Bug 1201439 - [GSS] (6.4.z) RemotingContext should be copied for async EJB calls
Summary: [GSS] (6.4.z) RemotingContext should be copied for async EJB calls
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: EJB
Version: 6.4.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: CR2
: EAP 6.4.1
Assignee: baranowb
QA Contact: Jan Martiska
Depends On:
Blocks: eap641-payload
TreeView+ depends on / blocked
Reported: 2015-03-12 17:23 UTC by Derek Horton
Modified: 2019-07-11 08:46 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2017-01-17 09:57:53 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker WFLY-4415 0 Major Closed RemotingContext should be copied for async EJB calls 2018-01-11 19:41:35 UTC

Description Derek Horton 2015-03-12 17:23:35 UTC
Description of problem:

The RemotingContext should be copied for async EJB calls.

This can cause Asynchronous EJB invocations to fail when the EJB is protected by a security-domain that uses the RemotingLoginModule for authentication.

client --> nodeX --- (remoting) --> nodeY (Asyc Method)

The asynch ejb calls are started by a stateless ejb on nodeY.  The RemotingLoginModule is handling the authentication for the node X to node Y EJB invocations.

This normally works fine.

However, this appears to fail when there is a JAAS cache miss by the thread that is carrying out the asynchronous invocation.  At that point, the login module stack will be invoked again, but the RemotingLoginModule will fail to authenticate the user since the async thread doesn't have the context to authenticate the user (SecurityActions.remotingContextGetConnection() returns null which causes the login module to return false from the login() method).  This authentication failure will result in the Invalid User error when the call reaches the EJB layer.

Comment 1 Derek Horton 2015-03-12 18:16:04 UTC
PR:  https://github.com/jbossas/jboss-eap/pull/2350

Comment 2 Derek Horton 2015-03-13 14:54:31 UTC
I updated the pull request:
PR:  https://github.com/jbossas/jboss-eap/pull/2350

I tested this change on EAP 6.3.3 and it resolves the issue.

Comment 4 Rostislav Svoboda 2015-04-23 13:42:07 UTC
Please provide test (as discussed with Carlo) to include this in CP01 payload.
I will qa_ack afterwards.

Comment 5 Ivo Studensky 2015-04-24 12:22:33 UTC
PR with a test-case:

Comment 6 Ivo Studensky 2015-04-24 12:31:35 UTC
Created another PR, the previous one was filed against a wrong target branch.


Comment 7 Rostislav Svoboda 2015-04-27 11:20:05 UTC
qa_acking, thank you for the test

Comment 9 Jan Martiska 2015-05-15 08:14:51 UTC
Verified in EAP 6.4.1.CR2.

Comment 10 Petr Penicka 2017-01-17 09:57:53 UTC
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.

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