Hi Isart
On 16/05/13 12:08, Isart Canyameres wrote:
Dear Sergey,
A sample code where this behaviour is shown can be found in my git repo:
https://github.com/isartcanyameres/HelloDOSGiSpringSecurity
commit 96dee437e77f (now in branch feature/acl)
However, this is far from being the test bundle you asked for.
Let's see if I find the time for building it.
Thanks for your effort so far. One thing I can tell is that I will look
into this issue in time for DOSGi 1.5 release or earlier, right now I'm
working with JAX-RS TCK tests and I have a number of other old/pending
issues, which I hope mostly address before I go on holidays starting
from 27th; realistically, I will start looking at DOSGi issues assigned
to me from the week starting 4th June...
Sorry for a bit of delay on that, perhaps it will give you some time to
prepare a test bundle :-), though may be it will save you the time if I
simply work with the existing security_filter demo, I can probably can
modify it a bit to ensure that the filter actually affects somehow what
the service endpoint sees
Many thanks, Sergey
Kind regards,
Isart
On 15/05/13 17:43, Sergey Beryozkin wrote:
Hi Isaart
On 15/05/13 16:02, Isart Canyameres wrote:
Hi again,
Please find links to created issues just below.
https://issues.apache.org/jira/browse/DOSGI-183
https://issues.apache.org/jira/browse/DOSGI-182
Please, feel free to update them upon need.
Thanks for your thoughts on it, looks like getting two filter chains
links as you suggested originally would be the best way forward.
Copying SecurityContext is also an option/workaround.
If you can provide a test bundle (which can be loaded into DOSGi 1.4
or 1.5-SMAPSHOT), that would help to reproduce, though we have a basic
demo too involving the filters.
As a side note, have a look at few CXF interceptors. If the goal is to
authenticate & then enforce RBAC, then CXF JAASLoginInterceptor will
do the 1st task assuming JAAS context is available and
SimpleAuthorizingInterceptor will do the 2nd one, it can even be
configured to check Spring Secured annotations.
Thanks, Sergey
Kind regards,
Isart
On 15/05/13 16:37, Isart Canyameres wrote:
Hi Sergey,
Thank you so much for taking the time for reading and even more for
your answer.
You guessed well, I'm trying to get the SecurityContext (which is
populated by the filter chain) made available to my service. More
precisely, I'd like it to be available in a method invocation security
interceptor protecting the service (it's not a CXF interceptor but a
Spring Security "interceptor":
org.springframework.security.access.intercept.aopalliance.MethodSecurityInterceptor).
This MethodSecurityInterceptor is called from
org.apache.cxf.interceptor.ServiceInvokerInterceptor. So, in short,
I'd like SecurityContext to be available in CXF, but also passed to my
service.
However, SpringSecurity filters setting the context do clear it when
the rest of the chain has finished, as explained here:
http://static.springsource.org/spring-security/site/docs/3.1.x/reference/core-web-filters.html#security-context-persistence-filter
Unfortunately, this fact leaves us with few options for keeping the
context available in CXF.
* The one I suggested is having the possibility to create a filter
chain that links to request handling in CXF (notice that this
solution is not linked to Spring Security at all, although pushed
by an issue related to it). I was not sure if this possibility
existed today, although I understand from your answer that there
is no such thing in any currently available version of DOSGi.
* An other possibility I can think of is serializing the
SecurityContext somewhere in the servlet request (inside the
custom filterChain), and retrieve this information in CXF
in-interceptor-chain (with a custom InInterceptor). I have to
admit that I find myself uncomfortable with this solution, but I
may play with it. It may serve as a workaround if I'm successful.
* There will likely be other solutions I haven't seen. So if anyone
comes with one, I would be grateful to know.
I'll create a JIRA issue with this and let you know.
Thank you again,
Isart
On 15/05/13 14:28, Sergey Beryozkin wrote:
Hi Isart
On 15/05/13 11:14, Isart Canyameres wrote:
Dear members of the CXF community,
I'm trying to add a filter chain to a DOSGi published JAX-RS web
service.
I'm trying it by instantiating my filter chain bean and
registering an
osgi service with "org.apache.cxf.httpservice.filter" property.
The filer chain is successfully registered, but I have following
issue:
I want my filter chain to be linked to the normal processing of the
request,
that is, last filter in the filter chain triggering normal processing
(leading to service invocation happening during filter chain
execution).
Instead, I see the filter chain completes its execution before normal
processing begins.
How can I achieve desired behaviour?
It appears a new enhancement will have to go in. Can you give me a
favor and create a JIRA issue targeted for DOSGi 1.5 ?
I'm not even sure that we need to get CXF chain running as part of
(Spring Security) filter chain, rather we probably need to get
SecurityContext populated by Spring made available to CXF, is it what
you are actually after ?
Thanks, Sergey
Thank you in advance,
Isart
Following log entries appear for an incoming request:
12:33:43,587 DEBUG | eResources | etty.internal.HttpServiceContext |
Handling request for [/sample/generateResources] using http context
[org.apache.cxf.dosgi.dsw.handlers.SecurityDelegatingHttpContext@1a445dcf]
12:33:43,592 INFO | eResources | che.cxf.dosgi.dsw.handlers.Chain |
doFilter() on FilterChainProxy[ UrlMatcher =
org.springframework.security.web.util.AntUrlPathMatcher[requiresLowerCase='true'];
Filter Chains:
{/**=[org.springframework.security.web.context.SecurityContextPersistenceFilter@79ed3030,
org.springframework.security.web.authentication.www.BasicAuthenticationFilter@42f6ddd9,
org.springframework.security.web.access.ExceptionTranslationFilter@5d5ef3e7,
org.springframework.security.web.access.intercept.FilterSecurityInterceptor@4def295]}]
---------------------------------------------------------------------------------------------------------------------
PROCESSING OF THE FILTER CHAIN - All filters finish execution of
doFilter() method
---------------------------------------------------------------------------------------------------------------------
12:35:02,194 DEBUG | eResources | nsport.servlet.ServletController |
Service http request on thread: Thread[qtp516740701-71 -
/sample/generateResources,5,Configuration Admin Service]
12:35:02,195 DEBUG | eResources | ort.http.AbstractHTTPDestination |
Create a new message for processing
12:35:02,225 DEBUG | eResources | pache.cxf.transport.http.Headers |
Request Headers: {Accept=[*/*], Authorization=[Basic AAA],
Content-Type=[null], Host=[localhost:8080], User-Agent=[curl/7.21.3
(x86_64-pc-linux-gnu) libcurl/7.21.3 OpenSSL/0.9.8o zlib/1.2.3.4
libidn/1.18]}
12:35:02,278 DEBUG | eResources | .cxf.phase.PhaseInterceptorChain |
Adding interceptor
org.apache.cxf.ws.policy.PolicyInInterceptor@4d47ce48
to phase receive
12:35:02,278 DEBUG | eResources | .cxf.phase.PhaseInterceptorChain |
Adding interceptor
org.apache.cxf.interceptor.ServiceInvokerInterceptor@7fafd333 to
phase
invoke
12:35:02,278 DEBUG | eResources | .cxf.phase.PhaseInterceptorChain |
Adding interceptor
org.apache.cxf.interceptor.OutgoingChainInterceptor@7052fac2 to phase
post-invoke
12:35:02,278 DEBUG | eResources | .cxf.phase.PhaseInterceptorChain |
Adding interceptor
org.apache.cxf.interceptor.OneWayProcessorInterceptor@57cd102a to
phase
pre-logical
12:35:02,278 DEBUG | eResources | .cxf.phase.PhaseInterceptorChain |
Adding interceptor
org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor@57e0626e to phase
unmarshal
12:35:02,279 DEBUG | eResources | .cxf.phase.PhaseInterceptorChain |
Adding interceptor
org.apache.cxf.transport.https.CertConstraintsInterceptor@1e5dba88 to
phase pre-stream
12:35:02,279 DEBUG | eResources | .cxf.phase.PhaseInterceptorChain |
Chain org.apache.cxf.phase.PhaseInterceptorChain@24f05c30 was
created.
Current flow:
receive [PolicyInInterceptor]
pre-stream [CertConstraintsInterceptor]
unmarshal [JAXRSInInterceptor]
pre-logical [OneWayProcessorInterceptor]
invoke [ServiceInvokerInterceptor]
post-invoke [OutgoingChainInterceptor]
---------------------------------------------------------------------------------------------------------------------
INVOCATION OF IN INTERCEPTOR CHAIN FOLLOWS
---------------------------------------------------------------------------------------------------------------------
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
