StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<h3>JDBCRealm Supports CLIENT-CERT</h3> <p>Yes, it can. However, there are few quirks to watch out for.</p> <h3>User Names</h3> <p>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.</p> <p>Specifically, <code>getName()</code> is called on the <code>Principal</code> returned by <code>X509Certificate.getSubjectDN()</code> to obtain a <code>String</code>, which is used as the user name. If you read the <a href="http://java.sun.com/j2se/1.5.0/docs/api/java/security/cert/X509Certificate.html#getSubjectDN()" rel="noreferrer">documentation,</a> you'll find that this is no longer the best approach.</p> <h3>Authentication</h3> <p>The simplest set up would be to load your trust anchors into <a href="http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html" rel="noreferrer">Tomcat's trust store</a>, 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.</p> <h3>Authorization</h3> <p>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. </p> <p>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.</p> <h3>A Note on Passwords</h3> <p>The <code>JDBCRealm</code> will create a new <a href="http://java.sun.com/j2se/1.5.0/docs/api/java/security/package-summary.html" rel="noreferrer">Principal</a>, which does carry a password, but unless your application downcasts this <code>Principal</code> to the Tomcat-specific implementation (<a href="http://tomcat.apache.org/tomcat-5.5-doc/catalina/docs/api/org/apache/catalina/realm/GenericPrincipal.html" rel="noreferrer">GenericPrincipal</a>), this property won't be visible to you, and it doesn't really matter what you put in that column. I recommend <code>NULL</code>. </p> <p>In other words, when using <code>JDBCRealm</code> with client-auth, the password field is ignored. This <code>GenericPrincipal</code> has a method to access an underlying principal, but unfortunately, the <code>Principal</code> from the certificate is not passed along; the <code>JDBCRealm</code> will set it to null; the only useful method in this scenario might be <code>getName()</code> (returning the subject DN is some possibly non-standard form).</p> <h3>Table Structure and Content</h3> <p>Use exactly the same table structure you would for a <a href="http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html#JDBCRealm" rel="noreferrer">FORM-based JDBCRealm</a> (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 <code>NULL</code> or some dummy value.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload