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 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. 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.
6.  Restart the CA.
7. Continue the IPA server install from the. Fix up the Admin user so that it works for IPA. 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

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

Reply via email to