[
https://issues.jboss.org/browse/WFLY-8772?page=com.atlassian.jira.plugin....
]
Farah Juma commented on WFLY-8772:
----------------------------------
As mentioned in chat, here's what was happening for the legacy ROC case:
1) In RemoteOutboundConnectionService#start, we specify the username that was configured
in the legacy ROC when creating the destination URI (previously, we didn't specify the
username when constructing this URI).
2) In EjbClientContextSetupProcessor.RegistrationService#transformOne, when building up a
match rule for the destination URI from the ROC, we ensure that we match on any user info
present in the destination URI (i.e., rule.matchUser(userInfo))
3) To determine the AuthenticationConfiguration to use for EJBClientInvocationContext in
EJBInvocationHandler#invoke, we use
AuthenticationContextConfigurationClient#getAuthenticationConfiguration if there is no
sticky authentication configuration present. I looked at what's happening in
AuthenticationContextConfigurationClient#getAuthenticationConfiguration. The
AuthenticationContext is actually correct at this point. However, the URI that is passed
to AuthenticationContextConfigurationClient#getAuthenticationConfiguration does not have
any user info on it. Thus, the rule that we built up doesn't match this URI and so the
AuthenticationConfiguration that corresponds to the user defined in the ROC won't get
used.
We should no longer attempt to match on the user info for the destination URI for a remote
outbound connection.
For the Elytron ROC case, where no username is meant to be specified on the ROC, we were
erroneously treating the username as the string "undefined" and then attempting
to match on the user "undefined".
Deployments referencing outbound connection with authentication
context always use Elytron default-authentication-context
-------------------------------------------------------------------------------------------------------------------------
Key: WFLY-8772
URL:
https://issues.jboss.org/browse/WFLY-8772
Project: WildFly
Issue Type: Bug
Components: Remoting, Security
Reporter: Farah Juma
Assignee: Farah Juma
Priority: Blocker
Labels: eap7.1-rfe-blocker, eap7.1-rfe-failure, eap71_beta_candidate
Analysis document for EAP7-551 states the following:
{quote}This RFE is to add a reference to the new authentication-context capability to the
remote-outbound-connection resource and make use of it satisfy the security requirements
for the outbound connections being established.
The AuthenticationContext will be used to access both information required for
authentication and also for any SSLContext required for the connection.
A newly referenced authentication-context will be used to provide all security
configuration for outbound connections.{quote}
However, currently the remoting outbound connections will only use Elytron default
authentication context and ignore authentication context defined in remoting outbound
connection resource:
* If no default authentication context is defined in Elytron subsystem but remote
outbound connection has defined one, no authentication context is associated with remote
outbound connection.
* If the default authentication context is defined in Elytron subsystem but no
authentication context is defined in remote outbound connection, remoting assumes that
outbound connection uses legacy security.
* If the default authentication context is defined in Elytron subsystem and different
authentication context is defined in remote outbound connection, the remote outbound
connection will use the Elytron subsystem default none the less.
* The authentication context defined in outbound remote connection will only work if it
is the same as default authentication context in Elytron subsystem.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)