Bug 1032188

Summary: Security context associated with EJB asynchronous invocations can potentially be corrupted over time by the caller thread
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: wfink
Component: EJB, SecurityAssignee: David M. Lloyd <david.lloyd>
Status: CLOSED DUPLICATE QA Contact: Jan Martiska <jmartisk>
Severity: high Docs Contact: Russell Dickenson <rdickens>
Priority: unspecified    
Version: 6.1.1   
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-19 17:38:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description wfink 2013-11-19 16:59:26 UTC
When an @Asynchronous EJB call is performed, the security context is propagated to the thread handling the asynchronous call. When authentication is required in the asynchronous call (e.g. @RolesAllowed) this is handled by the JBossCachedAuthenticationManager. Thus there is usually no call to the LoginModule. However, when the JBossCachedAuthenticationManager has given up the corresponding cache entry, there is a call to the LoginModule. The LoginModule however, cannot access the ServletRequest via the PolicyContext and fails.

We've experienced this behavior in two situation:
- The user logs out, while @Asynchronous call is still running.
- The cache maintained by the JBossCachedAuthenticationManager exceeds it's limits and cached entries are removed.

The expected behaviour is that the original security context (attributes) are copied over to the async invocation and updates to that security context later on in a separate thread shouldn't affect the ongoing async EJB invocation.

Comment 1 wfink 2013-11-19 17:38:15 UTC

*** This bug has been marked as a duplicate of bug 1005093 ***