tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: decouple authentication and authorization of TOMCAT
Date Mon, 14 Sep 2009 19:33:52 GMT
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 believe Tomcat's integrated AAA is pretty much 
an all-or-nothing proposition.  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.

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.

Need an expert to confirm this.

Anyway, for production usage, it is not recommended to use 
tomcat-users.xml, and it would also be rather unpractical if you have 
many users : you would still need to list all your expected user-id's in 
tomcat-users.xml, with their respective roles.

I have been having this same kind of issue myself, fortunately with a 
very low ratio of users/tomcat, so I could find other workarounds.  But 
I am interested also in a more general solution, in case the need ever 
crops up.

Basically, I would present the problem as follows; (sorry if this is not 
very rigorous in Java or Servlet Spec or Tomcat terms) :
- in Tomcat's flavor of AAA, one can specify, in the web-xml of a 
webapp, which "role" a user has to belong to, to be allowed to run the 
webapp.  I suppose this is quite efficient, because Tomcat can read this 
in advance (when the webapp is deployed), and buffer it, so it does not 
have to check an external source at each request.
- however, this notion of "role" does not really extend beyond Tomcat, 
so one would have to "map" it to, for example, some attribute of the AD 
(or LDAP) record of the user, and then arrange for Tomcat to be able to 
determine if the current user-id "is in that role".  (I believe there 
exists a method like "ServletRequest.getRemoteUser().isUserInRole(role)" 
or something of the kind).
If the answer is positive, the request gets through, otherwise it doesn't.

So the way I would see a practical solution, in a Windows Domain context 
(and in a platform-independent way) would be :
- first you need to authenticate the user and obtain a user-id.  This 
could be done via a front-end Apache, or via a servlet filter such as 
jCIFS or Jespa.
- then you would need something which, on the base of the user-id, 
obtains a list of attributes of this user which can be mapped to Tomcat 
roles. For example, this could also be done at the front-end Apache 
stage, by accessing the user's AD directory record directly, and passing 
the corresponding attributes to Tomcat via "request attributes" or via 
added HTTP headers in the request. (*)
- 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.

Of course, since by that time you are not really using the Tomcat AAA 
much anyway, you might as well bypass it completely and do your own form 
of authorization (via e.g. a servlet filter), based on any sort of 
"group list" your filter has access to.

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

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.

(*) 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.

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

View raw message