>
> 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 : http://tomcat.apache.org/connectors-doc/reference/apache.html
> 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!
Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
