Freeman, Thank you for your input. I was able to create a custom interceptor and login module which allows me to set the SecurityContext on the message. Now I have access to the authenticated principal in my web service but I'm stuck on how to propagate it to my OSGI service layer. I guess I was hoping to be able to do something like the following in my OSGI code:
AccessControlContext acc = AccessController.getContext(); Subject subj = Subject.getSubject(acc); That would give me the authenticated subject and then I could make decisions based on that. What I can't figure out is how to get from a Principal in my web services to being able to get the Subject from an OSGI service. Any thoughts? Is there a better way? Chris On Mon, Mar 19, 2012 at 10:00 PM, Freeman Fang <[email protected]>wrote: > Hi, > > My comment inline > > On 2012-3-20, at 上午7:12, Chris Geer wrote: > > We are testing the concept of using Apache HTTPD as a reverse proxy and >> authenticating all our users there. This allows us to authenticate in one >> spot and pass the authenticated username in a HTTP header to our various >> backend servers. We currently have this working pretty well on one >> application using spring security and the >> PreAuthenticatedAuthentication**Provider. >> Now we are trying to do the same with CXF so that our web services can get >> the authenticated user information as well but we've run into an issue >> trying to utilize spring security. >> >> We are running CXF on top of ServiceMix 4.4.1 (CXF 2.4.6) and using >> blueprint configuration files. When we try to add the spring security tags >> to our blueprint files our service gets stuck in GracePeriod waiting for a >> namespace handler for >> "https://www.springsource.org/**security<https://www.springsource.org/security>". >> So this >> brings up two questions: >> >> 1) Is there a way to define spring security features in a blueprint file? >> If so, what bundles/features do I need to get past the namespace >> resolution? >> > I don't think you can use spring tags in blueprint context. > > 2) Is there a better way to handle this issue without having to use spring >> security? >> > Yes, I think so. > As you're using Servicemix 4.4.1, please take a look at > cxf-ws-security-blueprint example shipped with kit, it leverage cxf > JAASLoginInterceptor to authenticate against karaf > default jaas configuration. If your backend security service is based on > JAAS, you can use pretty much same way, if not, you can also add another > interceptor to extract username/password(based on http basic auth or > ws-security UsernameToken) from incoming message, and then create security > context and saved it into message, then you can use the saved security > context whenever and whatever you want to call your backend security > service. You can take a look at JAASLoginInterceptor[1] to get details that > how to extract username/password and create security context from it. > > [1]https://svn.apache.org/**repos/asf/cxf/branches/2.4.x-** > fixes/rt/core/src/main/java/**org/apache/cxf/interceptor/** > security/JAASLoginInterceptor.**java<https://svn.apache.org/repos/asf/cxf/branches/2.4.x-fixes/rt/core/src/main/java/org/apache/cxf/interceptor/security/JAASLoginInterceptor.java> > HTH > Freeman > > > >> Our end goal is to be able to call OSGI services from our CXF web service >> and have the security context passed along so our OSGI services can make >> decisions based on the calling user. We really want to avoid having to >> pass >> the username as a parameter to all the methods. >> >> Thanks, >> Chris >> > > ------------------------------**--------------- > Freeman Fang > > FuseSource > Email:[email protected] > Web: fusesource.com > Twitter: freemanfang > Blog: http://freemanfang.blogspot.**com <http://freemanfang.blogspot.com> > > > > > > > > > >
