tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Boorshtein <>
Subject Re: Setting JK_REMOTE_USER help
Date Wed, 16 Jun 2010 17:27:25 GMT
> To look at this from a very strict point of view, the whole area is already
> a bit stretched.  Tomcat has this notion of "roles" (because the Servlet
> Spec has this same notion).  But if you look at common authentication
> schemes, like NTLM or LDAP, they do not have this notion.  It is possible
> that some authentication "Realm" (another servlet-engine specific use of the
> term) "translates" the NTLM notion of "user group" (or some LDAP attribute)
> into Tomcat's notion of "role" (and in fact they often do).  But that is a
> stretch. Unavoidable, because servlet engines do not know about "user
> groups", but stretch nevertheless.
> I suppose it would be boring if everyone agreed on the same notions all the
> time.

The issue here is that the servlet specification specifies a way to
check what "role" a user is in.  How that role is implemented (LDAP
group, user attribute, pulled out of a hat) doesn't really matter.  An
application's code can write "if (request.isUserInRole("X")..." and
should work.  It should also work whether you are using tomcat to do
authentication or something else (ie Apache+mod_jk or federation).
The problem with the Realm system is its designed with the assumption
that tomcat is doing the authentication which is not a valid
assumption in an environment where the authentication is seperated
from authorization.  The entire point of container security is that as
a coder I don't have to worry about how any of this is implemented.

> Basically, nobody stops you from retrieving some LDAP attributes of the user
> at the Apache level, and passing them over to Tomcat by adding one or more
> custom HTTP headers to the request (or a request attribute, as explained
> here :
> search for "JkEnvVar").
> And then at the Tomcat level, adding a servlet filter which retrieves these
> header/attributes and stuffs them inside the UserPrincipal object, to
> satisfy Tomcat's isUserInRole() call (with some approximation due to my
> incomplete knowledge in these matters).
> Just an idea to avoid having to access LDAP twice.

LDAP as a service is generally fast enough to be a negligable part of
the AAA process.  It looks like subclassing the JNDIRealm is going to
be the easiest way here.  I don't need perfect, just working for this
POC.  Spending 20 min on some code is still easier then getting
weblogic up and running.

Thanks everyone!


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

View raw message