[JBEAP-16149] [GSS](7.2.z) JBREM000308: Authentication failed (no mechanisms left) when EJB invocations across servers done with programatic auth

Type: Bug
Resolution: Done
Priority: Major
Fix Version/s: 7.2.4.CR1, 7.2.4.GA
Affects Version/s: 7.1.5.GA, 7.2.0.GA
Component/s: EJB, Security
Labels:
- EAP-CD18

CDW devel_ack:
CDW docs_ack:
CDW pm_ack:
CDW qa_ack:
CDW release:
QE Test Coverage:
?
Target Release:

7.2.z.GA
Workaround Description:
Hide

Create a user on the target server for example username: 'txn-user', password: 'txn-user-pa$$w0rd'. Then you'd need to add an authentication-client to the elytron subsystem JBoss instance, see these CLI commands:

./bin/add-user.sh -a -u txn-user -p 'txn-user-pa$$w0rd'

/subsystem=elytron/authentication-configuration=ejb-auth:add(authentication-name="txn-user", credential-reference={clear-text="txn-user-pa$$w0rd"}) /subsystem=elytron/authentication-context=default:add(match-rules=[{authentication-configuration=ejb-auth}]) /subsystem=elytron:write-attribute(name=default-authentication-context,value=default)

This would result in an elytron configuration like this:

... <subsystem xmlns="urn:wildfly:elytron:1.2" default-authentication-context="default" final-providers="combined-providers" disallowed-providers="OracleUcrypto"> <authentication-client> <authentication-configuration name="ejb-auth" authentication-name="txn-user"> <credential-reference clear-text="txn-user-pa$$w0rd"/> </authentication-configuration> <authentication-context name="default"> <match-rule authentication-configuration="ejb-auth"/> </authentication-context> </authentication-client> ...
Show
Create a user on the target server for example username: 'txn-user', password: 'txn-user-pa$$w0rd'. Then you'd need to add an authentication-client to the elytron subsystem JBoss instance, see these CLI commands: ./bin/add-user.sh -a -u txn-user -p 'txn-user-pa$$w0rd' /subsystem=elytron/authentication-configuration=ejb-auth:add(authentication-name= "txn-user" , credential-reference={clear-text= "txn-user-pa$$w0rd" }) /subsystem=elytron/authentication-context= default :add(match-rules=[{authentication-configuration=ejb-auth}]) /subsystem=elytron:write-attribute(name= default -authentication-context,value= default ) This would result in an elytron configuration like this: ... <subsystem xmlns= "urn:wildfly:elytron:1.2" default -authentication-context= " default " final -providers= "combined-providers" disallowed-providers= "OracleUcrypto" > <authentication-client> <authentication-configuration name= "ejb-auth" authentication-name= "txn-user" > <credential-reference clear-text= "txn-user-pa$$w0rd" /> </authentication-configuration> <authentication-context name= " default " > <match-rule authentication-configuration= "ejb-auth" /> </authentication-context> </authentication-client> ...
Steps to Reproduce:

Hide

*Take EAP 7.2
unzip -d $JBOSS_HOME/ eap72-reproducer-overlay.zip
./start1.sh
./start2.sh
./test.sh*
------
To run the 2nd reproducer jbeap-13963-reproducer.jar, setup eap72-reproducer-overlay.zip and then deploy the 2nd reproducer:
Deploy jbeap-13963-reproducer.jar to standalone and standalone2 from eap72-reproducer-overlay.zip
java -cp ./jbeap-13963-reproducer.jar:$JBOSS_HOME/bin/client/jboss-client.jar:$JBOSS_HOME/bin/client/jboss-cli-client.jar client.Client

Show
*Take EAP 7.2 unzip -d $JBOSS_HOME/ eap72-reproducer-overlay.zip ./start1.sh ./start2.sh ./test.sh* ------ To run the 2nd reproducer jbeap-13963-reproducer.jar, setup eap72-reproducer-overlay.zip and then deploy the 2nd reproducer: Deploy jbeap-13963-reproducer.jar to standalone and standalone2 from eap72-reproducer-overlay.zip java -cp ./jbeap-13963-reproducer.jar:$JBOSS_HOME/bin/client/jboss-client.jar:$JBOSS_HOME/bin/client/jboss-cli-client.jar client.Client

