Why use a JAAS Realm ?

[Sreyan Chakravarty]

I would like to know the advantages a JAAS Realm offers over other Realms like DataSource Realms.

Do JAAS Realms allow configuring a custom password hashing algorithms like bCrypt ?


Can I do post login activities like storing the user-id in the user session ?


Are there any advantages or reasons why you would want to use a JAAS Realm ?

Thanks.

[Tim Holloway]

All Realms are interchangeable. There is no difference in how Tomcat or the webapp interacts with them. There are no magic realms that do things like post-loogin activities, and in fact, if you'll notice there's not even any J2EE APIs for login-related activities at all. In an SSO environment, login may never take place within the context of a webapp because login was done somewhere else. (for example when you logged into Windows).

JAAS is a flexibie security framework, but the Tomcat Realm module for JAAS only uses a limited set of its capabilities.

The userID is available regardless of which realm you use. Just call the getRemoteUser() method of the HttpServletRequest. If the user has not been authenticated (logged in), then the value returned will be nuil. Otherwise it will be the userid that the user logged in under. That is, in fact, the only way an application can determine that a login took place: when requests start showing up with a non-null RemoteUser ID.

[Sreyan Chakravarty]

Tim Holloway wrote:All Realms are interchangeable. There is no difference in how Tomcat or the webapp interacts with them. There are no magic realms that do things like post-loogin activities, and in fact, if you'll notice there's not even any J2EE APIs for login-related activities at all. In an SSO environment, login may never take place within the context of a webapp because login was done somewhere else. (for example when you logged into Windows).

JAAS is a flexibie security framework, but the Tomcat Realm module for JAAS only uses a limited set of its capabilities.

The userID is available regardless of which realm you use. Just call the getRemoteUser() method of the HttpServletRequest. If the user has not been authenticated (logged in), then the value returned will be nuil. Otherwise it will be the userid that the user logged in under. That is, in fact, the only way an application can determine that a login took place: when requests start showing up with a non-null RemoteUser ID.

