SingleSignOn valve in combination with SPNego

[Maarten van Hulsentop <ma...@vanhulsentop.nl>]

Hello all,

We are encountering an issue with the use of the SingleSignOn valve and
SPNego and are looking for a best practice on this. Let me describe our
situation;
Our suite consists of multiple end-user webapplications but also a few
webapplications that accept interaction from other systems. Authentication
from other systems is always done on a BASIC authentication basis, using
username/password.

For the end-user webapplications the method of authentication and
authorization (Valve and Realm) is configurable in the application specific
realms. The end-user applications are closely related so we use the
SingleSignOn valve at global (server.xml) level to share end-user 'logins'.

To make sure that users who succesfully authenticated by an end-user
webapplication cannot access the webapplications for external systems, the
SingleSignOn valve has requireReauthentication set to true. This way a user
can only access the applications for which the username/credential matches.

Now, when we configure SPNego, we have to have a realm for that web
application that always grants the user access, as the authentication for
SPNego is performed completely in the valve. But when a user who
authenticated in a non-SPNego web application tries to access the SPNego
web application, the realm will also allow that user. This is a problematic
situation.

Maybe we could prevent this with the role mechanism, but in some cases we
like to use the tomcatAuthentication="false" on the AJP connector, and in
those cases a role would complicate things.

Any ideas?

Regards,

Maarten

Re: SingleSignOn valve in combination with SPNego

[André Warnier <aw...@ice-sa.com>]

Konstantin Kolinko wrote:
> 2014-06-04 17:02 GMT+04:00 Maarten van Hulsentop <ma...@vanhulsentop.nl>:
>> Hello all,
>>
>> We are encountering an issue with the use of the SingleSignOn valve and
>> SPNego and are looking for a best practice on this. Let me describe our
>> situation;
>> Our suite consists of multiple end-user webapplications but also a few
>> webapplications that accept interaction from other systems. Authentication
>> from other systems is always done on a BASIC authentication basis, using
>> username/password.
>>
>> For the end-user webapplications the method of authentication and
>> authorization (Valve and Realm) is configurable in the application specific
>> realms. The end-user applications are closely related so we use the
>> SingleSignOn valve at global (server.xml) level to share end-user 'logins'.
>>
>> To make sure that users who succesfully authenticated by an end-user
>> webapplication cannot access the webapplications for external systems, the
>> SingleSignOn valve has requireReauthentication set to true. This way a user
>> can only access the applications for which the username/credential matches.
>>
>> Now, when we configure SPNego, we have to have a realm for that web
>> application that always grants the user access, as the authentication for
>> SPNego is performed completely in the valve. But when a user who
>> authenticated in a non-SPNego web application tries to access the SPNego
>> web application, the realm will also allow that user. This is a problematic
>> situation.
>>
>> Maybe we could prevent this with the role mechanism, but in some cases we
>> like to use the tomcatAuthentication="false" on the AJP connector, and in
>> those cases a role would complicate things.
>>
>> Any ideas?
> 
> Just some thoughts.
> 
> 1. What Realm implementation are you using?
> 
> SpnegoAuthenticator calls
> 
>>            principal = context.getRealm().authenticate(gssContext,
>>                    isStoreDelegatedCredential());
> 
> SingleSignOn.reauthenticate( ) calls
> 
>>                Principal reauthPrincipal =
>>                        realm.authenticate(username, entry.getPassword());
> 
> So if you have a custom realm, the two use cases can be distinguished
> by the methods that they call.
> 
> 2. Programmatically, re-authentication can be suppressed by either one
> of the following
> 
> a) clearing REQ_SSOID_NOTE note from Request,
> in any valve in the chain before the authenticator is invoked
>> request.removeNote(Constants.REQ_SSOID_NOTE);
> 
> b)  in a custom Authenticator,
> by overwriting reauthenticateFromSSO(..) or
> by setting AuthenticatorBase.sso to the value null
> 
> I wonder whether it makes sense to add a flag to an AuthenticatorBase
> to allow to configure whether it participates in SSO. If it does not,
> then skip sso lookup in startInternal() and return early from
> reauthenticateFromSSO() method.
> 
> 4. Maybe you can move the web applications that require SPNEGO to a
> different <Host> container, so that they do not share the SSO valve?
> 

I would tend to add +1 to item 4 above.

