You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by thlim <ss...@gmail.com> on 2011/10/18 15:32:54 UTC
Adding Scope to Permission Check
Knowing that Shiro allows me to define permissions onto an instance, for e.g.
"project:edit:project_a", is there another way to do this differently?
For e.g., he is the Project Manager for Project A and he is allowed to
edit/view/delete Project A properties. However, he's is a Consultant who can
only view Project B. Given this scenario, I will assign him the Project
Manager and Consultant roles. Given how Shiro checks permissions (or how I
understood it), Shiro would allow him to edit Project B as well. How to I
limit his Project Manager role (along with the permissions) to Project A
without having to copying multiple permissions e.g.
"project:edit:project_c", "project:edit:project_d" for different projects
where he is also the Project Manager.
Please advice
Thanks
/lim/
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Adding-Scope-to-Permission-Check-tp6904602p6904602.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Adding Scope to Permission Check
Posted by Manoj Khangaonkar <kh...@gmail.com>.
Hi Mattew,
Glad that helps.
But I will agree with anyone who thinks that while passing arbitrary
context in a PrincipalCollection works, it
is less than elegant.
I think there is room for an enhancement in Shiro here. When dealing
with large number of resources and permissions, the
realm returning all Permissions for a PrincipalCollection is just not efficient.
In distributed and highly scalable environments , there is a need to
partition storage and caching of permissions. Just creating
multiple realms is not sufficient. Also where integration applications
developed by different teams, there is a need to be able to
accomodate different permission models.
Perhaps we need the explicit ability to specify context while checking
permissions and retrieving permissions. Depending on the context, the
realm may
return only a subset of the permissions. Additionally caching may be
done based on context.
May be a Context interface that can take arbitrary name,value pairs are data.
public interface PermissionContext {
public void setAttribute(String name, Object value) ;
public Object getAttribute(String name) ;
}
Subject would have an additional isPermitted method that takes
PermissionContext as parameter
Subject.isPermitted(PermissionContext, Permission)
Realm would need an additional doGetAuthorizationInfo method that
takes PermissionContext as parameter
doGetAuthorizationInfo(PermissionContext
The implementor of the Realm would use the data in PermissionContext
to customize what permissions are returned.
AuthorizingRealm currently glues Shiro to your Realm. This would need
to change it a little bit to pass the
PermissionContext to doGetAuthorizationInfo(PermissionContext) method.
AuthorizingRealm would also need to cache
based on context.
Another disadvantage of having only
doGetAuthorizationInfo(PrincipalCollection) is that it almost forces
you to associate
permissions to principals (or Users). In many access control systems ,
the most famous of which is the unix file system, the
permissioning metadata is stored with resource ( file inode in unix)
and not with the user. Supporting permission retrieval based on
abritrary context will
let Shiro support such use cases as well.
I would be interested in hearing what the community feels about this suggestion.
-- Manoj
On Thu, Oct 20, 2011 at 2:53 PM, Copeland, Matthew M <ma...@ku.edu> wrote:
>
> Thanks. I think that may be exactly what I needed.
>
> Matthew
>
> -----Original Message-----
> From: Manoj Khangaonkar [mailto:khangaonkar@gmail.com]
> Sent: Wednesday, October 19, 2011 7:43 PM
> To: user@shiro.apache.org
> Subject: Re: Adding Scope to Permission Check
>
> The permissions for a Prinicipal ( Actually principalCollection) is given to Shiro by the Realm method
>
> doGetAuthorizationInfo(PrincipalCollection p)
>
> Most of the time, people use only one Principal which is the username.
> But you can use additional principals which can be any attribute like a group and then use these principals to retrieve the right permissions from your repository.
>
> Assuming you do not want to logout, you can use Subject.runAs(PrincipalCollection p) to switch context.
>
> Manoj
>
> On Wed, Oct 19, 2011 at 8:46 AM, Copeland, Matthew M <ma...@ku.edu> wrote:
>> I'm struggling with this same problem right now with groups rather than projects, but it's basically the exact same issue. The role has permissions to do a certain things. The user has a given role within a certain context, but not within other contexts. I've found the original poster's question multiple times on the list in one form or another.
>>
>> Is there a way to pass the rest of the contextual information into
>> shiro, so that in my realm I can assign the appropriate roles and
>> permissions for the given context the user is working in at the time?
>> Obviously, it would require the ability to change the context at
>> different times. (It almost sounds like being able to do an executeAs
>> type of call, but it doesn't quite work that way.)
>>
>> I'd rather not have to do some kind of hack in my jsp pages, where I'm adding on the group name at the end of each of the many permissions checks. I won't be creating a separate page for every single group that gets created, so I'd like to be able to set the context internally before going to render the view. It seems like a rather inelegant way to handle it, if you have to build up the permission name in the page for each check, or set a variable with each permission name, so that you can fill in the appropriate value at the time. Is there a better way to handle this?
>>
>> I'm not afraid to go mucking around in the internals of shiro to get it done, but I'm having trouble finding a way to get the information into the realm. I was considering passing it in with the principals. It'd probably require an internal logout/login to change context, but I've been unable to find the location of how the principals get set and passed to the realm. (Looking for the principal setting code took me all over the core code-base.) Any ideas? Any hope that this kind of functionality will be built in to a new release soon?
>>
>> Thanks,
>>
>> Matthew
>>
>>
>> -----Original Message-----
>> From: Jared Bunting [mailto:jared.bunting@peachjean.com]
>> Sent: Tuesday, October 18, 2011 5:35 PM
>> To: user@shiro.apache.org
>> Subject: Re: Adding Scope to Permission Check
>>
>> I would add that you can build these permissions up in your realm.
>>
>> So, in your realm you look at your user database, you see that User1
>> has project:edit and has access to project_a so you assign him
>> permission project:edit:project_a and so forth.
>>
>> In other words, your data storage format does not have to explicitly
>> mimic your shiro permission/role structure.
>>
>> -Jared
>>
>> On 10/18/2011 02:29 PM, Manoj Khangaonkar wrote:
>>> Hi,
>>>
>>> Role based permissions works best for coarse grained permissions.
>>>
>>> Having a generic ProjectManager role works well when you want to give
>>> permissions to all projects.
>>>
>>> When you want to do permissions at an instance level - projectA ,
>>> projectB , projectC and so on you are better of associating the
>>> permissions directly with user.
>>>
>>> You would associate
>>>
>>> User1 has permissions
>>> project:edit:project_a
>>> project:view:project_b
>>>
>>> User2 has permissions
>>> project:view:Project_a
>>> project:edit:project_b
>>>
>>> If you try to do instance specific permission using roles, you will
>>> need to create many roles like ProjectManagerforA, ConsultantforA ..
>>> and so on.
>>>
>>> Hope that helps
>>>
>>> Manoj
>>>
>>>
>>> On Tue, Oct 18, 2011 at 6:32 AM, thlim <ss...@gmail.com> wrote:
>>>> Knowing that Shiro allows me to define permissions onto an instance, for e.g.
>>>> "project:edit:project_a", is there another way to do this differently?
>>>>
>>>> For e.g., he is the Project Manager for Project A and he is allowed
>>>> to edit/view/delete Project A properties. However, he's is a
>>>> Consultant who can only view Project B. Given this scenario, I will
>>>> assign him the Project Manager and Consultant roles. Given how
>>>> Shiro checks permissions (or how I understood it), Shiro would allow
>>>> him to edit Project B as well. How to I limit his Project Manager
>>>> role (along with the permissions) to Project A without having to copying multiple permissions e.g.
>>>> "project:edit:project_c", "project:edit:project_d" for different
>>>> projects where he is also the Project Manager.
>>>>
>>>> Please advice
>>>>
>>>> Thanks
>>>>
>>>> /lim/
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://shiro-user.582556.n2.nabble.com/Adding-Scope-to-Permission-Ch
>>>> eck-tp6904602p6904602.html Sent from the Shiro User mailing list
>>>> archive at Nabble.com.
>>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
> --
> http://khangaonkar.blogspot.com/
>
>
>
--
http://khangaonkar.blogspot.com/
Re: Adding Scope to Permission Check
Posted by Manoj Khangaonkar <kh...@gmail.com>.
Hi Mattew,
Glad that helps.
But I will agree with anyone who thinks that while passing arbitrary
context in a PrincipalCollection works, it
is less than elegant.
I think there is room for an enhancement in Shiro here. When dealing
with large number of resources and permissions, the
realm returning all Permissions for a PrincipalCollection is just not efficient.
In distributed and highly scalable environments , there is a need to
partition storage and caching of permissions. Just creating
multiple realms is not sufficient. Also where integration applications
developed by different teams, there is a need to be able to
accomodate different permission models.
Perhaps we need the explicit ability to specify context while checking
permissions and retrieving permissions. Depending on the context, the
realm may
return only a subset of the permissions. Additionally caching may be
done based on context.
May be a Context interface that can take arbitrary name,value pairs are data.
public interface PermissionContext {
public void setAttribute(String name, Object value) ;
public Object getAttribute(String name) ;
}
Subject would have an additional isPermitted method that takes
PermissionContext as parameter
Subject.isPermitted(PermissionContext, Permission)
Realm would need an additional doGetAuthorizationInfo method that
takes PermissionContext as parameter
doGetAuthorizationInfo(PermissionContext
The implementor of the Realm would use the data in PermissionContext
to customize what permissions are returned.
AuthorizingRealm currently glues Shiro to your Realm. This would need
to change it a little bit to pass the
PermissionContext to doGetAuthorizationInfo(PermissionContext) method.
AuthorizingRealm would also need to cache
based on context.
Another disadvantage of having only
doGetAuthorizationInfo(PrincipalCollection) is that it almost forces
you to associate
permissions to principals (or Users). In many access control systems ,
the most famous of which is the unix file system, the
permissioning metadata is stored with resource ( file inode in unix)
and not with the user. Supporting permission retrieval based on
abritrary context will
let Shiro support such use cases as well.
I would be interested in hearing what the community feels about this suggestion.
-- Manoj
On Thu, Oct 20, 2011 at 2:53 PM, Copeland, Matthew M <ma...@ku.edu> wrote:
>
> Thanks. I think that may be exactly what I needed.
>
> Matthew
>
> -----Original Message-----
> From: Manoj Khangaonkar [mailto:khangaonkar@gmail.com]
> Sent: Wednesday, October 19, 2011 7:43 PM
> To: user@shiro.apache.org
> Subject: Re: Adding Scope to Permission Check
>
> The permissions for a Prinicipal ( Actually principalCollection) is given to Shiro by the Realm method
>
> doGetAuthorizationInfo(PrincipalCollection p)
>
> Most of the time, people use only one Principal which is the username.
> But you can use additional principals which can be any attribute like a group and then use these principals to retrieve the right permissions from your repository.
>
> Assuming you do not want to logout, you can use Subject.runAs(PrincipalCollection p) to switch context.
>
> Manoj
>
> On Wed, Oct 19, 2011 at 8:46 AM, Copeland, Matthew M <ma...@ku.edu> wrote:
>> I'm struggling with this same problem right now with groups rather than projects, but it's basically the exact same issue. The role has permissions to do a certain things. The user has a given role within a certain context, but not within other contexts. I've found the original poster's question multiple times on the list in one form or another.
>>
>> Is there a way to pass the rest of the contextual information into
>> shiro, so that in my realm I can assign the appropriate roles and
>> permissions for the given context the user is working in at the time?
>> Obviously, it would require the ability to change the context at
>> different times. (It almost sounds like being able to do an executeAs
>> type of call, but it doesn't quite work that way.)
>>
>> I'd rather not have to do some kind of hack in my jsp pages, where I'm adding on the group name at the end of each of the many permissions checks. I won't be creating a separate page for every single group that gets created, so I'd like to be able to set the context internally before going to render the view. It seems like a rather inelegant way to handle it, if you have to build up the permission name in the page for each check, or set a variable with each permission name, so that you can fill in the appropriate value at the time. Is there a better way to handle this?
>>
>> I'm not afraid to go mucking around in the internals of shiro to get it done, but I'm having trouble finding a way to get the information into the realm. I was considering passing it in with the principals. It'd probably require an internal logout/login to change context, but I've been unable to find the location of how the principals get set and passed to the realm. (Looking for the principal setting code took me all over the core code-base.) Any ideas? Any hope that this kind of functionality will be built in to a new release soon?
>>
>> Thanks,
>>
>> Matthew
>>
>>
>> -----Original Message-----
>> From: Jared Bunting [mailto:jared.bunting@peachjean.com]
>> Sent: Tuesday, October 18, 2011 5:35 PM
>> To: user@shiro.apache.org
>> Subject: Re: Adding Scope to Permission Check
>>
>> I would add that you can build these permissions up in your realm.
>>
>> So, in your realm you look at your user database, you see that User1
>> has project:edit and has access to project_a so you assign him
>> permission project:edit:project_a and so forth.
>>
>> In other words, your data storage format does not have to explicitly
>> mimic your shiro permission/role structure.
>>
>> -Jared
>>
>> On 10/18/2011 02:29 PM, Manoj Khangaonkar wrote:
>>> Hi,
>>>
>>> Role based permissions works best for coarse grained permissions.
>>>
>>> Having a generic ProjectManager role works well when you want to give
>>> permissions to all projects.
>>>
>>> When you want to do permissions at an instance level - projectA ,
>>> projectB , projectC and so on you are better of associating the
>>> permissions directly with user.
>>>
>>> You would associate
>>>
>>> User1 has permissions
>>> project:edit:project_a
>>> project:view:project_b
>>>
>>> User2 has permissions
>>> project:view:Project_a
>>> project:edit:project_b
>>>
>>> If you try to do instance specific permission using roles, you will
>>> need to create many roles like ProjectManagerforA, ConsultantforA ..
>>> and so on.
>>>
>>> Hope that helps
>>>
>>> Manoj
>>>
>>>
>>> On Tue, Oct 18, 2011 at 6:32 AM, thlim <ss...@gmail.com> wrote:
>>>> Knowing that Shiro allows me to define permissions onto an instance, for e.g.
>>>> "project:edit:project_a", is there another way to do this differently?
>>>>
>>>> For e.g., he is the Project Manager for Project A and he is allowed
>>>> to edit/view/delete Project A properties. However, he's is a
>>>> Consultant who can only view Project B. Given this scenario, I will
>>>> assign him the Project Manager and Consultant roles. Given how
>>>> Shiro checks permissions (or how I understood it), Shiro would allow
>>>> him to edit Project B as well. How to I limit his Project Manager
>>>> role (along with the permissions) to Project A without having to copying multiple permissions e.g.
>>>> "project:edit:project_c", "project:edit:project_d" for different
>>>> projects where he is also the Project Manager.
>>>>
>>>> Please advice
>>>>
>>>> Thanks
>>>>
>>>> /lim/
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://shiro-user.582556.n2.nabble.com/Adding-Scope-to-Permission-Ch
>>>> eck-tp6904602p6904602.html Sent from the Shiro User mailing list
>>>> archive at Nabble.com.
>>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
> --
> http://khangaonkar.blogspot.com/
>
>
>
--
http://khangaonkar.blogspot.com/
RE: Adding Scope to Permission Check
Posted by "Copeland, Matthew M" <ma...@ku.edu>.
Thanks. I think that may be exactly what I needed.
Matthew
-----Original Message-----
From: Manoj Khangaonkar [mailto:khangaonkar@gmail.com]
Sent: Wednesday, October 19, 2011 7:43 PM
To: user@shiro.apache.org
Subject: Re: Adding Scope to Permission Check
The permissions for a Prinicipal ( Actually principalCollection) is given to Shiro by the Realm method
doGetAuthorizationInfo(PrincipalCollection p)
Most of the time, people use only one Principal which is the username.
But you can use additional principals which can be any attribute like a group and then use these principals to retrieve the right permissions from your repository.
Assuming you do not want to logout, you can use Subject.runAs(PrincipalCollection p) to switch context.
Manoj
On Wed, Oct 19, 2011 at 8:46 AM, Copeland, Matthew M <ma...@ku.edu> wrote:
> I'm struggling with this same problem right now with groups rather than projects, but it's basically the exact same issue. The role has permissions to do a certain things. The user has a given role within a certain context, but not within other contexts. I've found the original poster's question multiple times on the list in one form or another.
>
> Is there a way to pass the rest of the contextual information into
> shiro, so that in my realm I can assign the appropriate roles and
> permissions for the given context the user is working in at the time?
> Obviously, it would require the ability to change the context at
> different times. (It almost sounds like being able to do an executeAs
> type of call, but it doesn't quite work that way.)
>
> I'd rather not have to do some kind of hack in my jsp pages, where I'm adding on the group name at the end of each of the many permissions checks. I won't be creating a separate page for every single group that gets created, so I'd like to be able to set the context internally before going to render the view. It seems like a rather inelegant way to handle it, if you have to build up the permission name in the page for each check, or set a variable with each permission name, so that you can fill in the appropriate value at the time. Is there a better way to handle this?
>
> I'm not afraid to go mucking around in the internals of shiro to get it done, but I'm having trouble finding a way to get the information into the realm. I was considering passing it in with the principals. It'd probably require an internal logout/login to change context, but I've been unable to find the location of how the principals get set and passed to the realm. (Looking for the principal setting code took me all over the core code-base.) Any ideas? Any hope that this kind of functionality will be built in to a new release soon?
>
> Thanks,
>
> Matthew
>
>
> -----Original Message-----
> From: Jared Bunting [mailto:jared.bunting@peachjean.com]
> Sent: Tuesday, October 18, 2011 5:35 PM
> To: user@shiro.apache.org
> Subject: Re: Adding Scope to Permission Check
>
> I would add that you can build these permissions up in your realm.
>
> So, in your realm you look at your user database, you see that User1
> has project:edit and has access to project_a so you assign him
> permission project:edit:project_a and so forth.
>
> In other words, your data storage format does not have to explicitly
> mimic your shiro permission/role structure.
>
> -Jared
>
> On 10/18/2011 02:29 PM, Manoj Khangaonkar wrote:
>> Hi,
>>
>> Role based permissions works best for coarse grained permissions.
>>
>> Having a generic ProjectManager role works well when you want to give
>> permissions to all projects.
>>
>> When you want to do permissions at an instance level - projectA ,
>> projectB , projectC and so on you are better of associating the
>> permissions directly with user.
>>
>> You would associate
>>
>> User1 has permissions
>> project:edit:project_a
>> project:view:project_b
>>
>> User2 has permissions
>> project:view:Project_a
>> project:edit:project_b
>>
>> If you try to do instance specific permission using roles, you will
>> need to create many roles like ProjectManagerforA, ConsultantforA ..
>> and so on.
>>
>> Hope that helps
>>
>> Manoj
>>
>>
>> On Tue, Oct 18, 2011 at 6:32 AM, thlim <ss...@gmail.com> wrote:
>>> Knowing that Shiro allows me to define permissions onto an instance, for e.g.
>>> "project:edit:project_a", is there another way to do this differently?
>>>
>>> For e.g., he is the Project Manager for Project A and he is allowed
>>> to edit/view/delete Project A properties. However, he's is a
>>> Consultant who can only view Project B. Given this scenario, I will
>>> assign him the Project Manager and Consultant roles. Given how
>>> Shiro checks permissions (or how I understood it), Shiro would allow
>>> him to edit Project B as well. How to I limit his Project Manager
>>> role (along with the permissions) to Project A without having to copying multiple permissions e.g.
>>> "project:edit:project_c", "project:edit:project_d" for different
>>> projects where he is also the Project Manager.
>>>
>>> Please advice
>>>
>>> Thanks
>>>
>>> /lim/
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://shiro-user.582556.n2.nabble.com/Adding-Scope-to-Permission-Ch
>>> eck-tp6904602p6904602.html Sent from the Shiro User mailing list
>>> archive at Nabble.com.
>>>
>>
>>
>
>
>
>
--
http://khangaonkar.blogspot.com/
Re: Adding Scope to Permission Check
Posted by Manoj Khangaonkar <kh...@gmail.com>.
The permissions for a Prinicipal ( Actually principalCollection) is
given to Shiro by the Realm method
doGetAuthorizationInfo(PrincipalCollection p)
Most of the time, people use only one Principal which is the username.
But you can use additional principals which can be any attribute like
a group and then use these principals
to retrieve the right permissions from your repository.
Assuming you do not want to logout, you can use
Subject.runAs(PrincipalCollection p) to switch context.
Manoj
On Wed, Oct 19, 2011 at 8:46 AM, Copeland, Matthew M <ma...@ku.edu> wrote:
> I'm struggling with this same problem right now with groups rather than projects, but it's basically the exact same issue. The role has permissions to do a certain things. The user has a given role within a certain context, but not within other contexts. I've found the original poster's question multiple times on the list in one form or another.
>
> Is there a way to pass the rest of the contextual information into shiro, so that in my realm I can assign the appropriate roles and permissions for the given context the user is working in at the time? Obviously, it would require the ability to change the context at different times. (It almost sounds like being able to do an executeAs type of call, but it doesn't quite work that way.)
>
> I'd rather not have to do some kind of hack in my jsp pages, where I'm adding on the group name at the end of each of the many permissions checks. I won't be creating a separate page for every single group that gets created, so I'd like to be able to set the context internally before going to render the view. It seems like a rather inelegant way to handle it, if you have to build up the permission name in the page for each check, or set a variable with each permission name, so that you can fill in the appropriate value at the time. Is there a better way to handle this?
>
> I'm not afraid to go mucking around in the internals of shiro to get it done, but I'm having trouble finding a way to get the information into the realm. I was considering passing it in with the principals. It'd probably require an internal logout/login to change context, but I've been unable to find the location of how the principals get set and passed to the realm. (Looking for the principal setting code took me all over the core code-base.) Any ideas? Any hope that this kind of functionality will be built in to a new release soon?
>
> Thanks,
>
> Matthew
>
>
> -----Original Message-----
> From: Jared Bunting [mailto:jared.bunting@peachjean.com]
> Sent: Tuesday, October 18, 2011 5:35 PM
> To: user@shiro.apache.org
> Subject: Re: Adding Scope to Permission Check
>
> I would add that you can build these permissions up in your realm.
>
> So, in your realm you look at your user database, you see that User1 has
> project:edit and has access to project_a so you assign him permission
> project:edit:project_a and so forth.
>
> In other words, your data storage format does not have to explicitly
> mimic your shiro permission/role structure.
>
> -Jared
>
> On 10/18/2011 02:29 PM, Manoj Khangaonkar wrote:
>> Hi,
>>
>> Role based permissions works best for coarse grained permissions.
>>
>> Having a generic ProjectManager role works well when you want to give
>> permissions to all projects.
>>
>> When you want to do permissions at an instance level - projectA ,
>> projectB , projectC and so on
>> you are better of associating the permissions directly with user.
>>
>> You would associate
>>
>> User1 has permissions
>> project:edit:project_a
>> project:view:project_b
>>
>> User2 has permissions
>> project:view:Project_a
>> project:edit:project_b
>>
>> If you try to do instance specific permission using roles, you will
>> need to create many roles like
>> ProjectManagerforA, ConsultantforA .. and so on.
>>
>> Hope that helps
>>
>> Manoj
>>
>>
>> On Tue, Oct 18, 2011 at 6:32 AM, thlim <ss...@gmail.com> wrote:
>>> Knowing that Shiro allows me to define permissions onto an instance, for e.g.
>>> "project:edit:project_a", is there another way to do this differently?
>>>
>>> For e.g., he is the Project Manager for Project A and he is allowed to
>>> edit/view/delete Project A properties. However, he's is a Consultant who can
>>> only view Project B. Given this scenario, I will assign him the Project
>>> Manager and Consultant roles. Given how Shiro checks permissions (or how I
>>> understood it), Shiro would allow him to edit Project B as well. How to I
>>> limit his Project Manager role (along with the permissions) to Project A
>>> without having to copying multiple permissions e.g.
>>> "project:edit:project_c", "project:edit:project_d" for different projects
>>> where he is also the Project Manager.
>>>
>>> Please advice
>>>
>>> Thanks
>>>
>>> /lim/
>>>
>>>
>>>
>>> --
>>> View this message in context: http://shiro-user.582556.n2.nabble.com/Adding-Scope-to-Permission-Check-tp6904602p6904602.html
>>> Sent from the Shiro User mailing list archive at Nabble.com.
>>>
>>
>>
>
>
>
>
--
http://khangaonkar.blogspot.com/
RE: Adding Scope to Permission Check
Posted by "Copeland, Matthew M" <ma...@ku.edu>.
I'm struggling with this same problem right now with groups rather than projects, but it's basically the exact same issue. The role has permissions to do a certain things. The user has a given role within a certain context, but not within other contexts. I've found the original poster's question multiple times on the list in one form or another.
Is there a way to pass the rest of the contextual information into shiro, so that in my realm I can assign the appropriate roles and permissions for the given context the user is working in at the time? Obviously, it would require the ability to change the context at different times. (It almost sounds like being able to do an executeAs type of call, but it doesn't quite work that way.)
I'd rather not have to do some kind of hack in my jsp pages, where I'm adding on the group name at the end of each of the many permissions checks. I won't be creating a separate page for every single group that gets created, so I'd like to be able to set the context internally before going to render the view. It seems like a rather inelegant way to handle it, if you have to build up the permission name in the page for each check, or set a variable with each permission name, so that you can fill in the appropriate value at the time. Is there a better way to handle this?
I'm not afraid to go mucking around in the internals of shiro to get it done, but I'm having trouble finding a way to get the information into the realm. I was considering passing it in with the principals. It'd probably require an internal logout/login to change context, but I've been unable to find the location of how the principals get set and passed to the realm. (Looking for the principal setting code took me all over the core code-base.) Any ideas? Any hope that this kind of functionality will be built in to a new release soon?
Thanks,
Matthew
-----Original Message-----
From: Jared Bunting [mailto:jared.bunting@peachjean.com]
Sent: Tuesday, October 18, 2011 5:35 PM
To: user@shiro.apache.org
Subject: Re: Adding Scope to Permission Check
I would add that you can build these permissions up in your realm.
So, in your realm you look at your user database, you see that User1 has
project:edit and has access to project_a so you assign him permission
project:edit:project_a and so forth.
In other words, your data storage format does not have to explicitly
mimic your shiro permission/role structure.
-Jared
On 10/18/2011 02:29 PM, Manoj Khangaonkar wrote:
> Hi,
>
> Role based permissions works best for coarse grained permissions.
>
> Having a generic ProjectManager role works well when you want to give
> permissions to all projects.
>
> When you want to do permissions at an instance level - projectA ,
> projectB , projectC and so on
> you are better of associating the permissions directly with user.
>
> You would associate
>
> User1 has permissions
> project:edit:project_a
> project:view:project_b
>
> User2 has permissions
> project:view:Project_a
> project:edit:project_b
>
> If you try to do instance specific permission using roles, you will
> need to create many roles like
> ProjectManagerforA, ConsultantforA .. and so on.
>
> Hope that helps
>
> Manoj
>
>
> On Tue, Oct 18, 2011 at 6:32 AM, thlim <ss...@gmail.com> wrote:
>> Knowing that Shiro allows me to define permissions onto an instance, for e.g.
>> "project:edit:project_a", is there another way to do this differently?
>>
>> For e.g., he is the Project Manager for Project A and he is allowed to
>> edit/view/delete Project A properties. However, he's is a Consultant who can
>> only view Project B. Given this scenario, I will assign him the Project
>> Manager and Consultant roles. Given how Shiro checks permissions (or how I
>> understood it), Shiro would allow him to edit Project B as well. How to I
>> limit his Project Manager role (along with the permissions) to Project A
>> without having to copying multiple permissions e.g.
>> "project:edit:project_c", "project:edit:project_d" for different projects
>> where he is also the Project Manager.
>>
>> Please advice
>>
>> Thanks
>>
>> /lim/
>>
>>
>>
>> --
>> View this message in context: http://shiro-user.582556.n2.nabble.com/Adding-Scope-to-Permission-Check-tp6904602p6904602.html
>> Sent from the Shiro User mailing list archive at Nabble.com.
>>
>
>
Re: Adding Scope to Permission Check
Posted by thlim <ss...@gmail.com>.
Good tip. I will try that.
I will ask again if I need further help.
Thanks
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Adding-Scope-to-Permission-Check-tp6904602p6907124.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Adding Scope to Permission Check
Posted by Jared Bunting <ja...@peachjean.com>.
I would add that you can build these permissions up in your realm.
So, in your realm you look at your user database, you see that User1 has
project:edit and has access to project_a so you assign him permission
project:edit:project_a and so forth.
In other words, your data storage format does not have to explicitly
mimic your shiro permission/role structure.
-Jared
On 10/18/2011 02:29 PM, Manoj Khangaonkar wrote:
> Hi,
>
> Role based permissions works best for coarse grained permissions.
>
> Having a generic ProjectManager role works well when you want to give
> permissions to all projects.
>
> When you want to do permissions at an instance level - projectA ,
> projectB , projectC and so on
> you are better of associating the permissions directly with user.
>
> You would associate
>
> User1 has permissions
> project:edit:project_a
> project:view:project_b
>
> User2 has permissions
> project:view:Project_a
> project:edit:project_b
>
> If you try to do instance specific permission using roles, you will
> need to create many roles like
> ProjectManagerforA, ConsultantforA .. and so on.
>
> Hope that helps
>
> Manoj
>
>
> On Tue, Oct 18, 2011 at 6:32 AM, thlim <ss...@gmail.com> wrote:
>> Knowing that Shiro allows me to define permissions onto an instance, for e.g.
>> "project:edit:project_a", is there another way to do this differently?
>>
>> For e.g., he is the Project Manager for Project A and he is allowed to
>> edit/view/delete Project A properties. However, he's is a Consultant who can
>> only view Project B. Given this scenario, I will assign him the Project
>> Manager and Consultant roles. Given how Shiro checks permissions (or how I
>> understood it), Shiro would allow him to edit Project B as well. How to I
>> limit his Project Manager role (along with the permissions) to Project A
>> without having to copying multiple permissions e.g.
>> "project:edit:project_c", "project:edit:project_d" for different projects
>> where he is also the Project Manager.
>>
>> Please advice
>>
>> Thanks
>>
>> /lim/
>>
>>
>>
>> --
>> View this message in context: http://shiro-user.582556.n2.nabble.com/Adding-Scope-to-Permission-Check-tp6904602p6904602.html
>> Sent from the Shiro User mailing list archive at Nabble.com.
>>
>
>
Re: Adding Scope to Permission Check
Posted by Manoj Khangaonkar <kh...@gmail.com>.
Hi,
Role based permissions works best for coarse grained permissions.
Having a generic ProjectManager role works well when you want to give
permissions to all projects.
When you want to do permissions at an instance level - projectA ,
projectB , projectC and so on
you are better of associating the permissions directly with user.
You would associate
User1 has permissions
project:edit:project_a
project:view:project_b
User2 has permissions
project:view:Project_a
project:edit:project_b
If you try to do instance specific permission using roles, you will
need to create many roles like
ProjectManagerforA, ConsultantforA .. and so on.
Hope that helps
Manoj
On Tue, Oct 18, 2011 at 6:32 AM, thlim <ss...@gmail.com> wrote:
> Knowing that Shiro allows me to define permissions onto an instance, for e.g.
> "project:edit:project_a", is there another way to do this differently?
>
> For e.g., he is the Project Manager for Project A and he is allowed to
> edit/view/delete Project A properties. However, he's is a Consultant who can
> only view Project B. Given this scenario, I will assign him the Project
> Manager and Consultant roles. Given how Shiro checks permissions (or how I
> understood it), Shiro would allow him to edit Project B as well. How to I
> limit his Project Manager role (along with the permissions) to Project A
> without having to copying multiple permissions e.g.
> "project:edit:project_c", "project:edit:project_d" for different projects
> where he is also the Project Manager.
>
> Please advice
>
> Thanks
>
> /lim/
>
>
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Adding-Scope-to-Permission-Check-tp6904602p6904602.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
--
http://khangaonkar.blogspot.com/