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 >>> >> >> >
