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

[Ade Lee]

On Thu, 2011-11-03 at 09:22 -0400, Rob Crittenden wrote:
> Ade Lee wrote:
> > On Wed, 2011-11-02 at 16:03 -0400, Adam Young wrote:
> >> To clarify:  there are two types of Data stored in the PKI CA DS
> >> instances.  One is Users and groups (IdM),  and the other is
> >> certificates and requests.
> >>
> >> The CA currently administers its own users:  creates, add deletes, add
> >> privs and so forth.  If  we extract the IdM  objects from the CA
> >> control, we will need to build another mechanism to manage them.
> >>
> >> The Certificates will stay in their own suffix.  I don't think anyone
> >> disagrees about this.
> >>
> >> I'm trying to think through the steps of using the IPA user database for
> >> PKI.  If I undertand the end state, the general flow will be driven from
> >> ipa-server-install and will look like this:
> >>
> >> 1.  Create a unified DS instance.  We can continue to name it the way
> >> that IPA does:   All caps the hostname.
> >> 2.  Apply the LDAP schema LDIFs to it.  At this point, we probably want
> >> to create the whole IPA schema,  and the cmsUser as well
> >
> > For clarification, cmsuser is just an object that is defined in the PKI
> > schema, not the actual admin user created in the install itself.
> >
> > It may be advantageous to actually pre-create this user when applying
> > schema LDIFS and just have pkisilent add the user certs.
> 
> The description attribute needs to store per-instance specific 
> information such as the requestId. Unless you mean just adding userstate 
> and usertype.
> 

In dogtag, I believe we have used the description attribute to store
whatever the user provided to describe the user/group.  This is more
relevant to the console.

As IPA will be managing users and groups, then it can also manage this
attribute.

> >> 3.  Call PKISilent (or equivalent) passing the info for  the Unified
> >> directory server instance, to include the IPA tree for the users.
> >> 4.  PKISilent will create the PKI admin user,  to include its
> >> certificiate in the IPA tree.  This user will be half baked from an IPA
> >> perspective,  but will allow administration of the CA.
> >
> > Pre-creating this user may solve this problem.  You can pre-create a
> > user with all the required IPA and PKI attributes and just have
> > pkisilent add the user cert needed.
> >
> > As we will be running as directory manager in this case, we will
> > permissions to do this.
> >
> >> 5.  Create a PKIDirectory Manager account that has complete control over
> >> only the PKI  suffix, and not the IPA suffix.  Modify the PKI code to
> >> use only this account.  This account should be able to authenticate
> >> against the Dir Srv using a client certificate, stored in the PKI
> >> specific NSS database.
> >
> > This of course involves setting up the relevant ACIs.  We may want to
> > consider the reverse.  That only certain IPA accounts should have access
> > to the PKI data.
> 
> Which still involves ACIs, right?
Right
> 
> >> 6.  Restart the CA.
> >> 7.  Continue the IPA server install from the.  Fix up the Admin user so
> >> that it works for IPA.
> >
> > Not needed if we pre-populate as mentioned above.
> >
> >> 8.  Disable the Directory Manager's password.  From here on out,  access
> >> to the Dir Srv should be either certificate or Keytab only.
> >>
> >>
> >> After IPA is up and running, the management of the User Database is done
> >> by IPA.
> >> One thing that several people have asked for in IPA is the ability to
> >> manage external Roles:  ones that don't map to ACIs.  PKI has this
> >> requirement as well.  There are a couple approaches we could take:
> >>
> >> 1.  Attempt to use the current Role mechanism in IPA.  This gets hidden
> >> to an outside user,  but that should be OK.  Checking if a user is a PKI
> >> Admin, Agent, or Auditor should be done only by a privileged account anyway.
> >>
> >> 2.  Use a User Group:  PKIAdmins,  PKIAgents,  and PKIAuditors.    This
> >> is what I would suggest.
> >>
> >> 3.  Create an external mechanism.
> >>
> >>
> >> Once IPA has assumed control of the IdM DB, we will still need to be
> >> able to get user certificates into the  user records CMSUser field.  I
> >> do not know CS well enough to say how that would work,  but I assume it
> >> will be one of these two mechanisms:
> >>
> >> 1.  Use the CA Administrative interface to modify an existing user to
> >> have the certificate
> >> or
> >> 2.  Add a mechanism to IPA to request and apply the certificate to the
> >> IPA User.
> >>
> >> I'm guessing that the flow would be something like this:
> >>
> >> 1.  Create a user  (ipa user-add)
> >> 2.  Assign them to the PKIAgents groups
> >> 3.  Call the CA Admin interface to make the user an agent.
> >>
> >> If we do it this way, the  PKI instance will need to be able to modify
> >> the IPA user record.  Alternatively:
> >>
> >> 1.  ipa user-add
> >> 2.  ipa group-add-member
> >> 3.  ipa user-cert
> >
> > 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.
> 
> And it never should IMHO. We need to maintain the idea that the CA is 
> some black box that we can poke at from time to time to get data but I'd 
> prefer to keep them discrete.
> 
Yes - me too.

> >>
> >> As an added bonus, we get user certs.
> >>
> >>
> >> One discussion we've had on the side is about scalability.  As the
> >> Databases increase in size, it might become impractical to fully
> >> synchroize the user database over to a machine that is dedicated to
> >> Certificate operations.  For example, we might have a public facing
> >> machine in the DMZ that is servering CRLs and OCSP  to the world.  This
> >> machine would only need the subset of users  that can act as PKI
> >> admins.  In this case, we might build a custom script for replicating a
> >> subset of the IPA data one direction only:  from one of the fully
> >> replicated instance to the DMZ instance.  This is not something we
> >> foresee doing in a near term release, but should be discussed and
> >> fleshed out.
> >>
> >> _______________________________________________
> >> Freeipa-devel mailing list
> >> Freeipa-devel at redhat.com
> >> https://www.redhat.com/mailman/listinfo/freeipa-devel
> >
> >
> > _______________________________________________
> > Freeipa-devel mailing list
> > Freeipa-devel at redhat.com
> > https://www.redhat.com/mailman/listinfo/freeipa-devel
>