Marc Boorshtein wrote:
OK, come context first:
What I'm trying to do is integrate a Commercial Off The Shelf (COTS)
application that relies on container security into a Web Access
Manager (WAM). In a typical WAM deployment there are AAA is broken up
into multiple layers:
Web Server - Authentication (via the WAM) and course grained
Authorization (can the user access this app?)
Application - Fine grained Authorization aka Entitlements (can the
user perform task x?)
Since the authentication is done at the web server but the
entitlements are done by the application the web server needs to tell
the application server who the user is and the application server then
needs to fulfill the J2EE contract by providing information about the
user to the application.
In commercial application servers (Weblogic, WebSphere, JBoss) this is
done with an agent of some kind that satisfies the application
server's security requirements (usually by phoning home to the WAM to
validate the request). However commercial WAM products (SiteMinder,
OAM, etc) don't provide an "agent" for Tomcat. Given that what I'm
working on is a POC I'm not overly concerned with security as in
production this app will likely run on weblogic but for my purposes
Tomcat is a better pick for now.
That being said, the sequence of events should be:
1. Web server authenticates the user (works)
2. Pass the context to Tomcat (works)
Well, no. It passes a user-id to Tomcat.
For Tomcat, the user-id may be part of a "context" (although I believe that for Tomcat
also, the word "context" means "an application".)
3. Tomcat calls the realm to retrieve the user information and set
the context (doesn't presently occur)
Probably, more like yes. Tomcat, as far as I know, creates a userPrincipal object, which
contains the user-id and other information if available.
#3 appears to be the issue. Authenticaiton and Authorization should
be separate steps entirely in order to satisfy the J2EE contract in an
enterprise environment (which often involves WAMs).
So it doesn't sound like there is a configuration way to handle this.
I think I'll try hacking around to see if I can solve this with some
kind of custom Realm.
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.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
