Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

SEC-1190: preAuth does not detect a change in the SSO header #1438

spring-issuemaster opened this Issue Jun 27, 2009 · 4 comments


None yet
1 participant

Mark Diskin (Migrated from SEC-1190) said:

I configured the sso preauth

I configured the
<property name="principalRequestHeader" value="ct-remote-user" />

and this is correctly picking up the user to establish the session. The issue is if the user ends his sso session and starts a new one - the session on the app server (running the spring stack) still has an existing session and it does not seem that the value of this ct-remote-user is checked after the initial session is established. So the user will rejoin under the prior id.

Attached is a solution we worked on with Stefan from support. This could be improved upon as we found we needed to fully cleanup the session itself.

In test this is a verey common occurance and also for us we use different instances of the SSO for the development areas, so it helps when switching between QA and Prod environments.

Luke Taylor said:

I've added a checkForPrincipalChanges property to AbstactPreAuthenticatedProcessingFilter, which is a more generic solution. If set, the filter will do a comparison of the pre-authenticated principal value against the name stored in the current Authentication object. If they don't match, it will reauthenticate the user with the new principal.

Mark Diskin said:


After posting this I had to make another change to allow for the session to be invalidated, as I had other objects in state - i.e. I did not want the new user to have objects belong to the old.

HttpSession session = request.getSession(false);

if (session != null) {

Without this I don't this this new feture would be something we could use.


Luke Taylor said:

It sounds like you need a logout link :).

I've added an "invalidateSessionOnPrincipalChange" property to AbstactPreAuthenticatedProcessingFilter. If set to true (the default) and a new principal is detected, the existing session will be invalidated before proceeding to re-authenticate the user.

Mark Diskin said:

We have a logout but folks like to avoid it. We have a number of folks especially during the development switching login user's on the SSO side and messing up existing sessions on the pre-auth application side.

Thanks - looking forward to the new 3.0 version - now we have to get the Jasper folks to adopt it so we can correctly configure their Spring Security code to work with our SSO (they still have the acegi base that was targetted to siteminder).

@spring-issuemaster spring-issuemaster added this to the 3.0.0 RC1 milestone Feb 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment