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
