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? > > > > > >>> 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