tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: decouple authentication and authorization of TOMCAT
Date Wed, 16 Sep 2009 21:23:57 GMT
Hash: SHA1


On 9/14/2009 3:33 PM, André Warnier wrote:
> John Chen wrote:
>> Apache front-end will do the authentication, does tomcat still use
>> tomcat-users.xml for the authorization part?
> I am not quite sure.

I'm not sure which is the important part of the above question, but if
you configure Tomcat to accept httpd's user id, Tomcat will almost
certainly NOT use tomcat-users.xml for any reason whatsoever: you will
have to remove any role-name constraints from your web application's
security constraints for this to work.

Using the special role name '*' MAY work, but my interpretation of the
specification is that treating '*' as "any authenticated user,
regardless of role name" is not correct. Most implementations I have
seen of servlet authentication + authorization *do* treat '*' to mean
"any authenticated user, regardless of role name" but that's just due to
pure laziness of the implementation. (I'm not pointing fingers...
securityfilter also takes the lazy approach).

> I believe Tomcat's integrated AAA is pretty much
> an all-or-nothing proposition.

It is. You can wrap securityfilter in your own filter that does AD
authentication but then uses sf for authorization if you want, but I
have to think there's a better way. What's wrong with adding group/roles
to AD? Perhaps there is a way to use JNDIRealm to force a role that
doesn't actually exist in AD.

If you'd like to hack JNDIRealm, patches are always welcome. We've seen
this kind of request before, so I suspect it would be a useful thing to
add to the realm itself.

> But maybe, if the request is authenticated by Apache beforehand, it
> may work, since after all the request is authenticated before Tomcat
> even hits the webapp.

I think you'll find that adding httpd is more trouble than it's worth. YMMV.

> What I do not know, is if Tomcat, having accepted the prior
> Authentication of the request, would still anyway check if this user-id
> is "in a role" which allows running the webapp, and if it would do this
> using the tomcat-users.xml database, even though it did not use it to
> authenticate the user.

Tomcat doesn't get any role information from httpd. I think it basically
just creates a Principal object whose 'name' is the thing that httpd
asserts it is. Again, I suspect that checks for the '*' role will
succeed, but the spec does not guarantee such behavior.

> - then, at the Tomcat level, you would need to override the
> "isUserInRole()" method, so that it would compare the webapp's required
> role or roles, with these additional attributes or HTTP headers.

This may be more difficult than it sounds, because you'd have to do it
in a Valve that is installed /before/ the security valve (or whatever)
used by Tomcat. I believe that, for obvious security reasons, this is
not possible using normal configuration.

> I guess we should have a look at the securityfilter servlet filter,
> since it may already do something of the kind.

It does. Our next version should be a bit more modular, and should allow
a user to trivially build an authorization-only module out of the pieces
we provide.

> What I don't know and cannot comment on, is if the above kind of scheme
> would be easier to implement than creating a new Tomcat Realm which does
> all that. I am also not sure (because I'm too lazy to check right now)
> if a Tomcat Realm is specific to Tomcat, or part of the Servlet Spec and
> thus portable.

Not portable :(

> (*) and, to make this more efficient, you could save this in a cookie,
> so that on subsequent requests you can re-use it without re-looking up
> the AD record.

Uh.... are you sure you want to trust authentication information
asserted by a remote client? It would be safer to trust a cookie-encoded
session id and cache the AD info in the session. Why? Because session
ids are randomized so that guessing a valid one is difficult. Guessing
usernames is not so difficult.

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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message