Scott, is my understanding correct here? ^^^^^^
It can be wrong if you don't want the ability to create a thread to allow you to capture an identity/credential that can be reused in later calls to impersonate the caller that was in effect when the thread was created.
Even though the implementation is going to be difficult - choosing inheritablethreadlocal and threadlocal, I am wondering if there is any way we make this configurable. Because your concern is just one of a hundred use cases IMO.
I feel that the inheritance of security context by child threads should be automatic.
In the past it was configurable with a system property. See how the org.jboss.security.SecurityAssociation.ThreadLocal property affects whether or not the SecurityAssocation uses ThreadLocal or InheritableThreadLocal stores.
String flag = SecurityActions.getProperty("org.jboss.security.SecurityAssociation.ThreadLocal", "false"); boolean useThreadLocal = Boolean.valueOf(flag).booleanValue();
Yes, you are right.
This works in AS4.
In AS5, on the client side, SecurityAssociation works as is. But on the server side, SA uses SecurityContext (my stuff) underneath and there I had just used a SecurityContextAssociation with an inheritableThreadLocal directly. I am fixing it with a system property.