users@jersey.java.net

Re: [Jersey] Jersey & ACEGI

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Mon, 29 Jun 2009 08:57:07 +0200

On Jun 28, 2009, at 11:26 PM, Craig McClanahan wrote:

> Nabil Benothman wrote:
>>
>> Hi,
>> the use of access based on role is not enough for me, I have a
>> resource user
>> and I do not want everyone to have access to data of all other
>> users. so do
>> you have i idea how to do that?
>>
>>
> In the general case (I don't know whether Spring Security can do
> this) don't assume that a user has to "have" a role for all request
> URIs.
>
> An approach I've used for this use case depends on being able to
> detect (from the request URI) which user's data is being requested.
> Next, compare the requested user with the user making the request
> (if you're using basic authentication, that's the user retrieved
> from the Authorization header) and only grant the required role if
> the two user identities match. There's an example of this
> implementation in the samples/atompub-contacts-server sample
> application.
>

Yes, it overrides the SecurityContext and supports a "user" role that
is connected to the request URI, specifically the "username" path
parameter used in the resources and compares that value with the
principle name.

Since it overrides the SecurityContext it means the @RolesAllowed
annotation can still apply.

The example is not Web-based but i suspect it should be possible to
modify it to leverage/adapt the underlying SecurityContext derived
from the Jersey Servlet integration.

Paul.

> In a more complex scenario, you might extend this idea to grant a
> "read" and a "write" role for a user's own data, and a "read" role
> to other users who have authorized this user to access their data.
>> thankx
>>
>> Nabil.
>>
> Craig
>
>>
>>
>>
>>
>> Ronak Patel wrote:
>>
>>> Yes I did that. It's quite easy. Spring Security doesn't have to
>>> know that
>>> you have a Jersey application...it's quite transparent.
>>>
>>>
>>
>>
>