[
https://issues.apache.org/jira/browse/DOSGI-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490277#comment-15490277
]
Christian Schneider commented on DOSGI-182:
-------------------------------------------
I do not fully understand how this could work. The filter chain is built from
OSGi services. So you can not guarantee any order.
The only way I could imagine is to execute the CXF service as a filter and have
a filter before to set the context and another one after to delete it.
This would require a completely different mechanics though.
What do you use spring security for? Maybe CXF provides something for your case
already.
> SecurityContext populated by spring security made available to CXF
> ------------------------------------------------------------------
>
> Key: DOSGI-182
> URL: https://issues.apache.org/jira/browse/DOSGI-182
> Project: CXF Distributed OSGi
> Issue Type: Wish
> Affects Versions: 1.4.0
> Reporter: Isart
> Fix For: 1.9.0
>
>
> I'd like SecurityContext populated by SpringSecurity filter chain to be
> available in CXF, and also being available to registered services.
> I've been able to apply a SpringSecurity filter chain to JAX-RS services
> published with DOSGi by instantiating my filter chain bean and registering it
> as an
> osgi service with "org.apache.cxf.httpservice.filter" property.
> This filter chain populates SecurityContext but also removes it when the
> filter chain finishes.
> org.apache.cxf.dosgi.dsw.handlers.SecurityDelegatingHttpContext is
> responsible of handling the filter for DOSGi registered web services.
> When a request comes, the filter chain finishes before normal request
> processing in CXF takes place, resulting in SecurityContext not being
> available in CXF nor in registered web services.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
