[jboss-jira] [JBoss JIRA] (WFCORE-4668) Transaction recovery of remote ejb calls should not be using static Default AuthenticationContext
Ondrej Chaloupka (Jira)
issues at jboss.org
Tue Jul 21 11:10:00 EDT 2020
[ https://issues.redhat.com/browse/WFCORE-4668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14272614#comment-14272614 ]
Ondrej Chaloupka commented on WFCORE-4668:
------------------------------------------
hi [~mshikalw], I assume this is still issue. The trouble is that if authentication for remote EJB calls is used and transaction propagation happens then the recovery does not work properly until there is explicitly created a user with password for recovery processing. The user has to be created on the remote jboss node and the caller then defines the descriptor via `-Dwildfly.config.url`.
Unfortunately there is no easy standalone reproducer. The reason why this issue was created is the need for OpenShift configuration to define hardcoded user/password for any WFLY server which calls another server. This can be checked on OpenShift and WildFly s2i image.
For standalone reproducer - as I would check it - it could be to take a WFLY calling the other WFLY and disable silent authentication - forcing the remote call to use the authentication even the both WFLY servers are running on the local machine.
I think that the starting point could be the quickstart: https://github.com/wildfly/quickstart/blob/master/ejb-remote/
There is need to disable silent authentication (https://github.com/wildfly/quickstart/blob/20.0.0.Final/ejb-remote/client/src/main/resources/META-INF/wildfly-config.xml#L30).
If this all works then it's needed to create have an unfinished transaction on the second server (the server side) and check recovery to be started. There could be seen the failure until the specific setup of global default credentials are made.
Another chance could be to use the EAP QE crashrec test (https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/tests-transactions) where wildfly-config.xml would not be defined.
> Transaction recovery of remote ejb calls should not be using static Default AuthenticationContext
> -------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4668
> URL: https://issues.redhat.com/browse/WFCORE-4668
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.0.0.Beta9
> Reporter: Ondrej Chaloupka
> Priority: Critical
>
> The issue WFCORE-4599 removed the `AuthenticationContext` would be static. This started to cause troubles for transaction recovery processing when remote ejb calls are invoked.
> The configuration that was used earlier for server to server ejb calls[1] (used with `-Dwildfly.config.url`) stopped working.
> It was possible to configure the default authentication context in the `standalone.xml` for the whole elytron subsystem (in way like [2]). But this change started to cause threads being stuck on execution of remote ejb calls in WFTC (somewhere here [3]).
> Because of that the WFCORE-4659 reverted back the functionality of static global authentication context. This was rather a bit workaround as the functionality should be rather working as Stuart pointed out
> {quote}
> - Add an explicit config to specify the authentication context used by transaction recovery
> - If this is not set fall back to the default authentication context that is used by deployments
> - If none of the above are set then the auth context should be empty
> {quote}
> [1]
> {code}
> <configuration>
> <authentication-client xmlns="urn:elytron:1.0">
> <authentication-rules>
> <rule use-configuration="jta">
> <match-abstract-type name="jta" authority="jboss"/>
> </rule>
> </authentication-rules>
> <authentication-configurations>
> <configuration name="jta">
> <sasl-mechanism-selector selector="DIGEST-MD5"/>
> <providers>
> <use-service-loader />
> </providers>
> <set-user-name name="ejb"/>
> <credentials>
> <clear-password password="ejb"/>
> </credentials>
> <set-mechanism-realm name="ApplicationRealm" />
> </configuration>
> </authentication-configurations>
> </authentication-client>
> </configuration>
> {code}
> [2]
> {code}
> <subsystem xmlns="urn:wildfly:elytron:8.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto" default-authentication-context="jta">
> <authentication-client>
> <authentication-configuration name="jta" authentication-name="ejb" realm="ApplicationRealm" sasl-mechanism-selector="DIGEST-MD5">
> <credential-reference clear-text="ejb"/>
> </authentication-configuration>
> <authentication-context name="jta">
> <match-rule match-abstract-type-authority="jboss" authentication-configuration="jta"/>
> </authentication-context>
> </authentication-client>
> {code}
> [3] https://github.com/wildfly/wildfly-transaction-client/blob/master/src/main/java/org/wildfly/transaction/client/provider/remoting/RemotingRemoteTransactionPeer.java#L84
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
More information about the jboss-jira
mailing list