A mechanism to reloading principal

[cemo]

What are the best practices to reload principal inside and outside (a cron application) of the application. This is a question originating by spring-projects/spring-session#398 (comment) and we have same problem. We have some workarounds to mitigate problem but it would be awesome to have a solution in the first place.

[rwinch]

You would need to provide a custom SecurityContextRepository implementation

[cemo]

Don't you think that this should be included in Spring Security?

[rwinch]

@cemo I'm not sure I agree it needs to be in Spring Security, but should be in Spring. Spring Session provides a good way of doing this.

[cemo]

@rwinch I will be glad that If you can expand a little bid your statement. What should be approach exactly?

[rwinch]

You can access the session and update the attribute to the updated principal.

[cemo]

I was considering an abstraction to mark user security context dirty by either a session or another approach and then reload it at first request. How does it sound? Does it worth being included in Spring Security Core?

[rwinch]

How do you mark it as dirty? How do you reload the context?

[sambiomatters]

@rwinch This issue actually prevents our use of Spring Security. We have done workarounds in the past, but it becomes very unwieldy to workaround if you use any other AuthenticationTokens besides the UsernamePasswordAuthenticationToken. There really needs to be a way to reload the principal in an AuthenticationToken type agnostic way.

A solution would be to let the user details and authorities to be lazy loaded, or delegated. The issue now is that Authorities are copied at login to the AuthenticationToken so it is impossible to delegate access to those authorities to a database lookup.

[lglapinski]

@rwinch Is good way of doing this mentioned by you better than presented here?

[IARI]

The Issue mentioned by @lglapinski (and #849 plus several others linked there) all relate to Redis sessions.
Is it possible to achieve this with plain http-sessions as well?

@rwinch would a

custom SecurityContextRepository

be the way to go - and if so, can I just override HttpSessionSecurityContextRepository ?

And if i have done so and instantiated it in my WebSecurityConfigurerAdapter, Is it enough to register that as a bean? Does it need a special name?

[rwinch]

You need to explicitly configure the repository

@Autowired
SecurityContextRepository securityContextRepository;

@Override
protected void configure(HttpSecurity http) throws Exception {
	http
		.securityContext()
			.securityContextRepository(securityContextRepository)
			.and()
		....
}

You can find a complete sample here https://github.com/rwinch/spring-security-sample/tree/gh-3849