Thanks. I think that may be exactly what I needed. Matthew
-----Original Message----- From: Manoj Khangaonkar [mailto:[email protected]] Sent: Wednesday, October 19, 2011 7:43 PM To: [email protected] 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 <[email protected]> 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:[email protected]] > Sent: Tuesday, October 18, 2011 5:35 PM > To: [email protected] > 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 <[email protected]> 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/
