[Freeipa-devel] FreeIPA and Dogtag support for User Certificates in OpenStack Keystone

[Ade Lee]

On Mon, 2013-08-26 at 12:38 -0400, Adam Young wrote:
>   Keystone needs signing certificates for Signing PKI tokens.
> 
> In addition, CERN has a developed an approach that allows user to 
> authenticate to Keystone via X509 for batch jobs.  This requires Client 
> Certs.
> 
> Both of these use cases are easily supported by Dogtag, but not exposed 
> via FreeIPA yet.
> 
> The easiest path forward is to open up direct access to the Dogtag REST 
> APIs.
> 
> In this case, the work flow would be:
> 
> User sends CSR to Dogtag
> Agent approves
> User fetches signed certificate
> User uploads to IPA
> 

I can see a couple ways of implementing this.

Scenario A: (similar to current implementation)

1. User logs into IPA UI/CLI using Kerberos and IPA server obtains all
the relevant information needed to create the CSR.

2. IPA agent sends the request to dogtag specifying the relevant
profile.  This should be done using the new REST API.  There are fields
in the request to specify the requester name etc.  Any Kerberos/CSR info
validation should be done by IPA.

3. Dogtag gets the request and puts it in a queue for agent approval.
By default, anyone can submit a cert request - but I see no reason not
to use the ipa-agent.

4. Certificate Agent -- and by this I mean users which have added to the
dogtag database and to the relevant agent groups using the REST API -
looks at their queue and selects and approves the request.

5. Dogtag issues the cert.  An LDAP publisher is pre-configured on the
dogtag instance to publish the issued certificate to the user's entry in
the IPA subtree.  The user's entry DN is created by mapping from
attributes in the subject name.  The format of the mapper can be
configured.

Now all of the above requires changes mostly on the IPA side.  IPA will
need to add UI/interfaces to display request queues, requests etc. as
well as the ability to add agents to dogtag.

We could make this easier by allowing agents to pass directly to the
dogtag UI and expose the dogtag UI as part of the IPA UI.  We are
planning a similar kind of thing for the token management in the near
term.

For this to happen, we likely need the following:
1. Kerberos realm to be added to dogtag to allow Kerb authentication.
This is planned for token management.
2. IPA dogtag theme so that the change in UI experience is not too
jarring.

For agents, this is not a bad approach.  End users could also be exposed
to the dogtag UI, but given that you want to do some validation/
specification of the subject DN, its probably easier to do this on the
IPA side.
 
For CLI of course, it is possible to use the REST interfaces directly or
call the new pki CLI - which uses the new RESt interfaces.

> The questions I have relate to Dogtag/IPA integration:
> 
> All actions to Dogtag shuld be via mod_nss secured with Kerberos.
> Does this tie in with Dogtag, or would Dogtag require Client Side 
> Certificate validation?

Right now, dogtag requires client cert validation.  We will be adding a
Kerb realm in future though.  Remember though that only agents and
admins are agent have user entries in Dogtag.

> Even with Kerberos authentication, there is still no cross reference 
> between the Kerberos Principal and the CSR Subject.  Is this a problem?

As mentioned above, its probably better to do any vaslidation on the IPA
side.

> I thought there was a custom Tomcat Realm for integrating with 
> Kerberos.  If so, does this expose the correct data to check the Subject 
> in the CSR?

As noted above, the EE pages to request a cert do not require
authentication by default.  We could make them require kerberos
authentication and then we would be able to get the Principal
information.  Offhand, though, I'm not sure where we would add the logic
to use this information to check the subjectDN of CSR.

Might be easier to do any validations/ forming the CSR on the IPA side,
and continue to restrict interactions between IPA and Dogtag to
agents/admins.

> Are there security implications in the user uploading their own 
> certifcates to FreeIPA's LDAP?
> 
Not to Dogtag as long as Dogtag maintains its own set of users/groups
for agents and admins.
> 
> Can we re-enable the Dogtag XSRF checking without breaking IPA?
> 
This is possible if certs are requested using the new REST API.  So we
would have to update the IPA code to do this.

> Does it make sense to have an extension to ipa-server-install that 
> specifies a Keystone user that becomes a Dogtag agent, or a comparable 
> commandline tool of the ipa-* family?
> 
Thats an IPA/ Keystone policy type question.  For dogtag, all agents are
equal.

> If we expose an URL for CSRs, that exposes the potential to request CSRs 
> of any set of attributes.  The Agent would need to be careful not to 
> sign in appropriate requests.  Is there any support for limiting the 
> types of Requests that would be acceptable?
> 
The dogtag EE UI pages will expose only those fields that are permitted
by the certificate profile.  If you were to use the Dogtag EE user page,
you will see that it collects CSR information, and then uses the
information to generate a CSR, rather than taking any CSR.  

When cert requests are processed, only those attributes allowed in the
profile are used.


>