Preauthentication - Invalidate session on Principal Change and Roles(???)

[rrkwells]

I have a couple of questions regarding Preauthentication using SiteMinder scenario....

1). To invalidate a session on principal change, what all should be there in the configuration file? I thought have the attribute "invalidateSessionOnPrincipalChange" = true will be enough. But it doesn't work. I am using "Modify Header" add-on for firefox to add a header that will be used as principalRequestHeader. I connected to the app using once value and if I change the header value and refresh the page, its not getting the new header value. The old one is still the principal user.

2). Is the call to custom UserDetialsService made per request or is it only if no active user session exists for that principalrequestheader ? If it is second case, then how are the roles managed if there is a change in the user permission. I mean, I am attaching the roles to custom User object inside loadUserByUsername method of the Custom UserDetailsService class. So lets say, a user "XYZ" is an admin and he is logged into the app. For the first time, the request goes to loadUserBYUserName method and the roles are retrieved from db and added to User. Now if the user XYZ's permissions are changed on the database then how do we change the roles for this user. He was already logged in and the call to loadUser.. wouldn't happen. This is all assuming that the call to that method made only once per session. If it is per request, it wouldn't matter..

thanks in advance,

[rrkwells]

this is my security-config file's pre-auth-filter element..

<bean id="channelSecureFilter"
  		class="org.springframework.security.web.authentication.preauth.RequestHeaderAuthenticationFilter">
  	
  		<property name="principalRequestHeader" value="SM_UNIVERSAL_ID"/>	
  		<property name="authenticationManager" ref="authenticationManager"/>
  		<property name="invalidateSessionOnPrincipalChange" value="true"/>
  	</bean>

[marcelstoer]

Not sure I understand...still, I've got a few remarks.
a) The default value for invalidateSessionOnPrincipalChange in AbstractPreAuthenticatedProcessingFilter is true. Hence, you don't really need to specify that.
b) Whenever you invalidate the session the SecurityContext is killed too as it is bound to the session.
c) UserDetailsService is invoked whenever a SecurityContext is populated. This in return is done once per session. Hence, if you change a user's permissions when he's logged in the new state won't be applied until he logs out/in next time. If I'm not mistaken Peter Mularien's excellent Spring Security book shows how to apply those changes to an active session.
d) invalidateSessionOnPrincipalChange=true basically means this: if you send a different principal in a request (bound to an authenticated session) than the one that is stored in the SecurityContext, SS will first invalidate the session. Then, as by the above remarks, SS will invalidate the session, a new one is created, SS will create a new SecurityContext thereby invoking the UserDetailsService.

[lbarbul]

Not up-to-date at all, but..

To detect Pre-Authentication principal change (i.e. to refresh the Authentication in current Security Context) there is another property checkForPrincipalChanges.

See also the JIRA issue.

[dineshcse]

How would such deduction and invalidation possible in a legacy application that uses spring 2.0.x...Pls help