Also, by keeping it in a sub-interface, we guarantee that these types of operations can be more secure. For example, in a client/server scenario, maybe the client tier can never call these methods, but the Server tier could...
On Mon, Dec 15, 2008 at 2:51 PM, Les Hazlewood <[email protected]>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 >>>> >>> >>> >> >
