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