Bug 1032188 - Security context associated with EJB asynchronous invocations can potentially be corrupted over time by the caller thread
Security context associated with EJB asynchronous invocations can potentially...
Status: CLOSED DUPLICATE of bug 1005093
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: EJB, Security (Show other bugs)
6.1.1
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: David M. Lloyd
Jan Martiska
Russell Dickenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-19 11:59 EST by wfink
Modified: 2013-11-19 12:38 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-19 12:38:15 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker WFLY-2016 Major Resolved Security context associated with EJB asynchronous invocations can potentially be corrupted over time by the caller threa... 2014-01-07 18:58:35 EST

  None (edit)
Description wfink 2013-11-19 11:59:26 EST
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 12:38:15 EST

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

Note You need to log in before you can comment on or make changes to this bug.