4:49 p.m.
Hi all, esp. Darran and Stuart,
We (WildFly Camel Team) have a request [1] to support securing Camel CXF
endpoints with Elytron and I am trying to figure out the best way to
achieve that.
= Current state
A Camel context is started by Weld during
Phase.INSTALL_CDI_VALIDATOR_FACTORY. This triggers a creation of the CXF
WS endpoint. To expose the endpoint on Undertow, we create an ad hoc
DeploymentInfo [2] with a context path requested by the Camel route [3].
To handle security, users are suggested to use CXF Interceptors, such as
JAASLoginInterceptor [4]. The JAASLoginInterceptor works well with
security domains defined in the legacy Security subsystem.
= The problem
A user wants to get rid of the legacy Security subsystem and use Elytron
instead.
= How to solve it
As Darran pointed out in the chat, there is no JAAS support in Elytron
and we thus cannot keep relying on JAASLoginInterceptor & Co.
I investigated how Elytron is integrated in Undertow subsystem (esp.
UndertowDeploymentInfoService) and I tried to do the same for our custom
DeploymentInfo in Camel subsystem. The key point was to obtain a
reference to securityFunction and apply it to the DeploymentInfo. In
this way our Camel CXF endpoints indeed got protected by an Elytron
security domain.
I have a dirty but working PoC [5] where I just copied parts of
UndertowDeploymentInfoService to a new CamelDynamicDeploymentService.
I'd like to try re-using UndertowDeploymentInfoService as a whole so
that I do not duplicate the security sensitive code. But before I do,
could you Darran, Stuart and others please approve the general idea or
eventually suggest something better?
Thanks,
-- Peter
[1] https://issues.jboss.org/browse/ENTESB-7959
[2]
https://github.com/wildfly-extras/wildfly-camel/blob/6.0.0/cxfhttp/src/ma...
[3]
https://github.com/wildfly-extras/wildfly-camel/blob/6.0.0/cxfhttp/src/ma...
[4]
https://github.com/wildfly-extras/wildfly-camel-examples/blob/6.0.0/camel...
[5] https://github.com/ppalaga/wildfly-camel/commits/ENTESB-7959.180430
5:19 a.m.
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.
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.
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.
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.
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.
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.
Regards,
Darran Lofthouse.
On Wed, 2 May 2018 at 22:49 Peter Palaga <ppalaga(a)redhat.com> wrote:
Hi all, esp. Darran and Stuart,
We (WildFly Camel Team) have a request [1] to support securing Camel CXF
endpoints with Elytron and I am trying to figure out the best way to
achieve that.
= Current state
A Camel context is started by Weld during
Phase.INSTALL_CDI_VALIDATOR_FACTORY. This triggers a creation of the CXF
WS endpoint. To expose the endpoint on Undertow, we create an ad hoc
DeploymentInfo [2] with a context path requested by the Camel route [3].
To handle security, users are suggested to use CXF Interceptors, such as
JAASLoginInterceptor [4]. The JAASLoginInterceptor works well with
security domains defined in the legacy Security subsystem.
= The problem
A user wants to get rid of the legacy Security subsystem and use Elytron
instead.
= How to solve it
As Darran pointed out in the chat, there is no JAAS support in Elytron
and we thus cannot keep relying on JAASLoginInterceptor & Co.
I investigated how Elytron is integrated in Undertow subsystem (esp.
UndertowDeploymentInfoService) and I tried to do the same for our custom
DeploymentInfo in Camel subsystem. The key point was to obtain a
reference to securityFunction and apply it to the DeploymentInfo. In
this way our Camel CXF endpoints indeed got protected by an Elytron
security domain.
I have a dirty but working PoC [5] where I just copied parts of
UndertowDeploymentInfoService to a new CamelDynamicDeploymentService.
I'd like to try re-using UndertowDeploymentInfoService as a whole so
that I do not duplicate the security sensitive code. But before I do,
could you Darran, Stuart and others please approve the general idea or
eventually suggest something better?
Thanks,
-- Peter
[1] https://issues.jboss.org/browse/ENTESB-7959
[2]
https://github.com/wildfly-extras/wildfly-camel/blob/6.0.0/cxfhttp/src/ma...
[3]
https://github.com/wildfly-extras/wildfly-camel/blob/6.0.0/cxfhttp/src/ma...
[4]
https://github.com/wildfly-extras/wildfly-camel-examples/blob/6.0.0/camel...
[5] https://github.com/ppalaga/wildfly-camel/commits/ENTESB-7959.180430
10:48 a.m.
Hi Darran, thanks for the info, more inline...
On 03/05/18 12:19, Darran Lofthouse wrote:
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.
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.
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.
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.
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.
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.
WildFly Camel applications contain resources of two kinds:
(1) Resources deployed and served as usual in EE web apps (servlets,
static content, JSPs, traditional RS/WS, ...)
(2) Camel endpoints, such as CXF WS endpoints, that require special handling
There is no problem with securing (1). Everything works as expected there.
The problem we have relates exclusively to (2). I am saying this because
what you said seems to be related to (1) rather than (2) (sorry if I
misunderstood).
Let me try to explain again how the Camel CXF endpoints misfit the world
of traditional EE concepts and what we are trying to achieve.
A simple Camel route may look like this:
new RouteBuilder().from("direct:start")
.to("cxf://http://localhost:8080/webservices/my-ws")?serviceClass=...")
...
The meaning is what you'd guess: If I write something to "direct:start",
it gets routed to http://localhost:8080/webservices/my-ws.
To deploy this route on WildFly Camel, one packs the class into a war.
The war and the resulting application can be called anyhow. Let's say
ours is called "my-app.war" and you maybe already see the problem:
my-app.war gets deployed under some context path, by default /my-app,
whereas its CXF endpoints may be located outside of that path. The
endpoint in the example above has path /webservices/my-ws and there is
no common prefix with /my-app.
To be able to expose the endpoint, we cannot use any traditional means
such as servlet, because a servlet coming from my-app might only serve
paths under /my-app. We have to rely on the lower level API of Undertow.
In particular, we create a custom DeploymentInfo with the requested
context path and then we register it on Undertow.
What we'd like to achieve now is that the DeploymentInfo gets somehow
magically all security aspects configured as if it was a traditional
resource from /my-app.
I think that rather than creating the CXF endpoint DeploymentInfo from
scratch, we should try cloning the the main app's DeploymentInfo
(because that one already has the security set up properly) and
customize only the parts that are supposed to be different, most
prominently the context path. It seems to be feasible when looking at
UndertowDeploymentInfoService.
Any comments on that?
Thanks,
-- Peter
Regards,
Darran Lofthouse.
On Wed, 2 May 2018 at 22:49 Peter Palaga <ppalaga(a)redhat.com
<mailto:ppalaga@redhat.com>> wrote:
Hi all, esp. Darran and Stuart,
We (WildFly Camel Team) have a request [1] to support securing Camel
CXF
endpoints with Elytron and I am trying to figure out the best way to
achieve that.
= Current state
A Camel context is started by Weld during
Phase.INSTALL_CDI_VALIDATOR_FACTORY. This triggers a creation of the
CXF
WS endpoint. To expose the endpoint on Undertow, we create an ad hoc
DeploymentInfo [2] with a context path requested by the Camel route [3].
To handle security, users are suggested to use CXF Interceptors,
such as
JAASLoginInterceptor [4]. The JAASLoginInterceptor works well with
security domains defined in the legacy Security subsystem.
= The problem
A user wants to get rid of the legacy Security subsystem and use
Elytron
instead.
= How to solve it
As Darran pointed out in the chat, there is no JAAS support in Elytron
and we thus cannot keep relying on JAASLoginInterceptor & Co.
I investigated how Elytron is integrated in Undertow subsystem (esp.
UndertowDeploymentInfoService) and I tried to do the same for our
custom
DeploymentInfo in Camel subsystem. The key point was to obtain a
reference to securityFunction and apply it to the DeploymentInfo. In
this way our Camel CXF endpoints indeed got protected by an Elytron
security domain.
I have a dirty but working PoC [5] where I just copied parts of
UndertowDeploymentInfoService to a new CamelDynamicDeploymentService.
I'd like to try re-using UndertowDeploymentInfoService as a whole so
that I do not duplicate the security sensitive code. But before I do,
could you Darran, Stuart and others please approve the general idea or
eventually suggest something better?
Thanks,
-- Peter
[1] https://issues.jboss.org/browse/ENTESB-7959
[2]
https://github.com/wildfly-extras/wildfly-camel/blob/6.0.0/cxfhttp/src/ma...
[3]
https://github.com/wildfly-extras/wildfly-camel/blob/6.0.0/cxfhttp/src/ma...
[4]
https://github.com/wildfly-extras/wildfly-camel-examples/blob/6.0.0/camel...
[5] https://github.com/ppalaga/wildfly-camel/commits/ENTESB-7959.180430
2429
days inactive
2430
days old
2 comments
2 participants
participants (2)
-
Darran Lofthouse -
Peter Palaga