I do not know how the SPNEGO valve in Tomcat really works, so what follows may, or may not 
be applicable, but in any case be careful.
Windows "WIA" (web integrated authentication) generally requires several back-and-forth 
exchanges between the server and the browser (invisibly to the user), and it is imperative 
that these exchanges happen in a strict sequence and over the same TCP connection 
(because, from a WIA perspective, it is the *connection* which is authenticated) (which 
also means that when there is a new connection, a re-authentication must take place).
So it is generally a bad idea to mix WIA authentication with any other form of AAA (or to 
try to "smartly shortcut" the WIA authentication), because you may end up with the wrong 
sequence of messages between the browser and the WIA authentication mechanism.  And then 
you would start getting random "Forbidden" responses or random browser authentication 
popup dialogs, without really understanding why.
And it is a bitch to debug.

As mentioned earlier, I do not know the details of your setup or what you intend to do, so 
this may be irrelevant in your case.  But if you start receiving unexplained 401/404 
responses or seeing random popup login dialogs, remember this.

-------------------

At a different level, separately from the above :

The point of SSO is generally to avoid an inconvenience for the user : to have to re-enter 
login details each time they switch to another application.

Well, in the case of SPNEGO authentication, this is basically irrelevant anyway : the user 
never has to introduce his login details; these are picked up automatically by the 
browser, from the underlying Windows session, which is already authenticated ever since 
the user logged-in in Windows.  Whether this SPNEGO authentication has to be repeated when 
the browser/server connection changes, is similarly irrelevant from the user's perspective 
(*), since it is done automatically in the background when needed.
In other words, SPNEGO has its own built-in SSO (**), and there is no /need/ to combine it 
with any other SSO mechanism. (***)

(*) It is different from the underlying network perspective, but there is nothing you can 
do about that.
(**) one could call it "ZSO" for "zero sign-on", since the user never signs on
(***) and if you do, and try to be smart about it by trying to avoid the SPNEGO 
authentication when you think that the user is already signed-in, then it is almost 
guaranteed trouble

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: SingleSignOn valve in combination with SPNego

[Konstantin Kolinko <kn...@gmail.com>]

2014-06-04 17:02 GMT+04:00 Maarten van Hulsentop <ma...@vanhulsentop.nl>:
> Hello all,
>
> We are encountering an issue with the use of the SingleSignOn valve and
> SPNego and are looking for a best practice on this. Let me describe our
> situation;
> Our suite consists of multiple end-user webapplications but also a few
> webapplications that accept interaction from other systems. Authentication
> from other systems is always done on a BASIC authentication basis, using
> username/password.
>
> For the end-user webapplications the method of authentication and
> authorization (Valve and Realm) is configurable in the application specific
> realms. The end-user applications are closely related so we use the
> SingleSignOn valve at global (server.xml) level to share end-user 'logins'.
>
> To make sure that users who succesfully authenticated by an end-user
> webapplication cannot access the webapplications for external systems, the
> SingleSignOn valve has requireReauthentication set to true. This way a user
> can only access the applications for which the username/credential matches.
>
> Now, when we configure SPNego, we have to have a realm for that web
> application that always grants the user access, as the authentication for
> SPNego is performed completely in the valve. But when a user who
> authenticated in a non-SPNego web application tries to access the SPNego
> web application, the realm will also allow that user. This is a problematic
> situation.
>
> Maybe we could prevent this with the role mechanism, but in some cases we
> like to use the tomcatAuthentication="false" on the AJP connector, and in
> those cases a role would complicate things.
>
> Any ideas?

Just some thoughts.

1. What Realm implementation are you using?

SpnegoAuthenticator calls

>            principal = context.getRealm().authenticate(gssContext,
>                    isStoreDelegatedCredential());

SingleSignOn.reauthenticate( ) calls

>                Principal reauthPrincipal =
>                        realm.authenticate(username, entry.getPassword());

So if you have a custom realm, the two use cases can be distinguished
by the methods that they call.

2. Programmatically, re-authentication can be suppressed by either one
of the following

a) clearing REQ_SSOID_NOTE note from Request,
in any valve in the chain before the authenticator is invoked
> request.removeNote(Constants.REQ_SSOID_NOTE);

b)  in a custom Authenticator,
by overwriting reauthenticateFromSSO(..) or
by setting AuthenticatorBase.sso to the value null

I wonder whether it makes sense to add a flag to an AuthenticatorBase
to allow to configure whether it participates in SSO. If it does not,
then skip sso lookup in startInternal() and return early from
reauthenticateFromSSO() method.

4. Maybe you can move the web applications that require SPNEGO to a
different <Host> container, so that they do not share the SSO valve?

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org