tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Tomcat SPNEGO valve - role assignment in 'grant-all' realm
Date Wed, 10 Oct 2012 21:46:46 GMT
Hash: SHA1

Mark and Maarten,

On 10/10/12 8:24 AM, Mark Thomas wrote:
> 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).

At one point, I tried to re-architect the authenticator/realm stuff in
securityfilter because it really is fairly insane. It was originally
based (I gather) upon Tomcat's architecture and even used to plug-into
Tomcat (until Tomcat Realms started needing more support from Tomcat
internals instead of being completely independent), so it shares the
same authenticator / realm separation.

Conceptually, everything should be separated into controller,
credential-gathering, and authentication components. The
credential-gathering component should be able to take input (the
request) and provide credentials. Then the controller can provide
those creds to the authentication component. If the authentication
fails, the credential-gathering component can be used to take
appropriate action (e.g. return a 401 response, redisplay a login
form, etc.).

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

Very much so, yes: as soon as you try to step outside of the HTTP
Basic/Digest and FORM authentication (really credential-gathering)
strategies, things get weird. CLIENT-CERT is perhaps the weirdest of
all of these, because there is basically neither a user interface to
gather credentials (other than the browser's "choose client cert"
dialog) nor is there an authentication interface, because everything
gets done at the SSL layer. Technically speaking, the CLIENT-CERT
could be implemented with the kind of separation described above, but
it's needlessly complicated that way.

The point I was trying to get around to, here, was that the
credential-gathering component can produce credentials that have
private information that only a certain (paired) authenticator knows
about. In that case, a SPNEGO cred-gatherer could be coupled with a
SPNEGO authenticator such that the authentication (and
role-assignment) would only work when the credentials came from the
right kind of credential-gathering component.

I'm interested to see what you come up with, Maarten.

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Mozilla -


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

View raw message