On Wed, Sep 25, 2013 at 6:54 PM, <[email protected]> wrote: > I have a requirement to allow Subject.runAs(UserB) but with a limited set > of > permissions. > eg I want to assume the identity of a person, but without allowing > permission to > leave the house for the assumed identity. but if the person logs in > directly > they can do anything. >
I'm not sure what you mean 'leave the house'. Could you please elaborate? > I have a user->ro > -- > Les Hazlewood | @lhazlewood > CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 > ->permissions model, and the most reasonable place to assess > such a use seems for me to do something like: > > protected AuthorizationInfo doGetAuthorizationInfo(final > PrincipalCollection > principals) { > > //somehow get the Subject for the given PrincipalCollection, then > if(subject.isRunAs()) > check the parent subjects permissions (which maybe has something like > canRunAs:rolea,roleb:userid) > and use the roles defined there to determine the permissions with > which > to build AuthorizationInfo > ... > } > The Subject is really supposed to be a 'higher level' concept that sits above the Realm layer. Realms really know how to resolve identities and/or role/permissions for a given identity (which is represented in the PrincipalCollection). Unfortunately, I can't think of a clean way to do what you are requesting, since you don't want to really 'run as' a particular user - it appears that you want a 'merged view' of two users, unless I misunderstood you (which is totally possible ;)). Maybe your approach might be better handled at the point where the runAs election is occurring? For example: if (currentSubject.isPermitted("user:userId:runAs:roleA,roleB")) { currentSubject.runAs(otherUserIdentity); } I recommend this in any event - you should ideally guard if a user is allowed to assume the identity of another, and the best place to do this is before executing subject.runAs. > PS - as an aside, the shiro documentation says that shiro has no notion of > roles->permissions association because its so application specific. But > shiro's > stock iniRealm and all its subclasses understand the association very well > and I > think it a bit obtuse that a bunch of work is required if you want this > association with a realm thats not extending any of the iniRealm > heirarchy. - > should be standard since its already available in the case where most > people > will start with Shiro. > This is good feedback, thanks Jason. I have come to this opinion as well. I think there is a 'happy medium' where we can support more out of the box authorization association schemes for the 80/20 use cases. If this is ideally designed, it can be an optional feature to those that wish to use it, while others with authorization models that don't fit it could default to a less 'opinionated' mechanism (so they can do whatever they want). Cheers, Les
