You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by Les Hazlewood <lh...@apache.org> on 2008/12/15 20:10:10 UTC
Assumed Identity, aka 'Run As' functionality as a 1.0 feature
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
Re: Assumed Identity, aka 'Run As' functionality as a 1.0 feature
Posted by Jeremy Haile <jh...@fastmail.fm>.
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 <jh...@fastmail.fm>
> 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
>>>
>>
>>
Re: Assumed Identity, aka 'Run As' functionality as a 1.0 feature
Posted by Les Hazlewood <lh...@apache.org>.
Yep, as you said - sometimes convention overrules (my) logic, just for
clarity's sake. I'm open to the possibility that the majority of people
just _want_ "runAs" as the convention, and then I'll just have to give in :)
I care more that people find the framework easy to use and understand than
anything else. I'm just hoping that people like my suggestion over 'run as'
- it would be a bonus for me and then I could sleep well at night knowing
that good naming exists :)
Note: I'm gonna ramble for the remainder of this email, so please feel free
to ignore the rest of it if you're not interested in my thoughts on Acegi's
naming convention :) ...
On the side note about Acegi/Spring Security - I think the terminology
'granted authority' makes sense *if you don't make a distinction between
roles and permissions*, as they do not (from what I understand, as I've
never used it before). They are both Strings in the Acegi world, and so,
they let the underlying DAO implementation decide how the checks work or
not. I guess if you had to make a term that would encompass both roles and
permissions as artifacts, then 'granted authority' isn't so bad.
But I don't think the biggest flaw with the 'granted authority' nomenclature
is the name itself - it is IMO the underlying assumptions that are
solidified in Acegi's mental model - that roles and permissions aren't
different enough to treat them separately. That's the real issue I think.
I don't like 'granted authority' because Roles and Permissions are actually
different in practice - at least in every context I've been exposed to.
Roles are an association mechanism for users, aggregating (often assumed)
abilities into easily referenceable distinction. Permissions on the other
hand are based on raw functionality of the application (opening files,
editing posts, etc).
Their one huge difference of course is that, at least in our framework,
Permissions support implication logic whereas Roles do not. I suppose that
is just an implementation detail to the Acegi guys, wheras it makes more
sense to us (and to our users) to make the distinction part of the API. But
I venture to say that everyone to sees our API at least has a concept of
what Roles and Permissions are, whereas that is very hard to say about
'GrantedAuthority'.
In any case, I vote for the name which presents the least cognitive
friction. Things should make sense whenever possible without requiring the
need to live in the API docs...
Cheers,
Les
On Mon, Dec 15, 2008 at 4:10 PM, Jeremy Haile <jh...@fastmail.fm> wrote:
> 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 <jh...@fastmail.fm> 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 <jh...@fastmail.fm>
>>>> 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 <jh...@fastmail.fm>
>>>>>> 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 <
>>>>>>>> lhazlewood@apache.org
>>>>>>>>
>>>>>>>> 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 <jh...@fastmail.fm>
>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>
Re: Assumed Identity, aka 'Run As' functionality as a 1.0 feature
Posted by Jeremy Haile <jh...@fastmail.fm>.
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 <jh...@fastmail.fm>
> 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 <jh...@fastmail.fm>
>>> 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 <jh...@fastmail.fm>
>>>>> 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 <lhazlewood@apache.org
>>>>>>>
>>>>>>> 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 <jhaile@fastmail.fm
>>>>>>>> >
>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>
Re: Assumed Identity, aka 'Run As' functionality as a 1.0 feature
Posted by Les Hazlewood <lh...@apache.org>.
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 <jh...@fastmail.fm> 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 <jh...@fastmail.fm> 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 <jh...@fastmail.fm>
>>>> 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 <lhazlewood@apache.org
>>>>>>
>>>>>> 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 <jh...@fastmail.fm>
>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>
Re: Assumed Identity, aka 'Run As' functionality as a 1.0 feature
Posted by Jeremy Haile <jh...@fastmail.fm>.
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 <jh...@fastmail.fm>
> 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 <jh...@fastmail.fm>
>>> 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 <lhazlewood@apache.org
>>>>>
>>>>>> 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
>>>>>> <jh...@fastmail.fm>
>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
Re: Assumed Identity, aka 'Run As' functionality as a 1.0 feature
Posted by Les Hazlewood <lh...@apache.org>.
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 <jh...@fastmail.fm> 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 <jh...@fastmail.fm> 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 <lhazlewood@apache.org
>>>>
>>>>> 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 <jh...@fastmail.fm>
>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>
Re: Assumed Identity, aka 'Run As' functionality as a 1.0 feature
Posted by Jeremy Haile <jh...@fastmail.fm>.
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 <jh...@fastmail.fm>
> 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
>>> <lhazlewood@apache.org
>>>> 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 <jh...@fastmail.fm>
>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>
Re: Assumed Identity, aka 'Run As' functionality as a 1.0 feature
Posted by Les Hazlewood <lh...@apache.org>.
In actuality, those other methods would be passthrough methods to the
SecurityManager like all the others, and that layer could check/enforce
whatever it wants. Anyone could subclass the SM implementation, or provide
an implementation of an interface (that we have yet to define) to that
implements this logic. The point is, is that all of this stuff would
execute inside the SecurityManager, where you rightly say it belongs...
On Mon, Dec 15, 2008 at 3:14 PM, Les Hazlewood <lh...@apache.org>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 <jh...@fastmail.fm> 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 <lhazlewood@apache.org
>>> >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 <jh...@fastmail.fm>
>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>
>
Re: Assumed Identity, aka 'Run As' functionality as a 1.0 feature
Posted by Les Hazlewood <lh...@apache.org>.
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 <jh...@fastmail.fm> 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 <lhazlewood@apache.org
>> >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 <jh...@fastmail.fm>
>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>
>
Re: Assumed Identity, aka 'Run As' functionality as a 1.0 feature
Posted by Jeremy Haile <jh...@fastmail.fm>.
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
> <lh...@apache.org>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 <jh...@fastmail.fm>
>> 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
>>>>
>>>
>>>
>>
Re: Assumed Identity, aka 'Run As' functionality as a 1.0 feature
Posted by Les Hazlewood <lh...@apache.org>.
Also, by keeping it in a sub-interface, we guarantee that these types of
operations can be more secure. For example, in a client/server scenario,
maybe the client tier can never call these methods, but the Server tier
could...
On Mon, Dec 15, 2008 at 2:51 PM, Les Hazlewood <lh...@apache.org>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 <lh...@apache.org>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 <jh...@fastmail.fm> 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
>>>>
>>>
>>>
>>
>
Re: Assumed Identity, aka 'Run As' functionality as a 1.0 feature
Posted by Les Hazlewood <lh...@apache.org>.
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 <lh...@apache.org>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 <jh...@fastmail.fm> 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
>>>
>>
>>
>
Re: Assumed Identity, aka 'Run As' functionality as a 1.0 feature
Posted by Les Hazlewood <lh...@apache.org>.
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 <jh...@fastmail.fm> 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
>>
>
>
Re: Assumed Identity, aka 'Run As' functionality as a 1.0 feature
Posted by Jeremy Haile <jh...@fastmail.fm>.
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
Re: Assumed Identity, aka 'Run As' functionality as a 1.0 feature
Posted by Les Hazlewood <lh...@apache.org>.
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 <lh...@apache.org>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
>
>
>