[Freeipa-devel] Unifying the PKI and IPA Directory Server instances

[Ade Lee]

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 at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel