Just to clarify the discussion here: a user asked a specific question
on the user list. Les then raised the question of supporting "run-as"
in the framework. These are two different questions in my opinion.
Question #1: If a user today wants to implement a super-user feature
so that they can log into their application as another user, how can
they do that with the framework as it is today?
For this question, I advocate writing a custom realm that simply
returns a SimpleAuthenticationInfo object with the "run as" user's
principal and the authenticating user's credentials. If you need
auditing of who the user "really is", you can just add another field
to your principal to track that. This is the simplest approach to
implementing a super-user feature with the current framework and one
we've used here for a long time successfully.
Question #2: How can we implement "run-as" support in JSecurity so
that one user can permanently OR temporarily run as a different user
and the "run-as" user can be changed at runtime?
For this question, I advocate a solution similar to what you already
do - basically have JSecurity store the authenticated principal AND a
run-as principal. This would be invisibly hidden behind the Subject
interface for most security operations. However, the Subject
interface would also allow you to get at the origina/authenticated
identity.
For Question #2, I advocate NOT following my solution to #1 because a)
solution #1 doesn't support changing the user after login (at least
not without a mutable principal) b) if the framework supported it,
realms shouldn't have to do anything special to support "run as" and
c) JSecurity shouldn't dictate how someone's principal is structured
(via an interface or otherwise)
I'd prefer just keeping that one method in the core Subject
interface. The reason is that if "run as" is a core part of
JSecurity, why should you have to cast your Subject to something else
in order to get to the original identity? Will all code that accesses
that have to account for the fact that their implementation of Subject
might not implement that method? I don't think it should have to.
Most users will never write an implementation of the Subject class -
they'll just use the one that comes with JSecurity. And if they do
implement their own, it's easy to implement that method. Even if they
don't support "run as" - they can always make it just delegate to
"getPrincipal()"
On Dec 15, 2008, at 2:37 PM, Les Hazlewood 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
