You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Chris Geer <ch...@cxtsoftware.com> on 2012/03/20 00:12:31 UTC

Pre-Authentication

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
PreAuthenticatedAuthenticationProvider.
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". 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?
2) Is there a better way to handle this issue without having to use spring
security?

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

Re: Pre-Authentication

Posted by Chris Geer <ch...@cxtsoftware.com>.
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 <fr...@gmail.com>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:ffang@fusesource.com
> Web: fusesource.com
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.**com <http://freemanfang.blogspot.com>
>
>
>
>
>
>
>
>
>
>

Re: Pre-Authentication

Posted by Freeman Fang <fr...@gmail.com>.
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
> PreAuthenticatedAuthenticationProvider.
> 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". 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
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:ffang@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com