On Wed, Feb 17, 2010 at 15:57, Sergey Beryozkin <[email protected]> wrote: > Hi > > Have a look at > http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/CustomJAXRSInvoker.java > > This custom invoker is used in one of the tests (I linked to earlier on) so > clearly the org.apache.cxf.security.SecurityContext gets initialized), that > is JAXRs SecurityContextImpl gets the Principal from the current > org.apache.cxf.security.SecurityContext.
You are right. I think the complete explanation is as follows: The default filter configuration in Spring Security includes SecurityContextHolderAwareRequestFilter which replaces the ServletRequest with a request wrapper that overrides the getUserPrincipal and isUserInRole methods so that they return information from Spring Security. CXF's HTTP transport uses that information to build a org.apache.cxf.security.SecurityContext and the JAX-RS front-end will use that to inject javax.ws.rs.core.SecurityContext instances. In addition, the servlet filters by default also bind the Authentication object to the thread, which is a prerequisite to using method level authorization. Thus, John's scenario should indeed be supported by CXF out of the box. Does that sound correct? I will use these findings to update the document, so that it clearly explains which scenarios are supported out of the box and which scenarios require additional integration. > I think Andreas was referring earlier on to oneway invocations ? > cheers, Sergey There are indeed additional concerns with oneway invocations, but that only applies to JAX-WS. The statement "This makes it clear that an interceptor would not be the right place to manage Spring's security context" primarily refers to the fact that the security context needs to be cleaned up after the invocation of the service implementation. In John's scenario this is done by the servlet filters, but in scenarios that use WS-Security this is a bit more tricky. > ----- Original Message ----- From: "johnrock" <[email protected]> > To: <[email protected]> > Sent: Wednesday, February 17, 2010 1:46 PM > Subject: Re: Is it possible to integrate CXF JAX-RS with Spring Security > 2.0.5 ? > > > > Thank you for the link to that wiki. Very helpful. To quote from there: > > "If Spring Security is used for authentication, then CXF's SecurityContext > is not initialized automatically. cxf-spring-security provides an > interceptor that can be used if this is required. This interceptor adapts an > authenticated Authentication object found in the current Exchange to the > org.apache.cxf.security.SecurityContext interface and adds it to the current > message. Authorities in the Authentication object are mapped one-to-one to > roles in the SecurityContext. > ... > > Setting up Spring's security context: <ssec:spring-security-context-feature> > ... > > This makes it clear that an interceptor would not be the right place to > manage Spring's security context. cxf-spring-security solves this issue with > the help of a org.apache.cxf.service.invoker.Invoker proxy that will be > installed in front of the real invoker (whose responsibility is to dispatch > to the right method of the service implementation). This proxy sets up the > security context before delegating to the real invoker and removes it after > completion. " > > Doesn't this imply that either an Interceptor or custom invoker is required > ? My example is not currently using either approach. Is there an example > that uses an Interceptor or Invoker to set up the Security Context? > > -- > View this message in context: > http://old.nabble.com/Is-it-possible-to-integrate-CXF-JAX-RS-with-Spring-Security-2.0.5---tp27587340p27623838.html > Sent from the cxf-user mailing list archive at Nabble.com. > >
