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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
