[Pki-devel] the state of client auth and the new proposed restful interface

[Ade Lee]

Hi all, 

Client cert authentication is central to how the CS manages access to
its servlets.  How we use and have used client auth is tricky though -
and has implications for the new and current interfaces.

In this email, I hope to lay out the current state of client-auth - what
works, what doesn't, and some thoughts as to how this affects the
currently proposed interface.  More thoughts on how to solve some of the
problems would be really helpful. 

We use client auth in the following ways:

I. There are servlets which never require client auth (ee pages mostly)
and some admin (mostly installation related) pages

II. There are servlets which always require client auth (agent pages)

III. There are servlets which may require client auth (admin pages from
the console) which can be configured to require client auth.

IV. Enrollment profiles (executed from the EE pages - which do not
require client auth) - which, when executed - require client auth to be
processed.  Another example of this would be self-renewals.  This is a
case where we start off in a non-clientauth context and switch to client
auth.

Here is a brief history of how we have implemented client auth to
satisfy the above cases:

1. Shared Port Configuration: In the past, we did not have ports that
were specified as client-auth/ non-client auth.  Instead, if a servlet
required client auth, we would ask tomcat for the javax.x509.certificate
attribute and - through tomcatjss and jss - it would renegotiate the
connection and get the relevant certificate.  This handled cases I-IV.

2. Separated Ports:  Recently we changed the configuration to a port
separated configuration.  EE, admin and agent operations occurred on
separate ports, which were configured to either require (agent) or not
require (ee.,admin) client auth.  For case III, if client auth were
required, we configured the admin port to "want" - which would
essentially ask for a cert and continue if one was not provided.  For
case IV, we continued to rely on tomcat-initiated renegotiation.

3. Separated ports with MITM fix: For older clients without the newer
renegotiation protocol that fixes MITM, renegotiation is disabled.  This
means that case IV would fail for certain profiles and renewals.  The
fix for this was to redirect the profile submission to a new client auth
required EE port.

4. CA behind an apache proxy.  In this case, the outside world talks to
the CS through an httpd instance that talks to the CS though the ajp
port.  This is the current configuration used in IPA.  

* The decision as to whether a port is client auth/ non-client auth is
made in the proxy by mapping URLs.  URLs that begin with /agent for
example require client auth.  This handles cases I and II.  

* III is more complicated but can be addressed in the same way.  That is
we can tweak the URL matching rules to always permit the admin servlets
that always do not need client auth (like installation servlets), while
requiring client auth for other admin servlets.

* Case IV is currently broken.  Tomcat still passes on the request for
the javax.x509.certificate attribute - but ajp does not understand this
request and drops it on the floor - resulting in a 5XX type error being
returned.  As of now, I have been unable to find a way to configure ajp
to pass the request on to apache to have it renegotiate the connection.
 
5. The new proposed RESTful interface:

For Dogtag 9+, we have been envisioning that the CS instances would use
default ports and that they would still communicate with the outside
world through the http proxy.

At this point though, the new RESTful interface does not have any
indication as to whether the operation is agent/ee/admin -- no
indication of this in the URL -- so it is impossible to filter at the
httpd proxy based on URL.  Moreover, case IV is still broken.

There is also an additional consideration - which for reference, I cam
going to call case V. Some operations which currently have different
output depending on whether they are executed as an agent or an ee user
- are mapped to the same servlet in the new proposed api.  

An example is :
/pki/profiles -which would return a list of profiles 

This is a different list depending on whether it is executed as an agent
or whether it is executed as an EE user.

Possible Solutions (so far):

1.  Whether we use client auth is closely tied to our conception of who
is executing the command.  We have defined roles : ee, agent, admin in
the CS.  Perhaps we should add these to the proposed URI pattern?

So we might have /pki/agent/certificates and /pki/ee/certifcates  etc.
This would allow URL filtering on the proxy along the same lines as now
- solving cases I,II,III and V.  Case IV is still broken.

2. Another solution might be to - once we have determined that a client
cert is required (and has not been provided) - send a temporary redirect
to say /pki/getClientCert - with a 307 (temporary redirect) code.  This
servlet could be configured in the proxy to require client auth.  

This would presumably be the equivalent of renegotiating the connection
- except using apache rather than tomcat to do it.  And it would solve
all five cases listed above.

3, If we can figure out how to get ajp to pass back a request to
renegotiate the connection, then this might be the best solution yet.
Then we do not need to change any CS code - when we determine that we
need a client cert - it will be passed back to the proxy - and the proxy
will get the cert.
 
Ade