cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: help implementing secured resource methods?
Date Mon, 18 Jan 2010 12:33:34 GMT

it's been awhile since I used <security-constraint>, etc. I think the reason you get
401 in this case is that WebLogic has not been 
configured with a WebLogic-specific configuration listing user name/password pairs, because
if you use the <security-constraint>/etc 
you're actually relying on the underlying container to do the (basic) authentication. And
another thing to check here is that an 
Authorization header containing a Basic authorization info is properly formatted and that
a 'username:password' has been 

So hopefully, once you make the first (authentication) step working then the custom RequestHandler
will be able to get Principal(s) 
from an injected (thread-safe) SecurityContext in a RequestHandler and then do some custom
authorization decisions.

Perhaps, rather than doing the custom authorization checks, you might want to try to have
SpringSecurity do it for you, ex, see [1].
You can probably still rely on the (WebLogic) container doing the actual authentication and
the Principal allocation (as opposed to 
Spring Security doing it, see security:http/security:http-basic) but just configure SpringSecurity
to do the actual method-level 
authorization only. The test beans.xml at [1] relies on the @Secured (or RolesAllowed) annotations
but see [2] for an example on how 
to do the declarative method authorizatiom in beans.xml

Most likely, you'd still need a custom RequestHandler to check a sessionId...

let me know please what option you'd like to pursue and how it all goes,

cheers, Sergey

----- Original Message ----- 
To: <>
Sent: Friday, January 15, 2010 10:03 PM
Subject: help implementing secured resource methods?

I need to investigate how I can implement some level of authorization
security for my resource methods.

What I envision is that I will have one resource method that is
protected by basic auth (https), and all that does is return a session
id.  All the other resource methods will require a session id that I can
validate as either just existing, or perhaps to validate that the
authorization for the principal that owns that session is valid for the
"channel" this resource method represents (other resource methods will
represent other channels, which other principals are allowed to access).

I looked in the CXF doc for information about security and request
handlers.  It appears that I can register a request handler that might
be able to do all of this work.  I see that I can read the request
headers, and there is an example that shows how to read the basic auth

I think the next part has to do with configuring my app (the web.xml,
mostly) so that I can at least do manual authentication and

I then tried to send basic auth on my request.  SoapUI doesn't appear to
be able to send it just by providing the principal and credentials (even
though it seems like it does), but when I manually formatted an
"Authorization" header (that I got from a Wikipedia article) I got an
immediate 401 back from my app, before it got to any of my code.  That
seems to imply that I can't move forward without setting up the web.xml
file for security.

Assuming this is true, can anyone suggest a minimal set of elements in
the web.xml that will allow me to do this?  I've started with the



View raw message