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? Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
