tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Setting JK_REMOTE_USER help
Date Wed, 16 Jun 2010 17:02:42 GMT
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message