Geek Answers Handbook

Is it possible to use the CLIENT-CERT auth method with the JDBC scope in tomcat?

The JDBC scope indicates the table structure for authentication, which contains the columns defined by the userNameCol and userCredCol attributes. They correspond to the user and password, which makes sense for the FORM or BASIC auth methods. They are interactive and require these two parts from the client user.

  • What happens with the certificate?
  • What example data is stored in userNameCol and does userCredCol look like?
  • Is there an alternative table structure for the kingdom in this case?

PS - I am using tomcat 5.5.x.

+6
java authentication authorization web-services tomcat
source share
1 answer

JDBCRealm supports CLIENT-CERT

Yes it is possible. However, there are a few quirks to watch out for.

Usernames

The username column must contain the distinguished name of the certificate subject as a character string. Unfortunately, the Tomcat method used to get this line produces an implementation-specific result, so if you need to switch to a new security provider or even just update the Java runtime, you may need to map usernames to the new form, you will need check deployment to see which format is used.

In particular, getName() is called on Principal returned by X509Certificate.getSubjectDN() to get a String that is used as the username. If you read the documentation, you will find that this is no longer the best approach.

Authentication

The simplest setup would be to upload your trust bindings to the Tomcat trust store , which is configured in the server.xml file. With this setting, any client certificate chain that is root in one of your trusted CAs will be considered “authenticated”, and this correctly means that authentication means that the authentication is known and different from the authentication that determines what to do.

Login

Since anyone with a signed certificate will be authenticated, you need to configure the roles to protect private resources in your application. This is done by setting the security restrictions associated with the roles in the web.xml file. Then, fill out the “roles” table in your database to provide trusted users with additional roles.

The relationship between the user table and the role table works exactly the same as with FORM-based authorization, and should be used to grant the appropriate permissions to users you trust.

Password Note

JDBCRealm will create a new Principal that carries the password, but if your application does not empty this Principal in the Tomcat-specific implementation ( GenericPrincipal ), this property will not be visible to you, and it does not really matter what you put in this column. I recommend NULL .

In other words, when using JDBCRealm with client-auth, the password field is ignored. This GenericPrincipal has a method of accessing the main core, but, unfortunately, Principal not transferred from the certificate; JDBCRealm set to null; the only useful method in this scenario could be getName() (returning a DN object is probably a non-standard form).

Table structure and contents

Use the same table structure as for FORD-based JDBCRealm (or DatasourceRealm). The only difference will be in the content. The username will be the textual representation of the distinguished name of the subject, and the password will be NULL or some dummy value.

+5
source share

More articles:


All Articles