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

[Simo Sorce]

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