On Thu, 2011-11-03 at 11:00 -0400, 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?
At the moment it can't be enforced, but I guess we could build a special plugin that will work similarly to the uniqueness plugin but will work on one or more pools of mutually exclusive roles to be enforced on all entries. I guess this is something that could be useful outside of CA as well if roles turns out to be used more. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
