Assuming we have yet to agree on where these methods reside, do you agree with everything else? Are you OK with the architectural approaches discussed thus far?
I also want to make sure anyone else has the ability to review and object or make suggestions. Anyone else please speak up :) This is a notable and important feature, so it is good to have due diligence... On Mon, Dec 15, 2008 at 3:26 PM, Jeremy Haile <[email protected]> wrote: > True.. =) > > I still like just adding them to Subject rather than a sub-interface...but > that's just my opinion and I respect yours as well. > > Anyone else what to chime in here? > > > > On Dec 15, 2008, at 3:14 PM, Les Hazlewood wrote: > > I agree that it feels strange - its also strange to ask the Subject if it >> is >> permitted or has a role or not: "Do I have the 'blah' permission? SURE I >> do :)" >> >> We enable this because it is much easier to understand and code against. >> Since the Subject delegates to the SecurityManager, we always enforce >> stuff >> in that layer anyway. >> >> If you were an application programmer, wouldn't you want to just call this >> in your code: >> >> currentUser.assumeIdentity( anotherUserId ); >> >> ? >> >> Then the securityManager implementation could check first if the currently >> executing user has a specific permission. That permission could be >> "assumeIdentity", a string, by default. But then we could have a method >> on >> the SecurityManager implementation: >> >> setAssumeIdentityPermission( String permissionToCheck ); >> >> Allowing the individual configuring JSecurity to check for another >> permission instead. >> >> It seems like this is more desireable from the programmer's point of view, >> but still enforces security of not allowing just anyone to assume an >> identity. >> >> Thoughts? >> >> On Mon, Dec 15, 2008 at 2:56 PM, Jeremy Haile <[email protected]> wrote: >> >> I don't see a need for getAssumedIdentity(...) - since that's what >>> getPrincipal() returns. >>> >>> I also think it feels weird that you can set and relinquish the assumed >>> identity on the subject directly - seems like there may be some logic, >>> etc. >>> wrapped around that (e.g. checking if you have the "runasuser" >>> permission, >>> etc. that feel strange inside of subject. Not sure where it belongs >>> though >>> - security manager? >>> >>> securityManager.runAs( Object principal )? >>> securityManager.revertRunAs(); (probably need a better name here) >>> >>> >>> >>> On Dec 15, 2008, at 2:51 PM, Les Hazlewood wrote: >>> >>> Oh, I guess we would need to have a few methods on that interface: >>> >>>> >>>> getOriginalIdentity() : Object >>>> getAssumedIdentity() : Object; >>>> setAssumedIdentity( Object principal ) : void >>>> relinquishAssumedIdentity() : void; >>>> >>>> On Mon, Dec 15, 2008 at 2:37 PM, Les Hazlewood <[email protected] >>>> >>>>> wrote: >>>>> >>>> >>>> Would it make more sense to have a sub-interface of Subject? >>>> >>>>> >>>>> AssumableSubject that has one method: getOriginalIdentity() : Object >>>>> >>>>> This would achieve what we want and retain backwards compatibility (if >>>>> that's something we care about). As a parallel to demonstrate this >>>>> potential solution, I like how we've sub-interfaced AuthenticationToken >>>>> and >>>>> created a RememberMeAuthenticationToken. It keeps the concept of >>>>> 'Remember >>>>> Me' entirely out of the concept of a normal login operation. That is, >>>>> the >>>>> very concept of 'RememberMe' doesn't permuate the framework at all >>>>> unless >>>>> you're actually checking for that type of behavior. The same would be >>>>> true >>>>> of a Subject sub-interface. Thoughts? >>>>> >>>>> I also agree that we may not need a Manager - I was just brainstorming. >>>>> I >>>>> would like it to be flexible enough such that they can implement their >>>>> own >>>>> mechanism for obtaining/binding assumed identities as they see fit and >>>>> we >>>>> provide a default implementation that probably just uses the Session. >>>>> >>>>> >>>>> On Mon, Dec 15, 2008 at 2:25 PM, Jeremy Haile <[email protected]> >>>>> wrote: >>>>> >>>>> Despite my last email where I stated that I personally prefer the >>>>> >>>>>> composite principal approach for run-as, I think your approach is more >>>>>> viable from a framework perspective since it doesn't force the realm >>>>>> implementor to use any particular type of principal. In other words, >>>>>> I'd >>>>>> think JSecurity would store the "actual" principal in the session (as >>>>>> it >>>>>> does now), but could also store the "run-as" principal. >>>>>> >>>>>> I also think we should add methods to the Subject that allow you to >>>>>> access >>>>>> the "actual" principal (need a better name for that). The current >>>>>> methods >>>>>> would just return the "run as" principal, if one exists. >>>>>> >>>>>> I don't like the idea of adding another manager - I prefer to keep the >>>>>> number of managers in jsecurity to a minimum, since it adds one more >>>>>> layer >>>>>> that people may need to traverse to get to what they need. I think >>>>>> "run >>>>>> as" >>>>>> is a core enough feature that it can be supported in the core security >>>>>> manager. >>>>>> >>>>>> I agree that you need to be able to change the run-as user at runtime. >>>>>> I >>>>>> think the only way to get at the "actual" user's principal would be >>>>>> through >>>>>> new methods we'd add to the Subject class. >>>>>> >>>>>> >>>>>> >>>>>> On Dec 15, 2008, at 2:10 PM, Les Hazlewood wrote: >>>>>> >>>>>> This email thread: http://markmail.org/message/wr6bzfsnf74hoaby >>>>>> >>>>>> >>>>>>> has spurred my curiosity. I really think Assumed Identity / Run As >>>>>>> should >>>>>>> be part of the core framework. Especially as a 1.0 feature. >>>>>>> >>>>>>> I'm thinking that my approach to the solution could easily be >>>>>>> incorporated >>>>>>> into JSecurity as a top-level feature. Instead of modifying a >>>>>>> sessions >>>>>>> table as I do in my own applications, because we can't guarantee that >>>>>>> approach for any application, could we just store the assumed >>>>>>> identity >>>>>>> as >>>>>>> a >>>>>>> session attribute? >>>>>>> >>>>>>> But, before we go down the road of any solution, I want to ask: >>>>>>> >>>>>>> 1. Would my solution be optimal from a framework perspective? >>>>>>> 2. Would keeping the information as another Principal, instead of >>>>>>> the >>>>>>> session, be a viable approach? Would it be better than storing it in >>>>>>> the >>>>>>> session? Maybe more secure? (I don't know). >>>>>>> >>>>>>> I just thought of #2 a bit more. If we decide that #2 is a better >>>>>>> solution >>>>>>> than using the Session, we have to understand that every Principal is >>>>>>> inherently tied to a Realm, so how would we go about setting that >>>>>>> identity? >>>>>>> How would we empower a Realm implementor to achieve this >>>>>>> functionality >>>>>>> in >>>>>>> the easiest possible manner? >>>>>>> >>>>>>> I think we need to support assuming an identity not just during >>>>>>> login, >>>>>>> but >>>>>>> at any time during the life of the 'owning' user's interaction with >>>>>>> the >>>>>>> system. Likewise relinquishing the assumed identity should be able >>>>>>> to >>>>>>> be >>>>>>> done at any time as well. >>>>>>> >>>>>>> Whatever the approach, I think the framework solution should be >>>>>>> transparent >>>>>>> as possible, so the GUI developers don't have to change code. That >>>>>>> an >>>>>>> identity is assumed should be purely transparent to any use of the >>>>>>> JSecurity >>>>>>> API, IMO. >>>>>>> >>>>>>> What do you guys think? How do you think we should go about this? >>>>>>> >>>>>>> Les >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>> >
