tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Coe <>
Subject RE: JAAS authenticated user fails authorization check
Date Tue, 06 May 2008 19:47:46 GMT

You are quite correct about the classpath contention.  I should have been clear; to make use
of the libraries in my IDE, I'd have to include the jar in my lib folder for development,
not deploy the jar with the web-app.  That, or use introspection to avoid the IDE compile
problems and then rely on Tomcat to create the necessary objects at runtime.  I'm not a fan
of programming around exceptions, though, which I'd need to allow the security wrapper to
be deployed to another container.

As for JAAS and creating your own Principals, I think that's pretty much a requirement, if
you're doing something other than using the file and using a GUI app.  There
aren't too many Principal types, for any customizations you may need to make.  For example,
Tomcat has its own GenericPrincipal class, as well as security principal, whos type I forget
at the moment.

The JAAS login method uses a callback handler, which normally puts up a dialog when login()
is called without credentials in the handler.  Obviously, that's not really an option with
a web-app, so you have to roll your own login() and commit() implementations, using the callback
handler as the data source to populate your Principals.  So, if you want to use JNDI and JAAS,
you have no choice but to write your own JAAS module that hooks into your own JNDI module,
since Tomcat handles one but not both.

Basically, I really don't like having to specify LDAP account information in clear text in
a tomcat config file.  As well, with my own implementation, I'm not reliant on securing access
to my resources via HTTP requests.  It is definitely more work but is a lot more flexible
in the end.


-----Original Message-----
From: Christopher Schultz []
Sent: Tuesday, May 06, 2008 3:06 PM
To: Tomcat Users List
Subject: Re: JAAS authenticated user fails authorization check

Hash: SHA1


Robin Coe wrote:
| Problem is, the GenericPrincipal class is in the Catalina jar, which
| is available to Tomcat as a native library but for me to make use of
| it, I'd have to include it in my web-app lib.

Actually, no. GenericPrincipal as loaded by Tomcat's ClassLoader would
be incompatible with the GenericPrincipal class as loaded by your
webapp's ClassLoader. You'd need to put your authentication code into
Tomcat's lib directory in order to use it properly.

| I was hoping to be container-agnostic and avoid any proprietary
| libraries, which is why I used JNDI and JAAS.

But, you did use your own Principal implementation. Forgive my ignorance
regarding JAAS, but I was under the impression that it is atypical to
implement your own Principal object.

| I want to be able to hook into my security wrapper without
| necessarily going through Tomcat's security realm.

Container-managed security is pretty much intended to be self-contained.
You can't get Tomcat-managed authentication and authorization and yet
avoid Tomcat's security classes. Sorry.

| So, my options are to include the Catalina jar in my context or
| create my own mappings between resources and roles.  In the former
| case, I'll have a maintenance issue, because I'll have to ensure that
| the developers know that the jar needs to be kept in sync with the
| Tomcat environment.  In the latter case, I'll be manually doing what
| Tomcat can do.  However, if I am to be truly agnostic, that is what I
| should do anyway.

Maintaining a Tomcat-compatible security library will be much easier
than implementing your own authentication and authorization framework
(but feel free to do so!).

- -chris
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message