[Pki-devel] Tomcat Realms and Directory Server

[Adam Young]

One issue I have been looking at recently is how to integrate  PKI and 
IPA  at the auth level while keeping a clean separation.

We can extract the authentication from the servlet code,  so it is 
purely a matter of configuring the Tomcat instance Realm.

I wrote up a Proof of concept for just doing pure LDAP  using simple 
bind,  which is not a bad starting point.

http://adam.younglogic.com/2011/11/tomcat-simple-ipa/


We want to continue this approach, but use a more secure authentication 
method.  We won't be using basic auth, and we won't be using simple bind.

There are two forms of authentication we want to support:  Client 
Certificates and Kerberos. Certificates will work as they do now, and 
Kerberos will be for passing through user credentials from IPA,  through 
HTTP to CS.  In both cases,  the data that backs it will be stored in 
the DS instance.

Tomcat has a class classed a CombinedRealm: 
http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#CombinedRealm

That might support stacking Certificate and Kerberos  auth  on top of 
each other.  The Realm will then delegate to LDAP for extracting the Roles.

http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JAASRealm

Kerberos is typically done using a JAAS Realm.  I have to admit I don't 
really like the fact that we have to modify the JVM startup to do so, it 
is not really that big of a deal.  I was also not a fan of setting the 
Realm up as a single service ticket until Simo informed me that the 
Browser NEGOTIATE mechanism assumes that the Service ticket is going to 
be Named HTTP.  This means that for Proxied implementations, to include 
IPA,  we will have to share the Service  Principal Identity with the 
Apache HTTPD server.

http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JAASRealm

However,  once you start digging in,  you will find that the solutions 
are suboptimal.  It turns out that the Negotiate  auth-method has only 
very recently been supported,  and that is only on Tomcat7.

The best resource I have found on the options for a custom realm is here:
http://wiki.wsmoak.net/cgi-bin/wiki.pl?TomcatKerberos
and the most likely option
http://wiki.wsmoak.net/cgi-bin/wiki.pl?TomcatKerberosLoginModule

We really want a mix of the KRB5Login Module and the JNDIRealm.  That 
seems to be what is described here:  
http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html

   We should  target Tomcat 7 for Dogtag:future.  Fedora 16 ships with 
Tomcat-7.

I suspect that the CombinedRealm approach will not support falling back 
from one auth-method to another:  I've been looking and have not see it 
specified that you can put multiple  auth-method  entries inside a 
login-config in the web.xml.  Ideally, we would attempt a Certificate 
based authentication first, and then fall back to Negotiate.  However, 
we can say that a given deployment is going to be either Kerberos or 
Client Certificate,  and swap out the configuration at the Tomcat 
level.  I don't like that nearly as much.

The document here: http://wiki.apache.org/tomcat/SSLWithFORMFallback  
talks about how to do Client Cert with a fallback to Form based 
authentication.  We'd want to do Client Cert  with a fallback to Krb5.  
This is using what is called a Valve.  In Tomcat 6 and 7  valves have 
been deprecated in favor of Filters.  The general approach is the same.

I'd like to keep the idea of the Realm as the primary approach.  If we 
do have to build a custom Realm, and I suspect that we will, we might 
want to spin it off into its own package, or submit it for Inclusion in 
Tomcat 7 upstream.

It seems that the PKI approach has been to Bind as Directory Manager.  
What I would like to target moving forward is that the Bind is done as 
the user making the web request.  For managed operations that require a 
higher level of authentication,  we use the concept of queues like we do 
now.  The threads that manage those queue will use a Principal with a 
higher level of authorization:  not "Directory Manger", but perhaps "CA  
Manager"  which is a user we create that manages the CA subtree in the 
Directory server.   For a Dogtag deployment without IPA,  the CA Manger 
would have write privileged on the Identity subtree.  For integrated 
deployments,  IPA would have its own principal  "IPA Manager"  that 
would not have read or write capabilities in the CA Subtree.   DRM,  
TKS  and other subsytems would in turn also get their own Manager users, 
and they would only have permissions to manage their own trees:  we will 
need to  clear up which gets read and write permissions on which other 
subtrees.

Directory Manager would be limited to performing operations that effect 
the entire DS instance:  Setup and Replication.

The Directory Manager, CA Manager, IPA manager users should be binding 
with  a certificate or a keytab,  not with a cleartext password.