On Mon, Sep 21, 2009 at 16:06, Daniel Kulp <[email protected]> wrote: > On Mon September 21 2009 5:52:32 am Andreas Veithen wrote: >> Actually, I was going to propose to create a new Maven module that >> contains all Spring Security related code. If we do it like that, then >> there is no issue with the dependency on Spring Security. > > Either way is fine by me. :-) I really have no problem shipping spring > security as well if it's needed, especially if we get a couple good samples > that show it all working.... (hint hint hint... ;-) )
One thing after the other: first the code, then the tests (hint: I will need some help with this) and then the documentation and samples. > This definitely > fills some gaps in the security related implementations and such. If we can > get stuff that shows full spring security integration, that's huge. > > Dan > > > >> >> Andreas >> >> On Mon, Sep 21, 2009 at 11:40, Sergey Beryozkin <[email protected]> > wrote: >> > Hi >> > >> > It is brilliant, thanks. it would be nice to have this feature and a >> > WSS4J spring security aware password callback handler contributed to CXF >> > but the issue is we don't actually ship SpringSecurity... >> > Dan - would it make sense to introduce a 'provided' dependency on the >> > Spring security (core) modules ? And then modules like ws-security or >> > jaxrs can have contributions in ....spring.security packages ? >> > Alternatively we can have this feature and handler demonstrated perhaps >> > in the system tests area, with the contributions from Andreas being >> > acknowledged ? >> > >> > cheers, Sergey >> > >> > ----- Original Message ----- From: "Andreas Veithen" >> > <[email protected]> >> > To: <[email protected]> >> > Sent: Sunday, September 20, 2009 10:16 PM >> > Subject: Re: CXF + JAX-RS + Spring Security (Acegi) for authorization >> > >> > >> > I improved this a bit further by creating a feature that adds the invoker >> > proxy: >> > >> > public class AuthorizationFeature extends AbstractFeature { >> > @Override >> > public void initialize(Server server, Bus bus) { >> > Service service = server.getEndpoint().getService(); >> > service.setInvoker(new >> > SpringSecurityInvokerProxy(service.getInvoker())); >> > } >> > } >> > >> > Now the configuration looks like this: >> > >> > <jaxrs:server address="/rest"> >> > <jaxrs:serviceBeans> >> > ... >> > </jaxrs:serviceBeans> >> > <jaxrs:providers> >> > ... >> > </jaxrs:providers> >> > <jaxrs:features> >> > <bean class="myapp.security.AuthorizationFeature"/> >> > </jaxrs:features> >> > </jaxrs:server> >> > >> > The advantage is that it works in exactly the same way for all >> > frontends (I tested this successfully with JAX-RS and the simple >> > frontend) and that there is no need to figure out how to set up the >> > target invoker. >> > >> > Does the code in AuthorizationFeature look good? >> > >> > >> > I also have a working integration between WSS4J and Spring Security >> > which plays nicely with >> > SpringSecurityInvokerProxy/AuthorizationFeature. Here is the >> > configuration for a simple scenario: >> > >> > <security:authentication-provider> >> > <security:user-service> >> > <security:user name="joe" password="password" >> > authorities="ROLE_USER,ROLE_ADMIN"/> >> > <security:user name="bob" password="password" >> > authorities="ROLE_USER"/> </security:user-service> >> > </security:authentication-provider> >> > >> > <simple:server serviceClass="myapp.MyService" address="/myservice"> >> > <simple:serviceBean> >> > <bean class="myapp.MyServiceImpl"/> >> > </simple:serviceBean> >> > <simple:inInterceptors> >> > <bean class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor"> >> > <constructor-arg> >> > <map> >> > <entry key="action" value="UsernameToken"/> >> > <entry key="passwordType" value="PasswordText"/> >> > <entry key="passwordCallbackRef"> >> > <ssec:server-password-callback-handler >> > logExceptions="true" nestExceptions="false"/> >> > </entry> >> > </map> >> > </constructor-arg> >> > </bean> >> > </simple:inInterceptors> >> > </simple:server> >> > >> > ssec:server-password-callback-handler is a Spring handler that creates >> > a password callback handler that delegates authentication to Spring >> > Security. >> > >> > If there is interest, I can contribute the corresponding code. >> > >> > Andreas >> > >> > >> > On Wed, Sep 16, 2009 at 10:54, Sergey Beryozkin >> > >> > <[email protected]> wrote: >> >> Hi Andreas >> >> >> >> This does look like a neat solution. I think it's worth documenting what >> >> you >> >> suggested. >> >> Note that we don't support in-only operations for JAX-RS (just yet), but >> >> either way, what you've done seems to cover all the variations. In one >> >> of the system tests I added a custom invoker which extends JAXRSInvoker >> >> but your approach works well too and is more generic. >> >> >> >>> - The service is not necessarily invoked in the same thread as the >> >>> interceptor >> >> >> >> I thought that interceptors and the service were actually invoked on the >> >> same thread. It is transport threads like Jetty threads won't >> >> necessarily end up invoking on the service. >> >> >> >> Dan, can it be that a thread which invoked a given interceptor won't >> >> invoke >> >> the service endpoint ? >> >> >> >> By the way there's also a similar test showing how the spring security >> >> can be used without using annotations : >> >> >> >> >> >> systest/jaxrs/src/test/resources/jaxrs_security_no_annotations/WEB-INF/b >> >>eans.xml >> >> >> >> cheers, Sergey >> >> >> >> Andreas Veithen-2 wrote: >> >>> I'm currently trying to integrate JAX-RS with Spring Security for >> >>> authorization (authorization only; I use a custom authentication >> >>> mechanism). I found the following resources describing integration >> >>> between CXF and Spring Security: >> >>> >> >>> - >> >>> >> >>> http://www.nabble.com/Re:-CXF%2BACEGI-%2B-Anybody-out-there--p12759358. >> >>>html (WS-Security) >> >>> - http://www.emforge.org/wiki/WebServicesImplementation (WS-Security) >> >>> - There is also a JAX-RS systest (see >> >>> systest/jaxrs/src/test/resources/jaxrs_security/WEB-INF/beans.xml in >> >>> the trunk) that integrates Spring Security with JAX-RS. >> >>> >> >>> In order for (annotation driven) authorization to work, it is >> >>> necessary to use SecurityContextHolder to associate the >> >>> SecurityContext/Authentication with the current thread. In the first >> >>> two references, this is done in a custom interceptor, while the >> >>> systest uses a servlet filter (that implements HTTP basic >> >>> authentication). I see two issues with these approaches: >> >>> - The service is not necessarily invoked in the same thread as the >> >>> interceptor or servlet filter (e.g. in-only operations). If that >> >>> happens, the security context will not be set up correctly. >> >>> - The code in the first two references never resets the authentication >> >>> in the SecurityContext (by calling >> >>> SecurityContextHolder.getContext().setAuthentication(null)). I fear >> >>> that it is therefore possible that a service may accidentally get the >> >>> authentication from a previous request. This is only a problem when >> >>> using an interceptor, but using a servlet filter may not always be >> >>> possible (e.g. for WS-Security). >> >>> >> >>> The approach that I use to avoid these problems is to insert a proxy >> >>> in front of the Invoker (JAXRSInvoker in my case). This proxy looks as >> >>> follows: >> >>> >> >>> public class SpringSecurityInvokerProxy implements Invoker { >> >>> private Invoker target; >> >>> >> >>> public Invoker getTarget() { return target; } >> >>> public void setTarget(Invoker target) { this.target = target; } >> >>> >> >>> public Object invoke(Exchange exchange, Object o) { >> >>> Authentication authentication = exchange.get(Authentication.class); >> >>> SecurityContext securityContext = >> >>> SecurityContextHolder.getContext(); >> >>> securityContext.setAuthentication(authentication); >> >>> try { >> >>> return target.invoke(exchange, o); >> >>> } finally { >> >>> securityContext.setAuthentication(null); >> >>> } >> >>> } >> >>> } >> >>> >> >>> The Authentication object is added to the exchange by an interceptor >> >>> that implements the custom authentication mechanism. The try/finally >> >>> block here makes sure that the security context is reset right after >> >>> the invocation of the service. The corresponding configuration is: >> >>> >> >>> <jaxrs:server address="/rest"> >> >>> <jaxrs:serviceBeans> >> >>> ... >> >>> </jaxrs:serviceBeans> >> >>> <jaxrs:providers> >> >>> ... >> >>> </jaxrs:providers> >> >>> <jaxrs:invoker> >> >>> <bean class="myapp.security.SpringSecurityInvokerProxy"> >> >>> <property name="target"> >> >>> <bean class="org.apache.cxf.jaxrs.JAXRSInvoker"/> >> >>> </property> >> >>> </bean> >> >>> </jaxrs:invoker> >> >>> </jaxrs:server> >> >>> >> >>> This works well for me, but I would like to know if there is a >> >>> better/easier way to achieve this. >> >>> >> >>> Regards, >> >>> >> >>> Andreas >> >> >> >> -- >> >> View this message in context: >> >> http://www.nabble.com/CXF-%2B-JAX-RS-%2B-Spring-Security-%28Acegi%29-for >> >>-authorization-tp25462665p25468445.html Sent from the cxf-user mailing >> >> list archive at Nabble.com. >> > > -- > Daniel Kulp > [email protected] > http://www.dankulp.com/blog >
