geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quintin Beukes <quin...@skywalk.co.za>
Subject Re: Serious Problem with Roles
Date Mon, 16 Nov 2009 18:04:26 GMT
Oh yes :<

I was so focussed on my initial problem that I forgot about the
workings of isCallerInRole(). You have to do @DeclareRoles({..}) at
the class level. I actually do this everywhere I call
isCallerInRole(). It was just in this case where I'm trying to
determine the call's roles. The subject wasn't working (I now know
it's obvious, as a role isn't a principal), so I tried to do
isCallerInRole() without using it properly.

I have a big problem though.

Is there any way at all to get a list of roles for a user as mapped in
the deployment descriptor? Even if I have to query the Geronimo API.
Portability when it comes to security is really not a big issue for me
as I feel JavaEE's security is vague in any case. Besides, where ever
I break portability I do so through interfaces and implementations
with some "container validation". So if someone following me tries to
port he'll get a "friendly" message stating he needs to make his own
implementation.

Quintin Beukes



On Mon, Nov 16, 2009 at 7:29 PM, David Jencks <david_jencks@yahoo.com> wrote:
> Hi Quintin,
>
> On Nov 16, 2009, at 8:41 AM, Quintin Beukes wrote:
>
>> Hey,
>>
>> I basically have a bunch of roles which should each be mapped to
>> different combinations of a user's "GroupPrincipals". Something like
>> this:
>>
>>     <sec:role role-name="Lamp Room">
>>       <sec:principal
>> class
>> ="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal"
>> name="Lamp Room"/>
>>     </sec:role>
>>     <sec:role role-name="VDS User">
>>       <sec:principal
>> class
>> ="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal"
>> name="Lamp Room"/>
>>     </sec:role>
>>     <sec:role role-name="Personnel User">
>>       <sec:principal
>> class
>> ="org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal"
>> name="Lamp Room"/>
>>     </sec:role>
>>
>> This means that named roles are all assigned to a user of group "Lamp
>> Room".
>>
>> Though doing the following I don't see these "virtual roles", only the
>> actual group.
>>   Subject subject = ContextManager.getCurrentCaller();
>>   Set<Principal> principals = subject.getPrincipals();
>
> roles are just names, not principals, so there's no way you'll see them in
> the Subject.  Here's how it works, in PolicyContextGeneric:
>
> 1. the principal-role map specified above is fed in.
> 2. the role-permission map specified by the DD or annotations is fed in
> 3. these are combined to form a principal-permission map as the app starts
> up
> 4. when you test a permission (either through container access control or an
> isUserInRole/isCallerInRole call) we run through the Subject's principals,
> get the PermissionCollection for that principal, and see if it implies the
> permission desired.
>
> One thing to note about this is that geronimo needs to know about the role
> and permission you're going to check.  So the role has to be declared
> somewhere.  I'm less sure about the role-ref permission...
> for web apps there is an implicit role-ref permission set up mapping the
> role to itself for any role without an explicit role-ref.  I don't recall
> how ejbs work, I kinda think that you have to declare all the roles you are
> going to test with a role-ref.
>
>>
>> I can see how this would be the case, though the following must
>> definitely work: isCallerInRole("Personnel Admin") or EVEN
>> isCallerInRole("Lamp Room"). They all return false.
>>
>> If I have a method annotated with @RolesAllowed({"Personnel User"}),
>> then GeronimoSecurityService.isCallerAuthorized(Method method,
>> InterfaceType typee) return TRUE.
>> Though, GeronimoSecurityService.isCallerInRole(String role) returns
>> FALSE when I query isCallerInRole("Personnel User").
>
> I think this might support my idea that you have to explicitly set up a
> role-ref for any role you mean to test in an ejb.
>>
>> I assume somewhere the AccessControlContext isn't populated correctly?
>> I'm not really sure how this should work, so if someone can tell me
>> how this all fits together I can have a look.
>>
>
> Let me know if the above doesn't answer your questions
>
> thanks
> david jencks
>
>> Quintin Beukes
>
>

Mime
View raw message