[jboss-jira] [JBoss JIRA] (WFLY-8772) Deployments referencing outbound connection with authentication context always use Elytron default-authentication-context
Farah Juma (JIRA)
issues at jboss.org
Mon May 15 15:57:00 EDT 2017
[ https://issues.jboss.org/browse/WFLY-8772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406569#comment-13406569 ]
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)
More information about the jboss-jira
mailing list