Messaging Thread Boundries and Authenticated Principal

[posta07]

Mark,
Would setting up the SecurityContextHolder to transcend all threads, or just spawned threads, be a viable solution?
According to the documentation, you can configure the SecurityContextHolder to behave differently from the default (which uses ThreadLocal to store the SecurityContext, as this forum discussion assumes). Options include SecurityContextHolder.MODE_INHERITABLETHREADLOCAL which would propogate the security context to spawned threads. See this link for more details: http://static.springsource.org/sprin...w.html#d0e1543

[Cleric]

Hello

SecurityContextHolder.MODE_INHERITABLETHREADLOCAL

will work only in spawned threads from main Servlet Reuest thread.
In the Spring Integration asynchronous mesasge flow provides theard for pollers from ThreadPool.
Off topic: Servlet Reuest threads are also taking from ThreadPool...
Already there is an issue about Security Context propagation in the JIRA: https://jira.springsource.org/browse/INT-2166

Artem Bilan

[posta07]

Thanks for the reply, Artem.

will work only in spawned threads from main Servlet Reuest thread.

Sure, that's the strategy for MODE_INHERITABLETHREADLOCAL. But what about MODE_GLOBAL?

From the docs, previously linked to:

Some applications aren't entirely suitable for using a ThreadLocal, because of the specific way they work with threads. For example, a Swing client might want all threads in a Java Virtual Machine to use the same security context. SecurityContextHolder can be configured with a strategy on startup to specify how you would like the context to be stored. For a standalone application you would use the SecurityContextHolder.MODE_GLOBAL strategy.

[Cleric]

MODE_GLOBAL is a strategy about singleton for all application.
And Spring Security doc contains truth - it's for Swing