Sir, thank you so much for the answer. I am still not able to find anything on the net on how to configure realms. Sir can you tell me one thing, how would you add an user to a Realm ? For example when a new user registers on the site, how would you add that information to the User and Roles table for example. According to the docs here (https://tomcat.apache.org/tomcat-8.0-doc/config/credentialhandler.html) the credentials handler are configured so that they can hash new passwords but what do I have to do to add information to the Realm ?

[Tim Holloway]

There is a school of thought that user/role management should not only be a function of the webapp or server, but should be a completely external resource handled by completely different people. In fact, it's not uncommon in large enterprises for there to be a dedicated security group to handle stuff like that.

On the other side of the coin, there's websites such as online stores where users create their own accounts.

Java Realms don't concern themselves with this issue. All they care about is that there should be 2 pairs of mappings: a userid/password mapping and a userid/role mapping. When the database Realms are being used, these are usually something like a "users" table and a "roles" table. When LDAP/Active Directory is used, LDAP directory entries supply the data. I've also created Realms that simply queried remote Web Services.

If you want a self-registering web site, you would need to provide an independent database access connection such that your application program could write userids and passwords to your database as well as any other user profile information you might wish to capture above and beyond the Realm properties. Stuff like email and shipping addresses for example. It's good practice once a user has registered to require him/her to login immediately just so they get used to entering the password (before they forget it!). Also popular is to send an email with a "click-on-the-link", which ensures that their email address is valid in case they lose the password or just for general communications.

I think that one or 2 of the Realms has the ability to reference a database connection pool instead of making their own connections. The advantage there is that not only does that give the Realm the same advantage that Connection pools give webapps, but also that you only have to provide the connection information in one place instead of once for the webapp's use and once for the Realm's use.

[Sreyan Chakravarty]

Tim Holloway wrote:There is a school of thought that user/role management should not only be a function of the webapp or server, but should be a completely external resource handled by completely different people. In fact, it's not uncommon in large enterprises for there to be a dedicated security group to handle stuff like that.

On the other side of the coin, there's websites such as online stores where users create their own accounts.

Java Realms don't concern themselves with this issue. All they care about is that there should be 2 pairs of mappings: a userid/password mapping and a userid/role mapping. When the database Realms are being used, these are usually something like a "users" table and a "roles" table. When LDAP/Active Directory is used, LDAP directory entries supply the data. I've also created Realms that simply queried remote Web Services.

If you want a self-registering web site, you would need to provide an independent database access connection such that your application program could write userids and passwords to your database as well as any other user profile information you might wish to capture above and beyond the Realm properties. Stuff like email and shipping addresses for example. It's good practice once a user has registered to require him/her to login immediately just so they get used to entering the password (before they forget it!). Also popular is to send an email with a "click-on-the-link", which ensures that their email address is valid in case they lose the password or just for general communications.

I think that one or 2 of the Realms has the ability to reference a database connection pool instead of making their own connections. The advantage there is that not only does that give the Realm the same advantage that Connection pools give webapps, but also that you only have to provide the connection information in one place instead of once for the webapp's use and once for the Realm's use.

Okay so what you are saying is that I will need to manually insert the usernames, password and roles in the database myself. Preferably using something like JDBC. I have a couple of doubts regarding that. First of all according to the documentation (https://tomcat.apache.org/tomcat-8.0-doc/config/credentialhandler.html) Credential Handlers can have saltLength, iterations and algorithm. So why specify that when you can't use the Tomcat API to store username and hashed passwords. What good is saltLength when you are not creating a new password ?

Also the documentation says that it is used when creating a new password. So isn't there some way using the Tomcat API to store information in Realms ?

Also how do I replicate the same hashing for when I am storing the password to that of when I am querying the password from the Realm ? The hashing procedure must match and must be secure.

I just don't understand why Credentials Handlers have saltlength, and iterations when there is no way to tell the Realm that where the Salts are stored. The whole process seems pretty incomplete.

[Tim Holloway]

Tomcat and your web applications are 2 different programs with 2 different APIs, even though Tomcat is a program whose purpose is to contain and control webapps. Webapps shouldn't be talking to Tomcat's internal APIs, since that violates the "write once/run anywhere" paradigm of Java in general and J2EE in partucular. Tomcat's implementation of Realms is totally different than WebSphere's, for example. Even JBoss, which started out with an embedded Tomcat, is now using different mechanisms.

The Credential Handler is new to Tomcat 8 and it has to do with how the Realm verifies credentials (the password). Historically, if you stored a password as an encrypted (we hope!) value in a database, you specified which one of several digest methods would be used to verify the user's input password - a watchword of good security is that you DON'T fetch passwords from the database, you ENCRYPT the user's password and ask the database if there's a match. In other words:

SELECT COUNT(*) FROM USER_PASSWORD U WHERE U.USER_ID=? AND U.PASSWORD = ENCRYPTED(?)

if it returns 0, then the passwords didn't match, the login is rejected and we never had to fetch the actual password from the database where rogue code might be able to ship it off to the Ashley Madison hackers.

As I said, the old way of selecting which encryption method applied was to select one of a fixed number of methods. The CredentialHandler is code that allows implementing arbitrary validators instead of just what was in the original fixed set. You shouldn't need to code your own if you're using something standard like MD5, and therefore the salt and other strange parameters are should be equally unnecessary.

Adding a new user in your application code might look something like this:

final String SQL_COMMAND = "INSERT INTO USER_PASSWORD VALUES(user_id, password, email) VALUES (?, ENCRYPTED(?), ?)";
Connection conn = myConnections.getConnection();
PreparedStatement stmt = myConnections.prepage(SQL_COMMAND);
stmt.setString(1, newUserId);
stmt.setString(2, newUserPassword);
stmt.setString(3, newUserEmail);

Modify as needed to fix errors due to my not remembering all the details correctly, add error handling, etc. The "ENCRYPTED" SQL function will probably have some other name and/or parameters, depending on what brand of database you're using.

[Sreyan Chakravarty]

Tim Holloway wrote:Tomcat and your web applications are 2 different programs with 2 different APIs, even though Tomcat is a program whose purpose is to contain and control webapps. Webapps shouldn't be talking to Tomcat's internal APIs, since that violates the "write once/run anywhere" paradigm of Java in general and J2EE in partucular. Tomcat's implementation of Realms is totally different than WebSphere's, for example. Even JBoss, which started out with an embedded Tomcat, is now using different mechanisms.

The Credential Handler is new to Tomcat 8 and it has to do with how the Realm verifies credentials (the password). Historically, if you stored a password as an encrypted (we hope!) value in a database, you specified which one of several digest methods would be used to verify the user's input password - a watchword of good security is that you DON'T fetch passwords from the database, you ENCRYPT the user's password and ask the database if there's a match. In other words:

SELECT COUNT(*) FROM USER_PASSWORD U WHERE U.USER_ID=? AND U.PASSWORD = ENCRYPTED(?)

if it returns 0, then the passwords didn't match, the login is rejected and we never had to fetch the actual password from the database where rogue code might be able to ship it off to the Ashley Madison hackers.

As I said, the old way of selecting which encryption method applied was to select one of a fixed number of methods. The CredentialHandler is code that allows implementing arbitrary validators instead of just what was in the original fixed set. You shouldn't need to code your own if you're using something standard like MD5, and therefore the salt and other strange parameters are should be equally unnecessary.

Adding a new user in your application code might look something like this:

final String SQL_COMMAND = "INSERT INTO USER_PASSWORD VALUES(user_id, password, email) VALUES (?, ENCRYPTED(?), ?)";
Connection conn = myConnections.getConnection();
PreparedStatement stmt = myConnections.prepage(SQL_COMMAND);
stmt.setString(1, newUserId);
stmt.setString(2, newUserPassword);
stmt.setString(3, newUserEmail);

Modify as needed to fix errors due to my not remembering all the details correctly, add error handling, etc. The "ENCRYPTED" SQL function will probably have some other name and/or parameters, depending on what brand of database you're using.

Yeah but what if I wanted to use bCrypt or use a salt with MD5. What then ? The Tomcat realms don't seem to provide any mechanism for doing these things. How would you do these things ? Realms provide saltlength, which seems useless and incomplete. What do you do with that attribute ?

[Tim Holloway]

Well, that's the point. There's a default CredentialHandler (MessageDigestCredentialHandler) for that Realm, and it, in turn has a default Digest value of "text" (plain text). This gives backwards compatibility to older configurations. Next step up is to explicitly request the MessageDigestCredentialHandler and tell it to use one of the alternative digests (such as MD5 or SHA2).

If you have non-standard salt needs or the like, you can then start adding additional options per the documentation, and if that doesn't help, you can implement your own CredentialHandler. Thus, you do no more work than you have to to depending on your ambitions.

The CredentialHandler (at the risk of repeating myself) isn't part of your application program and wouldn't be used to create the user account records. It's used exclusively by the Realm to confirm that the password entered by the user matches the password stored in the database - once the appropriate encryption/hash has been applied.