I thought about that for a while - the naming convention. And, as probably no surprise to you, I don't like it at all :)
To me 'run as' is incredibly nondescript: run what? a method? a chunk of functionality? a system task? In the context of a Subject, what are you running? Do you "run" the Subject? Blech... I personally think "Run As" is just a lame name left in place when people didn't put much thought into what that actually means and what is going on. The following examples make much more sense to me if such a method name was to exist: daemonProcess.runAs( someUser ); or incomingThread.runAs( anotherUser ); or storedProcedure.runAs( thatUser ); etc. That context of the nomenclature "Run As" makes sense to me. But to continue using that phrase instead of something else that better describes the fundamental functionality frustrates me (yes, I know I'm an OO Naming Nazi ;)). I think we should call things as they are. If one user assumes the identity of another user, call it assumeIdentity( blah ) or setAssumedIdentity( blah ) if we are to maintain JavaBean semantics. Seems infinitely cleaner to me. This kind of attention to detail and intuitive naming conventions is one of many reasons why I think JSecurity makes much more sense than other frameworks. I think "Run As" is convention only because no one has provided a better alternative and people just stuck with it. Just my biased opinion of course... On Mon, Dec 15, 2008 at 3:42 PM, Jeremy Haile <[email protected]> wrote: > Yeah - other than where they reside and perhaps naming (I find the term > "run as" more intuitive and common than "assumed identity"), I agree with > everything. > > I like storing the principal and run-as principal in the session, and > having the run-as be invisible to most calling code. Since authentication > and authorization are two different operations on our realms, it should be > easy to swap out the principal behind the scenes and have everything else > work smoothly. > > > On Dec 15, 2008, at 3:37 PM, Les Hazlewood wrote: > > 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> >
