问题
The JDBC realm specifies a table structure for authentication which contains the columns defined by the attributes userNameCol and userCredCol. These correspond to user and password which makes sense for FORM or BASIC auth-methods. They are interactive and require these two pieces from the client's user.
- What comes back from the certificate?
- What would an example of the data stored in userNameCol and userCredCol look like?
- Is there an alternative table structure for the realm in this case?
PS - I'm using tomcat 5.5.x.
回答1:
JDBCRealm Supports CLIENT-CERT
Yes, it can. However, there are few quirks to watch out for.
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.
来源：https://stackoverflow.com/questions/163113/can-client-cert-auth-method-be-used-with-a-jdbc-realm-within-tomcat