tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Tomcat SPNEGO valve - role assignment in 'grant-all' realm
Date Wed, 10 Oct 2012 12:24:32 GMT
On 10/10/2012 10:30, Maarten van Hulsentop wrote:
> Hi,
> We are configuring our Tomcat web application to authenticate using SPNEGO
> (Kerberos in particular) on Tomcat 7.0.29.
> Following the step-by-step 'Windows Authentication How-To', i succeeded
> doing so. Part of setting it up was configuring a Realm that assigns a role
> to the user, because the web application requires this. The Realm is
> supposed to grant the role to any user, where the password equals the user
> name.
> Now, as long as we combine the SPNEGOAuthenticator and this Realm, there is
> no issue. But as soon as somebody starts using my special Realm in
> combination with, lets say, the BasicAuthenticator, we have introduced a
> huge security hole.
> In my mind, the responsibilities are assigned differently. The Valves
> (Authenticators) should be doing the HTTP request/header/login form/etc
> handling, and the Realm should be doing the actual Authentication against
> some data source. In the case of SPNEGO, the SPNEGOAuthenticator seems to
> try to do the authentication as well, and only delegate to the Realm to
> finally grant the role.

Correct. Things aren't are clear cut as I would like for SPNEGO or for
CLIENT-CERT where it is difficult / impossible to separate the
information gathering (Authenticator) from the validation (Realm).

> Now my questions are; am i right i my assumption of the responsibilities?

Generally yes, but reality gets in the way for some authentication methods.

> Should i be configuring this differently? or am i indeed on the right track?

I think you are on the right track. Without seeing your Realm it is hard
to comment as where you are adding the role is important. It should be
possible to implement it so only SPNEGO authenticated users get the role
and all other users are denied access. That should shut the security
hole you describe.


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

View raw message