SecurityContext inherited by threads on the serverside

[anil.saldhana]

http://anonsvn.jboss.org/repos/jbossas/tags/JBoss_4_0_5_GA/testsuite/src/main/org/jboss/test/security/test/SAThreadLocalUnitTestCase.java

The test "testThreadLocal" clearly tests that on the server, SecurityAssociation securitycontext (principal,cred,subject) are clearly not inherited by any threads that are started by the particular thread where this association is established.

I would like to understand from Scott as to why the inheritance of security context by threads is wrong on the server side.

[anil.saldhana]

Scott, is my understanding correct here? ^^^^^^

[starksm64]

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.

[anil.saldhana]

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.

[starksm64]

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.

[anil.saldhana]

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.