SFDC Cases Counter:
SFDC Cases Open:
SFDC Cases Links:

standalone client -> EAP1 EJB1 -> EAP2 EJB2

EAP1 fails when trying to finish the transaction with this error below, because it lost the authentication context. The EJB clients are using the WildFlyInitialContextFactory lookup approach.

This issue is similar to ~~JBEAP-15738~~ , except ~~JBEAP-15738~~ was server to server config via remote outbound connections configured in the JBoss profile instead of WildFlyInitialContextFactory approach.

public static Context getInitialContext(String host, Integer port, String username, String password)  throws NamingException {
   Properties props = new Properties();
   props.put(Context.INITIAL_CONTEXT_FACTORY,  "org.wildfly.naming.client.WildFlyInitialContextFactory");
   props.put(Context.PROVIDER_URL, String.format("%s://%s:%d", "remote+http", host, port));
   if(username != null && password != null) {
      props.put(Context.SECURITY_PRINCIPAL, username);
      props.put(Context.SECURITY_CREDENTIALS, password);
    }
   return new InitialContext(props);
}

Exception in thread "main" javax.ejb.EJBTransactionRolledbackException: javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.
  at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:114)
  at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:261)
  at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:362)
  at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:144)
  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
  at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
  at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
  at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
  at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
  at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
...
Caused by: javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.
  at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1300)
  at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
  at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
  at org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:77)
  at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:71)
  at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:88)
  ... 41 more
Caused by: org.wildfly.transaction.client.SynchronizationException: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation
  at org.wildfly.transaction.client.XAOutflowedResources$1.beforeCompletion(XAOutflowedResources.java:76)
  at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:236)
  at org.wildfly.transaction.client.AbstractTransaction.performConsumer(AbstractTransaction.java:247)
  at org.wildfly.transaction.client.AbstractTransaction$AssociatingSynchronization.beforeCompletion(AbstractTransaction.java:292)
  at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
  at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:360)
  at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91)
  at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
  at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1288)
  ... 46 more
Caused by: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation
  at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentityXA(RemotingRemoteTransactionPeer.java:94)
  at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer$1.beforeCompletion(RemotingRemoteTransactionPeer.java:166)
  at org.wildfly.transaction.client.SubordinateXAResource.beforeCompletion(SubordinateXAResource.java:143)
  at org.wildfly.transaction.client.XAOutflowedResources$1.beforeCompletion(XAOutflowedResources.java:73)
  ... 54 more
Caused by: org.wildfly.security.auth.AuthenticationException: JBREM000308: Authentication failed (no mechanisms left), tried: (none)
  at org.jboss.remoting3.ConnectionPeerIdentityContext.doAuthenticate(ConnectionPeerIdentityContext.java:368)
  at org.jboss.remoting3.ConnectionPeerIdentityContext.authenticate(ConnectionPeerIdentityContext.java:174)
  at org.jboss.remoting3.EndpointImpl$3.handleDone(EndpointImpl.java:506)
  at org.jboss.remoting3.EndpointImpl$3.handleDone(EndpointImpl.java:495)
  at org.xnio.IoFuture$HandlingNotifier.notify(IoFuture.java:208)
  at org.xnio.AbstractIoFuture$NotifierRunnable.run(AbstractIoFuture.java:720)
  at org.xnio.IoUtils$2.execute(IoUtils.java:71)
  at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:693)
  at org.xnio.AbstractIoFuture$CompleteState.withNotifier(AbstractIoFuture.java:132)
  at org.xnio.AbstractIoFuture.addNotifier(AbstractIoFuture.java:570)
  at org.jboss.remoting3.EndpointImpl.doGetConnection(EndpointImpl.java:495)
  at org.jboss.remoting3.EndpointImpl.getConnectedIdentity(EndpointImpl.java:434)
  at org.jboss.remoting3.UncloseableEndpoint.getConnectedIdentity(UncloseableEndpoint.java:52)
  at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentity(RemotingRemoteTransactionPeer.java:87)
  at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getPeerIdentityXA(RemotingRemoteTransactionPeer.java:92)
  ... 57 more

