Another way to do this would be to have an AssumedIdentityManager that the SecurityManager delegates to when acquiring and binding the Subject to the application (e.g. Thread). Then whether it is stored in the session or not is an implementation detail...
On Mon, Dec 15, 2008 at 2:10 PM, Les Hazlewood <[email protected]>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 > > >
