Hehe - well I don't disagree with you, although I think that you could
make an argument that subject.runAs( anotherUser ) isn't that
confusing. There's also something to be said for following the
terminology and conventions that people understand and are used to.
For example, I can't stand the term "granted authority" that Spring
Security uses instead of calling it roles or permissions. They
probably had a similar mindset when they came up with that term -
thinking that it was more accurate/descriptive/whatever.
I'm just playing devil's advocate here - I'm kind of on the fence on
this issue. I'd love to get feedback from other folks out there as to
what they think would be more accurate/intuitive/easy-to-understand.
Anyone?
Jeremy
On Dec 15, 2008, at 3:58 PM, Les Hazlewood wrote:
I thought about that for a while - the naming convention.
And, as probably no surprise to you, I don't like it at all :)
To me 'run as' is incredibly nondescript: run what? a method? a
chunk of
functionality? a system task? In the context of a Subject, what are
you
running? Do you "run" the Subject? Blech...
I personally think "Run As" is just a lame name left in place when
people
didn't put much thought into what that actually means and what is
going on.
The following examples make much more sense to me if such a method
name was
to exist:
daemonProcess.runAs( someUser ); or
incomingThread.runAs( anotherUser ); or
storedProcedure.runAs( thatUser ); etc.
That context of the nomenclature "Run As" makes sense to me. But to
continue using that phrase instead of something else that better
describes
the fundamental functionality frustrates me (yes, I know I'm an OO
Naming
Nazi ;)).
I think we should call things as they are. If one user assumes the
identity
of another user, call it assumeIdentity( blah ) or
setAssumedIdentity( blah
) if we are to maintain JavaBean semantics. Seems infinitely
cleaner to
me.
This kind of attention to detail and intuitive naming conventions is
one of
many reasons why I think JSecurity makes much more sense than other
frameworks. I think "Run As" is convention only because no one has
provided
a better alternative and people just stuck with it. Just my biased
opinion
of course...
On Mon, Dec 15, 2008 at 3:42 PM, Jeremy Haile <[email protected]>
wrote:
Yeah - other than where they reside and perhaps naming (I find the
term
"run as" more intuitive and common than "assumed identity"), I
agree with
everything.
I like storing the principal and run-as principal in the session, and
having the run-as be invisible to most calling code. Since
authentication
and authorization are two different operations on our realms, it
should be
easy to swap out the principal behind the scenes and have
everything else
work smoothly.
On Dec 15, 2008, at 3:37 PM, Les Hazlewood wrote:
Assuming we have yet to agree on where these methods reside, do you
agree
with everything else? Are you OK with the architectural approaches
discussed thus far?
I also want to make sure anyone else has the ability to review and
object
or
make suggestions. Anyone else please speak up :) This is a
notable and
important feature, so it is good to have due diligence...
On Mon, Dec 15, 2008 at 3:26 PM, Jeremy Haile <[email protected]>
wrote:
True.. =)
I still like just adding them to Subject rather than a
sub-interface...but
that's just my opinion and I respect yours as well.
Anyone else what to chime in here?
On Dec 15, 2008, at 3:14 PM, Les Hazlewood wrote:
I agree that it feels strange - its also strange to ask the
Subject if it
is
permitted or has a role or not: "Do I have the 'blah'
permission? SURE
I
do :)"
We enable this because it is much easier to understand and code
against.
Since the Subject delegates to the SecurityManager, we always
enforce
stuff
in that layer anyway.
If you were an application programmer, wouldn't you want to just
call
this
in your code:
currentUser.assumeIdentity( anotherUserId );
?
Then the securityManager implementation could check first if the
currently
executing user has a specific permission. That permission could
be
"assumeIdentity", a string, by default. But then we could have
a method
on
the SecurityManager implementation:
setAssumeIdentityPermission( String permissionToCheck );
Allowing the individual configuring JSecurity to check for another
permission instead.
It seems like this is more desireable from the programmer's
point of
view,
but still enforces security of not allowing just anyone to
assume an
identity.
Thoughts?
On Mon, Dec 15, 2008 at 2:56 PM, Jeremy Haile <[email protected]>
wrote:
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
