On 11/03/2011 11:00 AM, Ade Lee wrote:
On Thu, 2011-11-03 at 09:20 -0400, Adam Young wrote:
On 11/03/2011 12:56 AM, Simo Sorce wrote:
On Wed, 2011-11-02 at 20:25 -0400, Adam Young wrote:
On 11/02/2011 06:19 PM, Rob Crittenden wrote:
Simo Sorce wrote:
On Wed, 2011-11-02 at 16:44 -0400, Ade Lee wrote:
On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote:
[...]
So, a user becomes an agent on the ca by having a certificate in the
user record and being a member of the relevant admin, agent or auditor
group.
I see this as follows:
1. ipa cms-user-add (add a user and add the auxilliary cmsuser object
class)
2. ipa user-cert (contact the ca and get a certificate for this user,
add this cert to the user record in the ipa database)
3. ipa group-add-member (add the user to the relevant group)
At no point does PKI need to modify anything in the IPA database.
Sounds reasonable.
Can you post a link to the schema that would be added to IPA objects ?
Simo.
I think this is it:
http://svn.fedorahosted.org/svn/pki/trunk/pki/base/ca/shared/conf/schema.ldif
Look for cmsuser.
Unfortunately it looks like the cmsuser objectclass is of type
structural, which means it cannot be added to existing records.
The cert seems to comes from
05rfc4523.ldif
and is added in
06inetorgperson.ldif
Which is already in our user record.
CMS only seems to "require" usertype, which is a string, and "allows"
userstate which is an integer.
I wonder if we can convince PKI to use a different schema to reprsent
this information. We can use Roles or Groups to tell what type of user a
user is, not sure about the state as that schema file has exactly the
same comment for both usertype and userstate, seems a bug.
I think so. I do not know if CMSuser is really needed, as it looks like
everything in there is accounted for some other way.
My guess is the "type" field is used to enforce that someone in one
group, say agents, cannot also be in a different group, say "auditors"
but they do use groups for most roles in the system.
I think that there are going to be severl layers for the permissions in
the IPA approach: For CAAdmins, we create a group CAdmins, and add a
Role to to CAAdminRole which contains the appropriate Permissions. Same
for Auditors and agents. No one should have the ACI to change these roles.
We probably want to put in an RFE for IPA Roles that state two roles
are mutually exclusive.
userstate is, I think, to disable an account, which is handled using
nsaccount lock in IPA. I think we should agree on a single mechanism,
and it should be the one in the most standard schema.
With just an initial look at the dogtag code, it appears that userState
and userType are no longer used in any meaningful way. We'll have to do
a more exhaustive search to be sure, but initial indications are that we
may no longer need this object class.
Adam does bring up a good point, which is that - as a common criteria
requirement, users were required to have no more than one of the
following roles: agent, admin, auditor. How would this be enforced in
the IPA database?
I think that we need to make it an RFE for IPA.
IIRC the user we create in CS now has the description attribute set up
in a very specific way. Is that still required?
What is description used for ?
Simo.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
