Konstantin Kolinko wrote:
2014-06-04 17:02 GMT+04:00 Maarten van Hulsentop <maar...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
