]
Farah Juma updated WFCORE-3149:
-------------------------------
Fix Version/s: 3.0.0.CR1
Use "remote+http" as the default protocol for an Elytron
remote outbound connection if no protocol is specified in the resolved
AuthenticationConfiguration
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Key: WFCORE-3149
URL:
https://issues.jboss.org/browse/WFCORE-3149
Project: WildFly Core
Issue Type: Bug
Components: Security
Reporter: Farah Juma
Assignee: Farah Juma
Priority: Blocker
Fix For: 3.0.0.CR1
Here's a description of the problem from [~sguilhen]:
{quote}
Farah Juma Not sure if this is relevant but do you remember a quick chat we had about a
month ago when I was converting this QS and I was getting a $local identity when
IntermediateEJB attempted to invoke the SecuredEJB? No matter what I did in terms of
configuration I was getting $local even if I used a sasl-mech-selector that explicitly
defined DIGEST-MD5 as the only mech.
I found another sample app that was working correctly and the only difference was that
the intermediate EJB was injecting the reference to the remote EJB instead of doing a
lookup. So I've changed the QS to inject the reference to the SecuredEJB in the
IntermediateEJB and it started working. I don't know if this has anything to do with
the current issue but I was also getting the $local identity when running this QS.
{quote}
The problem occurs for EJB invocations from a remote server when doing a lookup using a
PROVIDER_URL when no protocol is set on the {{AuthenticationConfiguration}} that should be
used for the remote EJB invocation. In particular, in
{{RemoteOutboundConnectionService#start}} when an {{AuthenticationContext}} is specified
for a remote outbound connection and no protocol is set on the resolved
{{AuthenticationConfiguration}}, we currently use "http-remoting" as the default
protocol when constructing the destination URI. In
{{EjbClientContextSetupProcessor.RegistrationService#transformOne}}, we create an
{{AuthenticationContext}} with a rule that attempts to match on "http-remoting".
However, because the {{InitialContext}} is created using
"remote+http://localhost:8080" as the PROVIDER_URL, our rule doesn't match
this PROVIDER_URL, so the desired {{AuthenticationConfiguration}} doesn't actually get
used. We could update {{RemoteOutboundConnectionService#start}} so that
"remote+http" is used as the default protocol instead of the
"http-remoting" protocol when no protocol is set on
{{AuthenticationConfiguration}} that is resolved for an Elytron remote outbound
connection.