Graham, On Fri, Mar 13, 2015 at 3:39 PM, Graham Leggett <minf...@sharp.fm> wrote: > >> What doesn’t seem to fit is the realm definition - specifying userCredCol >> is marked as mandatory, but this is obviously not present with a client >> certificate. What do you specify in this field? >> > You define the password column, which could have NULL values now, since we don't use passwords anymore.
> >> Does anyone have a working example of authentication using client >> certificates and authorization using a realm backed with a DataSource? >> > > > Try doing some online searching for the type of errors you got. Here's > what pops up in my quick google search: > > http://stackoverflow.com/questions/5086457/setting-up-client-cert-authentication-with-roles-on-tomcat-6-0 > > Here's another interesting article that tackles the old version of Tomcat, but the ideas are very similar. Here's a link: http://stackoverflow.com/questions/163113/can-client-cert-auth-method-be-used-with-a-jdbc-realm-within-tomcat Summary: "User Names The user name column should contain the certificate subject's distinguished name, as a character string. Unfortunately, the method Tomcat uses to obtain this string produces an implementation-dependent result, so it's possible if you were to switch to a new security provider or even just upgrade your Java runtime, you might need to map your user names to a new form. You'll have to test your deployment to find out what format is used. Specifically, getName() is called on the Principal returned by X509Certificate.getSubjectDN() to obtain a String, which is used as the user name. If you read the documentation, you'll find that this is no longer the best approach. Authentication The simplest set up would be to load your trust anchors into Tomcat's trust store, which is configured in the "server.xml" file. With this setup, any client certificate chain that is root in one of your trusted CAs will be considered "authenticated," and rightly so—authentication means that an identity is known, and is distinct from authorization, which determines what that identity is allowed to do. Authorization Since anyone with a signed certificate will be authenticated, you need to set up roles in order to protect private resources in your application. This is done by setting up security constraints, associated with roles, in your "web.xml" file. Then, in your database, populate the "roles" table to grant trusted users with extra roles. The relationship between the user table and the roles table works exactly as it would with FORM-based authorization, and should be utilized to grant appropriate permissions to users that you trust. A Note on Passwords The JDBCRealm will create a new Principal, which does carry a password, but unless your application downcasts this Principal to the Tomcat-specific implementation (GenericPrincipal), this property won't be visible to you, and it doesn't really matter what you put in that column. I recommend NULL. In other words, when using JDBCRealm with client-auth, the password field is ignored. This GenericPrincipal has a method to access an underlying principal, but unfortunately, the Principal from the certificate is not passed along; the JDBCRealm will set it to null; the only useful method in this scenario might be getName() (returning the subject DN is some possibly non-standard form). Table Structure and Content Use exactly the same table structure you would for a FORM-based JDBCRealm (or DatasourceRealm). The only difference will be in the content. The user name will be a text representation of the subject distinguished name, and the password will be NULL or some dummy value." I don't know how much of it is still relevant in Tomcat7/Tomcat8. By the way, what platform, what JVM and what version of Tomcat do you run? Hope that helps! Cheers! Neven
