Status: Closed (View Workflow)
Affects Version/s: JBossAS-5.0.0.GA
Fix Version/s: 6.0.0.M1
Environment:Windows Vista, JBoss 5.0.0 GA
Similar Issues:Show 10 results
JBAS-7171 InvokerAdaptorService overwrites existing SecurityContext and clears it after invocation JBAS-7550 AuthenticationInterceptor overwrites the existing SecurityContext JBAS-7949 AuthenticationInterceptor is removing the SecurityContext from the thread JBAS-4323 XMBean Interceptor for InvokerAdaptorService to deal with NonSerializableExceptions - twiddle getAttributes JBAS-4326 Overwriting an existing passwordFile with FilePassword can corrupt the file JBAS-4288 Backport-XMBean Interceptor for InvokerAdaptorService to deal with NonSerializableExceptions to Branch_4_0 JBAS-7787 DataSourcePersistentManager does not overwrite creation time when "re-inserting" a record JBAS-7010 JndiLoginInitialContextFactory is not creating expected SecurityContext JBAS-4293 Should not throw TransactionRolledbackException when the transaction is rolled back because of setRollbackOnly invocation JBAS-1345 Clustered Invocation Layer
The InvokerAdaptorService always creates a new SecurityContext even if there is already one created by components called earlier in invocation stack. After invoking the desired MBean method the SecurityContext will be cleared with a call to: SecurityActions.clearSecurityContext();
This leads to several problems:
In our project we have a secured EJB (annotated with @SecurityDomain) which is calling an MBean Service and a local (secured) EJB. After the invocation of the mbean there is no security context anymore which leads to an IllegalStateException "Security Context has not been set" thrown by RoleBasedAuthorizationInterceptorv2) when we try to call the local EJB.
Following steps are possible to fix the problem:
1. call to SecurityActions.getSecurityContext();
2. if there is currently no SecurityContext create a new one and set it.
3. if there already is a SecurityContext set, do nothing.
4. call the mbean method.
5. only if we created the SecurityContext, we should clear it with SecurityActions.clearSecurityContext(), otherwise, do nothing.