- - Sort By Name
  - Sort By Date
  - Ascending
  - Descending
  - Thumbnails
  - List
  - Download All

eap72-reproducer-overlay.zip
26 kB
2019/01/14 12:54 PM
jbeap-13963-reproducer.jar
7 kB
2019/01/10 4:34 PM
logs.zip
14 kB
2019/01/10 4:36 PM

clones

WFLY-9896 Server-server EJB transactional invocation rolls back if stateful bean is used and JBOSS-LOCAL-USER auth is not possible

Closed

incorporates

EJBCLIENT-340 Ensure any AuthenticationContext associated with the invocation is propagated to the transaction call.

Resolved

WFTC-71 Ensure the current AuthenticationContext is captured by the SubordinateXAResource.

Resolved

is duplicated by

JBEAP-16651 [GSS](7.2.z) Transactional remote-outbound-connection to an older version results in an ARJUNA016045 WARN message

Closed

is related to

JBEAP-13963 [GSS](7.1.z) Server-server EJB transactional invocation rolls back if stateful bean is used and JBOSS-LOCAL-USER auth is not possible

Closed

JBEAP-15738 [GSS](7.2.z) Server-server EJB transactional invocation rolls back if stateful bean is used and JBOSS-LOCAL-USER auth is not possible

Closed

relates to

JBEAP-17120 [GSS](7.2.z) Server-server EJB transactional invocation rolls back if MDB call remote EJB and JBOSS-LOCAL-USER auth is not possible

Closed

JBEAP-17349 [GSS](7.2.z) EJB Recovery unable to authenticate when restarted server is trying to recover ejb xa transactions

Closed

JBEAP-18310 [GSS](7.4.z) EJB Recovery unable to authenticate when restarted server is trying to recover ejb xa transactions

Closed

links to

KCS

(1 is related to, 3 relates to, 1 links to)

Michaela Osmerova added a comment - 2024/08/28 2:44 PM

Moving verified issues to closed.

Michaela Osmerova added a comment - 2024/08/28 2:44 PM Moving verified issues to closed.

Daniel Cihak added a comment - 2019/09/24 3:49 AM

Verified with EAP 7.2.4.CP-CR2.

Daniel Cihak added a comment - 2019/09/24 3:49 AM Verified with EAP 7.2.4.CP-CR2.

Darran Lofthouse added a comment - 2019/02/07 6:53 AM

At the moment I believe this issue is likely the same as https://issues.jboss.org/browse/JBEAP-13963

I believe in both cases the properties passed to the InitialContext are used to configure an AuthenticationConfiguration and AuthenticationContext which is used for both the Naming invocation and the EJB invocation but we have skipped re-using for the transaction client invocations - I have some hacked changes linked from ~~JBEAP-13963~~ capturing the AuthenticationContext and using it for the transaction client calls as well.

Darran Lofthouse added a comment - 2019/02/07 6:53 AM At the moment I believe this issue is likely the same as https://issues.jboss.org/browse/JBEAP-13963 I believe in both cases the properties passed to the InitialContext are used to configure an AuthenticationConfiguration and AuthenticationContext which is used for both the Naming invocation and the EJB invocation but we have skipped re-using for the transaction client invocations - I have some hacked changes linked from JBEAP-13963 capturing the AuthenticationContext and using it for the transaction client calls as well.

Assignee:: Darran Lofthouse

Reporter:: Brad Maxwell

Votes:: 0 Vote for this issue

Watchers:: 14 Start watching this issue

Created:: 2019/01/10 4:33 PM

Updated:: 2024/08/28 2:44 PM

Resolved:: 2019/08/06 12:07 PM

Details

Description

Attachments

Attachments

Issue Links

Easy Agile Planning Poker

Activity

Collapse comment: Michaela Osmerova added a comment - 2024/08/28 2:44 PM

Expand comment: Michaela Osmerova added a comment - 2024/08/28 2:44 PM

Collapse comment: Daniel Cihak added a comment - 2019/09/24 3:49 AM

Expand comment: Daniel Cihak added a comment - 2019/09/24 3:49 AM

Collapse comment: Darran Lofthouse added a comment - 2019/02/07 6:53 AM

Expand comment: Darran Lofthouse added a comment - 2019/02/07 6:53 AM

People

Dates