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 13:57:47 GMT
On Thu, Jun 17, 2010 at 9:11 AM, Mark Thomas <> wrote:
> On 17/06/2010 13:26, André Warnier wrote:
>> 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.
> That is how Tomcat Realms are designed. This is consistent with the
> Servlet sepc that leaves the implementation details entirely to the
> container. If Tomcat required all authentication requests to be made via
> carrier pigeon then that would be spec complaint providing the correct
> information was exposed via the API defined in the spec.

Yes, it is as long as Tomcat is not combined with Apache or IIS.  Once
Tomcat offloads the authentication to Apache/IIS there should be a
mechanism in place to still continue the authorization framework.

>> 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.
> Easier said than done. The Realms deliberately have no visibility of the
> request or the response. The Authenticators extract the username and
> password, pass them to the realm to obtain an authenticated Principal
> (with roles) and then the Authenitcators populate the attributes that
> then support the calls in the Servlet API.
> The way to handle this (probably) is to modify the Authenticators
> (hopefully just the base class) to check for an already authenticated
> user. If one is found, use the realms just to get the roles. The
> implementation for that is already in place. It just needs adding to the
> interface and the visibility changed. Then you just need to figure out
> how to merge the existing Principal (that may have roles) with the new
> one that has the roles from the Realm.
> Tomcat 7's internal API has deliberately been declared as volatile inthe
> docs so now is the time to make these changes. Patches welcome.
> Note this won't get ported back to 6 due to the API changes required.

I'll take a look at the tomcat 7 api and see what I can do.


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

View raw message