Ray,

On Monday 17 September 2007, Ray Krueger wrote:
> The authorization and authentication concerns are addressed at the
> protocol layer first, and can then be extended into lower levels of
> the application via AOP and such. So, if you're interested in securing
> your application at that level, then CXF doesn't even really enter
> into the discussion. Meaning that you're going to put the Acegi filter
> out there, and configure it to protect whatever URLs your CXF services
> are published on. Acegi wouldn't know anything about CXF in that case.

This currently works fine if you use the CXFServlet approach and deploy 
your application as a war into some sort of Servlet container. 

However, if you do a J2SE standalone mode application, this is quite hard 
to do right now and is something we should make a bit easier.   
Currently, you would need to grab the raw Jetty listeners, use the Jetty 
API's to add the filters, etc....   (Note: this also applies if you want 
to secure your decoupled destination for a ws-rm/ws-a interaction)   

We probably should allow filters to be added via the spring configuration 
for the destination.   That would simplify things quite a bit.

> From there you can decide in your endpoints how you consider the
> 'Principal'. You could retrieve it from Acegi without it being part of
> WS-Security and keep it loose that way. Or you could find some means
> of integrating Acegi into a WS-Security provider for CXF somehow.

This was the interceptor I mentioned before.   An interceptor after the 
WS-Sec interceptors would have access to the stuff decoded from the 
message.   The interceptor could create the principal object and pass 
that into Acegi.

Dan


> The application I am building will support both plain xml over http
> and soap over http. So in that case it makes sense for me to place
> security at the http layer, and avoid relying on something like
> WS-Security.
>
> On 9/17/07, Daniel Kulp <[EMAIL PROTECTED]> wrote:
> > Interesting you should ask this.....    I first heard about ACEGI
> > last week in a different conversation and have just started to look
> > into it a bit.   I'd LOVE to have your input into this as to what
> > you think is needed or what you would consider good integration.
> >
> > Here are my thoughts so far:   (keep in mind, I had never heard of
> > ACEGI till last week so I could be completely off base)
> >
> > 1) If you deploy your app as a war using the spring webapp stuff and
> > setting up to use aop for your service, it should just work.  The
> > acegi filter should grab the basic-auth stuff, setup the security
> > context stuff it needs, and when we call invoke on the service, the
> > acegi stuff should grant/deny it.
> >
> > 2) Longer term, we could write an interceptor that grabs the
> > AuthorizationPolicy object and HTTPS/WS-Sec stuff from our message
> > and fills in the acegi contexts with the details.    That really
> > wouldn't be a huge amount of work to do.
> >
> >
> > Dan
> >
> > On Thursday 13 September 2007, mattmadhavan wrote:
> > > Hello,
> > > Can some one point me to some docs on the CXF and ACEGI
> > > integration or CXF and security like authentication and
> > > authorization. Some sample app will even be great.
> > >
> > > I found some blogs on the CXF+ACEGI, but it is Java centric. On
> > > the client side we need to set the which class handles the
> > > security on the Server side! But if I am using some other language
> > > for clients like C# it does n't seem to be the proper way!
> > >
> > > Any ideas will be greatly appreciated.
> > >
> > > Thanks
> > > Matt
> >
> > --
> > J. Daniel Kulp
> > Principal Engineer
> > IONA
> > P: 781-902-8727    C: 508-380-7194
> > [EMAIL PROTECTED]
> > http://www.dankulp.com/blog



-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

Reply via email to