<div dir="ltr">I think on this one it is worth starting with some of the history and then some of the planned next steps as overall I think anything developed here should consider how we plan to evolve the configuration.<div><br></div><div>At the time we added WildFly Elytron it was a new security solution for the application server, all deployments that already existed would be using PicketBox based security so we wanted a solution that would allow the existing deployments to continue to work 'as-is' whilst allowing new deployments to make use of WildFly Elytron and to allow administrators the choice to migrate their deployments to WildFly Elytron. This is the reason we added mappings to both the EJB and Undertow subsystems, if we don't match on a mapping then assume they want PicketBox, if we do match on a mapping apply Elytron based security.</div><div><br></div><div>There is one gap in this mapping that is likely to be changing soon, presently the mapping only maps to a http-authentication-factory - for a change I am in the process of making, for the Web Services integration and I assume your integration this factory is not really required - in general these type of integrations only require the SecurityDomain. So that is one change I plan to make, the mapping could specify a SecurityDomain instead of the http-authentication-factory.</div><div><br></div><div>The SecurityDomain is already automatically associated with the ClassLoader of the deployment but we could reach a point in the future where if the domain is available it is attached to the DeploymentInfo so if something else wants to make use of it it just needs to check if it is attached - we could still add some of our handlers such as the one to associate the flexible identity.</div><div><br></div><div>At a slightly later point I do also need to look at how we can active the Elytron integration without requiring the mapping, I don't know if this would be using the existing elements and annotations or if we would want something specifically related to Elytron so that would need to be a later discussion.</div><div><br></div><div>But overall at this stage I wonder if we would be better to ensure we are dealing with attachments to the DeploymentInfo rather than getting too tightly tied to the application security domain mappings which is something we know will need to evolve further possibly to the point it is eliminated.</div><div><br></div><div>Regards,</div><div>Darran Lofthouse.</div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 2 May 2018 at 22:49 Peter Palaga <<a href="mailto:ppalaga@redhat.com" target="_blank">ppalaga@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all, esp. Darran and Stuart,<br>
<br>
We (WildFly Camel Team) have a request [1] to support securing Camel CXF <br>
endpoints with Elytron and I am trying to figure out the best way to <br>
achieve that.<br>
<br>
= Current state<br>
<br>
A Camel context is started by Weld during <br>
Phase.INSTALL_CDI_VALIDATOR_FACTORY. This triggers a creation of the CXF <br>
WS endpoint. To expose the endpoint on Undertow, we create an ad hoc <br>
DeploymentInfo [2] with a context path requested by the Camel route [3].<br>
<br>
To handle security, users are suggested to use CXF Interceptors, such as <br>
JAASLoginInterceptor [4]. The JAASLoginInterceptor works well with <br>
security domains defined in the legacy Security subsystem.<br>
<br>
= The problem<br>
<br>
A user wants to get rid of the legacy Security subsystem and use Elytron <br>
instead.<br>
<br>
= How to solve it<br>
<br>
As Darran pointed out in the chat, there is no JAAS support in Elytron <br>
and we thus cannot keep relying on JAASLoginInterceptor & Co.<br>
<br>
I investigated how Elytron is integrated in Undertow subsystem (esp. <br>
UndertowDeploymentInfoService) and I tried to do the same for our custom <br>
DeploymentInfo in Camel subsystem. The key point was to obtain a <br>
reference to securityFunction and apply it to the DeploymentInfo. In <br>
this way our Camel CXF endpoints indeed got protected by an Elytron <br>
security domain.<br>
<br>
I have a dirty but working PoC [5] where I just copied parts of <br>
UndertowDeploymentInfoService to a new CamelDynamicDeploymentService.<br>
<br>
I'd like to try re-using UndertowDeploymentInfoService as a whole so <br>
that I do not duplicate the security sensitive code. But before I do, <br>
could you Darran, Stuart and others please approve the general idea or <br>
eventually suggest something better?<br>
<br>
Thanks,<br>
<br>
-- Peter<br>
<br>
[1] <a href="https://issues.jboss.org/browse/ENTESB-7959" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/ENTESB-7959</a><br>
[2] <br>
<a href="https://github.com/wildfly-extras/wildfly-camel/blob/6.0.0/cxfhttp/src/main/java/org/apache/cxf/transport/undertow/wildfly/WildflyHTTPServerEngine.java#L64" rel="noreferrer" target="_blank">https://github.com/wildfly-extras/wildfly-camel/blob/6.0.0/cxfhttp/src/main/java/org/apache/cxf/transport/undertow/wildfly/WildflyHTTPServerEngine.java#L64</a><br>
[3] <br>
<a href="https://github.com/wildfly-extras/wildfly-camel/blob/6.0.0/cxfhttp/src/main/java/org/apache/cxf/transport/undertow/wildfly/WildflyHTTPServerEngine.java#L66" rel="noreferrer" target="_blank">https://github.com/wildfly-extras/wildfly-camel/blob/6.0.0/cxfhttp/src/main/java/org/apache/cxf/transport/undertow/wildfly/WildflyHTTPServerEngine.java#L66</a><br>
[4] <br>
<a href="https://github.com/wildfly-extras/wildfly-camel-examples/blob/6.0.0/camel-cxf-jaxws-cdi-secure/src/main/java/org/wildfly/camel/examples/cxf/jaxws/Application.java#L112" rel="noreferrer" target="_blank">https://github.com/wildfly-extras/wildfly-camel-examples/blob/6.0.0/camel-cxf-jaxws-cdi-secure/src/main/java/org/wildfly/camel/examples/cxf/jaxws/Application.java#L112</a><br>
[5] <a href="https://github.com/ppalaga/wildfly-camel/commits/ENTESB-7959.180430" rel="noreferrer" target="_blank">https://github.com/ppalaga/wildfly-camel/commits/ENTESB-7959.180430</a><br>
</blockquote></div></div>