This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
My app uses Tomcat's JAASRealm to user authentication. Now I can define a web.xml and context.xml in my WAR file and they'll get properly integrated into Tomcat when I deploy the WAR. But what about my jaas.config file? How can I add that so that Tomcat will read it? Right now I'm setting a -D option in the startup options, but I'd like to make it portable and specific to my app.
Bai Shen wrote:... but I'd like to make it portable and specific to my app.
Is this possible?
Not really. The whole point of container-based Authentication and Authorization is that the webapp doesn't know what kind of security Realm you're using. It's all plugins, and that makes it possible to test a webapp using the tomcat-users.xml file but authenticate using LDAP or JAAS in production without any application changes whatsoever. All the configuration is done to Tomcat, not the webapp.
CBAA isn't the ultimate in security. It's not very fine-grained, allowing only automated authentication of the user, URL-based authorization, and authority checking based on what role(s) are assigned to that user. JAAS, on the other hand, is very nuanced.
That doesn't have to be a problem. You can use CBAA for the coarse-grained security (for example, to keep ordinary users away from the application's administration pages). When you need finer authority-checking, you can use the User Principal object as a key into the fine-grained security system.
There are 2 ways to do that. The most portable is to simply use the username to lookup the additional rights definitions through external services (for example, a JDBC request). However, the UserPrincipal interface might be bound directly to interesting features. In that case, you might cast the UserPrincipal to its concrete implementation.
If you take the second approach, however, consider constructing a security object factory instead of doing the cast directly so as to localize the kludgery. You'll need the source code for the Realm implementation you're planning on using - and one of the first things that you lose will be the ability to test with simpler Realms such as the MemoryRealm. Finally, be aware that you're greatly limiting your options, since there's no universal Realm architecture. A Tomcat Realm module and a WebLogic Realm implementation may be radically different even though both will be implementing the same CBAA service. And, of course, Tomcat's own Realm architecture might change over time, causing your kludge-code to break.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Sep 24, 2008
Okay. But I have a couple more questions.
Why is it that Tomcat can see my LoginModule, but not my custom Principal class?