I didn't know about the WebServiceContext object when I did my initial
implementation, so I haven't tried it. I had decided to use Spring security for
the auth provider, so I just plugged that in at the password callback level. A
cool side-effect of this approach is that you can use Spring security
annotations to protect web service calls at the method level like this:
public User updateUser(String username, User info) throws AtlasFault {
... Guarded impl code ...
}
and within the body of a method, you can make a call to the standard Spring
security threadlocal to get the user roles and filter data accordingly. The way
I am doing it is probably not too portable though, so I guess it just depends
on what you need.
@Secured( { AtlasRoles.ROLE_USER_MGMT_ADMIN })
________________________________
From: Tedman Leung <[email protected]>
To: [email protected]
Sent: Friday, February 20, 2009 2:37:22 PM
Subject: Re: Authentication and authorization
Just out of curiosity, if you're using a WSS4J interceptor, wouldn't it be
easier to just call WebServiceContext.getUserPrincipal()? or is that some
how unreliable?
On Fri, Feb 20, 2009 at 10:27:15AM -0800, derek.adams wrote:
>
> Which authentication method are you using? If you are using WS-Security via
> the WSS4JInInterceptor, then you can set the authenticated user in your
> password callback class. Generally, the easiest method is to set a thread
> local variable (the method Spring security uses). If you are using HTTP
> basic authentication, I am pretty sure you would be able to get the username
> from the HTTP headers.
>
--
Ted Leung
[email protected]
It's time for a new bike when the bulb in your shift light burns out.
