You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Quintin Beukes <qu...@last.za.net> on 2009/11/14 12:17:59 UTC
Retrieving Group Principals
Hey,
I've got a bunch of @RolesAllowed annotations, which basically
reference the group principals of my users. They work perfectly.
Further I can also retrieve the subject name by accessing the
UserPrincipal through the EJBContext.
How can I retrieve all the group principal, or "Role Names". This is
available to OpenEJB, as it uses it to authorize my requests.
I can't read them from the database, as the role names in the database
are different from those used in OpenEJB. I'm using Geronimo role name
mappings for this. For example, my EJBs would be annotated with
@RolesAllowed({"Personnel Admin", "Personnel Read Access}), and then I
have in the database a role "Lamp Room Staff". This role would then be
mapped to a bunch of EJB roles, including "Personnel Read Access",
"Create Lamp", "Assign Lamp", etc.
For the server side it's fine to not have a list of the roles, as
OpenEJB takes care of it all, and where more complex authorization is
needed I just call ejbContext.isCallerInRole(...). Though my client
side front end also has authorization in it. This is mostly just to
show/hide actions allowed for a given user.
As a temporary fix I have a method "List getOperatorRoles()", which
takes a list of all roles and then iterates isCalledInRole, building a
list based on the result of this method. I can't continue doing this
though, as it increases maintenance and "breaks" modularity.
How can I retrieve a list of all roles? Even if it means I have to go
against the standard for this one thing, in which case I'll put it in
a utility class which validates it's environment and raise an error +
description when run in another server. This way when moving it I'll
remember to find another way of achieving the same. I don't think this
will happen anyway.
Quintin Beukes
Re: Retrieving Group Principals
Posted by Jean-Louis MONTEIRO <je...@atosorigin.com>.
Quintin Beukes-2 wrote:
>
> I'm not sure I understand what you mean?
>
Sorry for that :p
I was just saying that if you wanna use ThreadContext to get principals
list, it's probably better to push that code in a custom SecurityService.
Jean-Louis
--
View this message in context: http://old.nabble.com/Retrieving-Group-Principals-tp26349206p26387375.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Retrieving Group Principals
Posted by Quintin Beukes <qu...@skywalk.co.za>.
I'm not sure I understand what you mean?
Quintin Beukes
On Tue, Nov 17, 2009 at 11:21 AM, Jean-Louis MONTEIRO
<je...@atosorigin.com> wrote:
>
> Hi,
>
> i would prefer that proposition to locate proprietary code.
>
> Jean-Louis
>
>
> Q Beukes wrote:
>>
>> Or maybe a better way would be to use a custom SecurityService (which
>> could extend the GeronimoSecurityService) in some way? Though this
>> would still require accessing the ThreadContext.
>>
>> Quintin Beukes
>>
>>
>>
>> On Sat, Nov 14, 2009 at 2:02 PM, Quintin Beukes <qu...@last.za.net>
>> wrote:
>>> To achieve this I had a look at the OpenEJB code.
>>>
>>> Would the following be a valid way of doing so. I understand it's not
>>> portable at all, though like I mentioned this is acceptable for this
>>> situation. Much of our authentication/authorization code for the
>>> client side is not portable, as JavaEE doesn't provide much on this
>>> topic. I tried to stay by the spec where possible, though.
>>>
>>> So in:
>>> ./container/openejb-core/src/main/java/org/apache/openejb/core/security/AbstractSecurityService.java
>>> I found getCallerPrincipal(). I noticed it access the security service
>>> and fetch the Principals like so:
>>> ThreadContext threadContext = ThreadContext.getThreadContext();
>>> SecurityContext securityContext =
>>> threadContext.get(SecurityContext.class);
>>> Set<Principal> principals =
>>> securityContext.subject.getPrincipals();
>>>
>>> Can I do this inside an EJB to access the principals as well? I figure
>>> it should work, though I'd just like to be sure and I don't have any
>>> way to test until tomorrow.
>>>
>>> Thanks,
>>> Quintin Beukes
>>>
>>>
>>>
>>> On Sat, Nov 14, 2009 at 1:17 PM, Quintin Beukes <qu...@last.za.net>
>>> wrote:
>>>> Hey,
>>>>
>>>> I've got a bunch of @RolesAllowed annotations, which basically
>>>> reference the group principals of my users. They work perfectly.
>>>> Further I can also retrieve the subject name by accessing the
>>>> UserPrincipal through the EJBContext.
>>>>
>>>> How can I retrieve all the group principal, or "Role Names". This is
>>>> available to OpenEJB, as it uses it to authorize my requests.
>>>>
>>>> I can't read them from the database, as the role names in the database
>>>> are different from those used in OpenEJB. I'm using Geronimo role name
>>>> mappings for this. For example, my EJBs would be annotated with
>>>> @RolesAllowed({"Personnel Admin", "Personnel Read Access}), and then I
>>>> have in the database a role "Lamp Room Staff". This role would then be
>>>> mapped to a bunch of EJB roles, including "Personnel Read Access",
>>>> "Create Lamp", "Assign Lamp", etc.
>>>>
>>>> For the server side it's fine to not have a list of the roles, as
>>>> OpenEJB takes care of it all, and where more complex authorization is
>>>> needed I just call ejbContext.isCallerInRole(...). Though my client
>>>> side front end also has authorization in it. This is mostly just to
>>>> show/hide actions allowed for a given user.
>>>>
>>>> As a temporary fix I have a method "List getOperatorRoles()", which
>>>> takes a list of all roles and then iterates isCalledInRole, building a
>>>> list based on the result of this method. I can't continue doing this
>>>> though, as it increases maintenance and "breaks" modularity.
>>>>
>>>> How can I retrieve a list of all roles? Even if it means I have to go
>>>> against the standard for this one thing, in which case I'll put it in
>>>> a utility class which validates it's environment and raise an error +
>>>> description when run in another server. This way when moving it I'll
>>>> remember to find another way of achieving the same. I don't think this
>>>> will happen anyway.
>>>>
>>>> Quintin Beukes
>>>>
>>>
>>
>>
>
> --
> View this message in context: http://old.nabble.com/Retrieving-Group-Principals-tp26349206p26386654.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
>
Re: Retrieving Group Principals
Posted by Jean-Louis MONTEIRO <je...@atosorigin.com>.
Hi,
i would prefer that proposition to locate proprietary code.
Jean-Louis
Q Beukes wrote:
>
> Or maybe a better way would be to use a custom SecurityService (which
> could extend the GeronimoSecurityService) in some way? Though this
> would still require accessing the ThreadContext.
>
> Quintin Beukes
>
>
>
> On Sat, Nov 14, 2009 at 2:02 PM, Quintin Beukes <qu...@last.za.net>
> wrote:
>> To achieve this I had a look at the OpenEJB code.
>>
>> Would the following be a valid way of doing so. I understand it's not
>> portable at all, though like I mentioned this is acceptable for this
>> situation. Much of our authentication/authorization code for the
>> client side is not portable, as JavaEE doesn't provide much on this
>> topic. I tried to stay by the spec where possible, though.
>>
>> So in:
>> ./container/openejb-core/src/main/java/org/apache/openejb/core/security/AbstractSecurityService.java
>> I found getCallerPrincipal(). I noticed it access the security service
>> and fetch the Principals like so:
>> ThreadContext threadContext = ThreadContext.getThreadContext();
>> SecurityContext securityContext =
>> threadContext.get(SecurityContext.class);
>> Set<Principal> principals =
>> securityContext.subject.getPrincipals();
>>
>> Can I do this inside an EJB to access the principals as well? I figure
>> it should work, though I'd just like to be sure and I don't have any
>> way to test until tomorrow.
>>
>> Thanks,
>> Quintin Beukes
>>
>>
>>
>> On Sat, Nov 14, 2009 at 1:17 PM, Quintin Beukes <qu...@last.za.net>
>> wrote:
>>> Hey,
>>>
>>> I've got a bunch of @RolesAllowed annotations, which basically
>>> reference the group principals of my users. They work perfectly.
>>> Further I can also retrieve the subject name by accessing the
>>> UserPrincipal through the EJBContext.
>>>
>>> How can I retrieve all the group principal, or "Role Names". This is
>>> available to OpenEJB, as it uses it to authorize my requests.
>>>
>>> I can't read them from the database, as the role names in the database
>>> are different from those used in OpenEJB. I'm using Geronimo role name
>>> mappings for this. For example, my EJBs would be annotated with
>>> @RolesAllowed({"Personnel Admin", "Personnel Read Access}), and then I
>>> have in the database a role "Lamp Room Staff". This role would then be
>>> mapped to a bunch of EJB roles, including "Personnel Read Access",
>>> "Create Lamp", "Assign Lamp", etc.
>>>
>>> For the server side it's fine to not have a list of the roles, as
>>> OpenEJB takes care of it all, and where more complex authorization is
>>> needed I just call ejbContext.isCallerInRole(...). Though my client
>>> side front end also has authorization in it. This is mostly just to
>>> show/hide actions allowed for a given user.
>>>
>>> As a temporary fix I have a method "List getOperatorRoles()", which
>>> takes a list of all roles and then iterates isCalledInRole, building a
>>> list based on the result of this method. I can't continue doing this
>>> though, as it increases maintenance and "breaks" modularity.
>>>
>>> How can I retrieve a list of all roles? Even if it means I have to go
>>> against the standard for this one thing, in which case I'll put it in
>>> a utility class which validates it's environment and raise an error +
>>> description when run in another server. This way when moving it I'll
>>> remember to find another way of achieving the same. I don't think this
>>> will happen anyway.
>>>
>>> Quintin Beukes
>>>
>>
>
>
--
View this message in context: http://old.nabble.com/Retrieving-Group-Principals-tp26349206p26386654.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Retrieving Group Principals
Posted by Quintin Beukes <qu...@last.za.net>.
Or maybe a better way would be to use a custom SecurityService (which
could extend the GeronimoSecurityService) in some way? Though this
would still require accessing the ThreadContext.
Quintin Beukes
On Sat, Nov 14, 2009 at 2:02 PM, Quintin Beukes <qu...@last.za.net> wrote:
> To achieve this I had a look at the OpenEJB code.
>
> Would the following be a valid way of doing so. I understand it's not
> portable at all, though like I mentioned this is acceptable for this
> situation. Much of our authentication/authorization code for the
> client side is not portable, as JavaEE doesn't provide much on this
> topic. I tried to stay by the spec where possible, though.
>
> So in: ./container/openejb-core/src/main/java/org/apache/openejb/core/security/AbstractSecurityService.java
> I found getCallerPrincipal(). I noticed it access the security service
> and fetch the Principals like so:
> ThreadContext threadContext = ThreadContext.getThreadContext();
> SecurityContext securityContext =
> threadContext.get(SecurityContext.class);
> Set<Principal> principals = securityContext.subject.getPrincipals();
>
> Can I do this inside an EJB to access the principals as well? I figure
> it should work, though I'd just like to be sure and I don't have any
> way to test until tomorrow.
>
> Thanks,
> Quintin Beukes
>
>
>
> On Sat, Nov 14, 2009 at 1:17 PM, Quintin Beukes <qu...@last.za.net> wrote:
>> Hey,
>>
>> I've got a bunch of @RolesAllowed annotations, which basically
>> reference the group principals of my users. They work perfectly.
>> Further I can also retrieve the subject name by accessing the
>> UserPrincipal through the EJBContext.
>>
>> How can I retrieve all the group principal, or "Role Names". This is
>> available to OpenEJB, as it uses it to authorize my requests.
>>
>> I can't read them from the database, as the role names in the database
>> are different from those used in OpenEJB. I'm using Geronimo role name
>> mappings for this. For example, my EJBs would be annotated with
>> @RolesAllowed({"Personnel Admin", "Personnel Read Access}), and then I
>> have in the database a role "Lamp Room Staff". This role would then be
>> mapped to a bunch of EJB roles, including "Personnel Read Access",
>> "Create Lamp", "Assign Lamp", etc.
>>
>> For the server side it's fine to not have a list of the roles, as
>> OpenEJB takes care of it all, and where more complex authorization is
>> needed I just call ejbContext.isCallerInRole(...). Though my client
>> side front end also has authorization in it. This is mostly just to
>> show/hide actions allowed for a given user.
>>
>> As a temporary fix I have a method "List getOperatorRoles()", which
>> takes a list of all roles and then iterates isCalledInRole, building a
>> list based on the result of this method. I can't continue doing this
>> though, as it increases maintenance and "breaks" modularity.
>>
>> How can I retrieve a list of all roles? Even if it means I have to go
>> against the standard for this one thing, in which case I'll put it in
>> a utility class which validates it's environment and raise an error +
>> description when run in another server. This way when moving it I'll
>> remember to find another way of achieving the same. I don't think this
>> will happen anyway.
>>
>> Quintin Beukes
>>
>
Re: Retrieving Group Principals
Posted by Quintin Beukes <qu...@last.za.net>.
To achieve this I had a look at the OpenEJB code.
Would the following be a valid way of doing so. I understand it's not
portable at all, though like I mentioned this is acceptable for this
situation. Much of our authentication/authorization code for the
client side is not portable, as JavaEE doesn't provide much on this
topic. I tried to stay by the spec where possible, though.
So in: ./container/openejb-core/src/main/java/org/apache/openejb/core/security/AbstractSecurityService.java
I found getCallerPrincipal(). I noticed it access the security service
and fetch the Principals like so:
ThreadContext threadContext = ThreadContext.getThreadContext();
SecurityContext securityContext =
threadContext.get(SecurityContext.class);
Set<Principal> principals = securityContext.subject.getPrincipals();
Can I do this inside an EJB to access the principals as well? I figure
it should work, though I'd just like to be sure and I don't have any
way to test until tomorrow.
Thanks,
Quintin Beukes
On Sat, Nov 14, 2009 at 1:17 PM, Quintin Beukes <qu...@last.za.net> wrote:
> Hey,
>
> I've got a bunch of @RolesAllowed annotations, which basically
> reference the group principals of my users. They work perfectly.
> Further I can also retrieve the subject name by accessing the
> UserPrincipal through the EJBContext.
>
> How can I retrieve all the group principal, or "Role Names". This is
> available to OpenEJB, as it uses it to authorize my requests.
>
> I can't read them from the database, as the role names in the database
> are different from those used in OpenEJB. I'm using Geronimo role name
> mappings for this. For example, my EJBs would be annotated with
> @RolesAllowed({"Personnel Admin", "Personnel Read Access}), and then I
> have in the database a role "Lamp Room Staff". This role would then be
> mapped to a bunch of EJB roles, including "Personnel Read Access",
> "Create Lamp", "Assign Lamp", etc.
>
> For the server side it's fine to not have a list of the roles, as
> OpenEJB takes care of it all, and where more complex authorization is
> needed I just call ejbContext.isCallerInRole(...). Though my client
> side front end also has authorization in it. This is mostly just to
> show/hide actions allowed for a given user.
>
> As a temporary fix I have a method "List getOperatorRoles()", which
> takes a list of all roles and then iterates isCalledInRole, building a
> list based on the result of this method. I can't continue doing this
> though, as it increases maintenance and "breaks" modularity.
>
> How can I retrieve a list of all roles? Even if it means I have to go
> against the standard for this one thing, in which case I'll put it in
> a utility class which validates it's environment and raise an error +
> description when run in another server. This way when moving it I'll
> remember to find another way of achieving the same. I don't think this
> will happen anyway.
>
> Quintin Beukes
>