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 Thu, 17 Jun 2010 14:08:28 GMT
>> Hi.
>> I must say that, with my limited knowledge of the Tomcat internals taken
>> into consideration, I tend to agree with Marc in this case, if he is
>> right in claiming that the Tomcat Realm mixes authentication with
>> authorization and does not allow to separate the two.
> Well, he said he's managed to make it work, so it must be possible to
> separate the two.

I got it to work by writing custom code (namely I commented out the
"bind" in the JNDIRealm).  Thats OK for my own needs building a POC
but I wouldn't use it in production.

> As far as I could tell, his major complaint was that it didn't just work
> 'out of the box' (but it needs a 3rd party agent in the other examples).
>  He also threw in a complaint about contract violations which I didn't
> think was fair, or valid.

So apparently you didn't actually READ what I wrote in my previous
email.  I would suggest you do as it is quite detailed and pinpoints
exactly what my "complaint" is.

>> At the very least, I would expect the Realm to check first if the
>> request already has a user-id, and skip the authentication part in such
>> a case.
> The Realm doesn't see the request at all.

This is what the "base" problem probably is.  The authentication
mechanism doesn't have the conext to make decisions

>> There are many cases out there were Tomcat is only a part of a more
>> complex system, where a network-wide authentication is required, while
>> the authorization part may still be one that only Tomcat can do.
> I don't think the Servlet Spec defines a situation where authentication
> and authorisation occur separately, but I'm happy to be corrected.

No, it doesn't.  It just defines an API that should work regardless.

> The Spec defines some methods of authentication & authorization (BASIC,
> FORM, etc), and some objects associated with the request which describe
> some properties of an authenticated user principal, and it's roles.
> It also makes statements about what Containers must provide API wise,
> but it doesn't say how.

Yes.  Thats my point.  It should be transparent.  I (or any developer)
that writes my app to the spec should not have to recode their
applicatoin because the container doesn't handle a common
configuration change such as externalizing authentication.

I'd be happy to share how I was able to get this to work...where is
the best place, the wiki?


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

View raw message