Mailing-List: contact user-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@geronimo.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <56337A83-DA8F-4E38-9535-A037270DBD88@yahoo.com>
References: <1f3854d50911160841p5a51994n6c64f223fb984b4c@mail.gmail.com>
	<56337A83-DA8F-4E38-9535-A037270DBD88@yahoo.com>
From: Quintin Beukes <quintin@skywalk.co.za>
Date: Mon, 16 Nov 2009 20:04:26 +0200
Message-ID: <1f3854d50911161004r32b6b911v617156c18160c67c@mail.gmail.com>
Subject: Re: Serious Problem with Roles
To: user@geronimo.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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> wrot=
e:
> 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:
>>
>> =C2=A0 =C2=A0 <sec:role role-name=3D"Lamp Room">
>> =C2=A0 =C2=A0 =C2=A0 <sec:principal
>> class
>> =3D"org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal"
>> name=3D"Lamp Room"/>
>> =C2=A0 =C2=A0 </sec:role>
>> =C2=A0 =C2=A0 <sec:role role-name=3D"VDS User">
>> =C2=A0 =C2=A0 =C2=A0 <sec:principal
>> class
>> =3D"org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal"
>> name=3D"Lamp Room"/>
>> =C2=A0 =C2=A0 </sec:role>
>> =C2=A0 =C2=A0 <sec:role role-name=3D"Personnel User">
>> =C2=A0 =C2=A0 =C2=A0 <sec:principal
>> class
>> =3D"org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal"
>> name=3D"Lamp Room"/>
>> =C2=A0 =C2=A0 </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.
>> =C2=A0 Subject subject =3D ContextManager.getCurrentCaller();
>> =C2=A0 Set<Principal> principals =3D subject.getPrincipals();
>
> roles are just names, not principals, so there's no way you'll see them i=
n
> the Subject. =C2=A0Here'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 start=
s
> 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 th=
e
> permission desired.
>
> One thing to note about this is that geronimo needs to know about the rol=
e
> and permission you're going to check. =C2=A0So the role has to be declare=
d
> somewhere. =C2=A0I'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. =C2=A0I don't r=
ecall
> how ejbs work, I kinda think that you have to declare all the roles you a=
re
> 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
>
>