You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Les Hazlewood <lh...@apache.org> on 2008/12/18 17:28:59 UTC
Assumed Identity/Run As - we want your feedback!
Hi JSecurity community,
The JSecurity team will enable native support for the ability to assume
another user's identity at runtime, aka 'Run As' or 'Switch User'
functionality into the framework very soon. This allows the application to
look, feel and react as if the current user is another user entirely, a
functionality that is quite common in many applications.
We're looking to the community to get feedback on what people prefer this be
called in the API itself. Odds are very high that the methods to perform
this switching capability will reside in the Subject interface (or a
sub-interface of Subject, we haven't decided yet).
So, here are a few alphabetically-ordered options that seem to make sense
(don't forget a 'principal' is just an identifying attribute, like a
username or user id). If you feel so inclined, please choose one:
subject.assumeIdentity( Object principal );
subject.runAs( Object principal );
subject.switchUser( Object principal );
Please note that whatever the naming choice, the implementation will retain
raw traceability and auditing attributed to the original or 'owning' user in
all cases. You won't 'lose' that when executing this soon-to-be-created
method.
Thanks for any feedback!
Les
Re: Assumed Identity/Run As - we want your feedback!
Posted by Les Hazlewood <lh...@apache.org>.
Hi John,
There is a fine line as to what 'run as' should mean - just assuming or
'taking on' the identity of another user without authentication, or perhaps
switching state entirely, as if there were a new login. This is why I'm
strongly opposed to calling any feature 'run as' since it is incredibly
vague.
So, we might have something like Subject.assumeIdentity(PrincipalCollection
pc) or Subject.switchUser(AuthenticationToken token) or other similar
methods based on what needs to happen - it still needs to be flushed out.
Here is the issue with links to other discussions:
https://issues.apache.org/jira/browse/KI-21
Regards,
Les
On Fri, Apr 3, 2009 at 5:34 PM, John Cladmore <ju...@lorrev.org> wrote:
> Hi all.
>
> I just have a question and a suggestion about this "run as" feature to be
> implemented.
> Is Subject sufficient for "run as" method? Shouldn't this method take the
> same things as login(), which is a security token? The reason being, that
> if you imagine uesrA is authenticated, and is prompted for another username
> and passwd (as in windows) to allow access to another part of the
> application. Then we can't just provide only the Subject which is just like
> a username. Or am I missing something here about Subject? Additionally,
> considering how many new laptop have the option for fingerprint reader and
> who knows what's next, the token can be anything, an image that can be
> passed to the realm to be compared.
>
> Ok, so my suggest is that the 'run as' method take a token. I am no Ki
> expert, so please forgave me if I have missed some essential part of this
> discussion.
>
> Thanks for Ki.
>
> .v
>
> Les Hazlewood wrote:
>
>> Hi Tamás,
>>
>> There should _always_ be a Subject. A scheduled task or daemon process
>> should have a subject instance as well.
>>
>> That is why the security world uses the term 'Subject' instead of 'User',
>> since 'User' generally implies a human being. 'Subject' is general in that
>> it encompasses any state/identity information, be it a human or daemon
>> process or whatever...
>>
>> On Mon, Dec 22, 2008 at 8:46 AM, Tamás Cservenák <tamas@cservenak.net<mailto:
>> tamas@cservenak.net>> wrote:
>>
>> Hi there,
>>
>> not directly related, but I have a question: all these solutions
>> assume you already have a Subject.
>>
>> What about cases when it is not the case? (ie. scheduled tasks?)
>>
>> ~t~
>>
>>
>> On Thu, Dec 18, 2008 at 5:28 PM, Les Hazlewood
>> <lhazlewood@apache.org <ma...@apache.org>> wrote:
>>
>> Hi JSecurity community,
>>
>> The JSecurity team will enable native support for the ability
>> to assume another user's identity at runtime, aka 'Run As' or
>> 'Switch User' functionality into the framework very soon.
>> This allows the application to look, feel and react as if the
>> current user is another user entirely, a functionality that is
>> quite common in many applications.
>>
>> We're looking to the community to get feedback on what people
>> prefer this be called in the API itself. Odds are very high
>> that the methods to perform this switching capability will
>> reside in the Subject interface (or a sub-interface of
>> Subject, we haven't decided yet).
>>
>> So, here are a few alphabetically-ordered options that seem to
>> make sense (don't forget a 'principal' is just an identifying
>> attribute, like a username or user id). If you feel so
>> inclined, please choose one:
>>
>> subject.assumeIdentity( Object principal );
>> subject.runAs( Object principal );
>> subject.switchUser( Object principal );
>>
>> Please note that whatever the naming choice, the
>> implementation will retain raw traceability and auditing
>> attributed to the original or 'owning' user in all cases. You
>> won't 'lose' that when executing this soon-to-be-created method.
>>
>> Thanks for any feedback!
>>
>> Les
>>
>>
>>
>>
>> -- Thanks,
>> ~t~
>>
>>
>>
Re: Assumed Identity/Run As - we want your feedback!
Posted by John Cladmore <ju...@lorrev.org>.
Hi all.
I just have a question and a suggestion about this "run as" feature to
be implemented.
Is Subject sufficient for "run as" method? Shouldn't this method take
the same things as login(), which is a security token? The reason
being, that if you imagine uesrA is authenticated, and is prompted for
another username and passwd (as in windows) to allow access to another
part of the application. Then we can't just provide only the Subject
which is just like a username. Or am I missing something here about
Subject? Additionally, considering how many new laptop have the option
for fingerprint reader and who knows what's next, the token can be
anything, an image that can be passed to the realm to be compared.
Ok, so my suggest is that the 'run as' method take a token. I am no Ki
expert, so please forgave me if I have missed some essential part of
this discussion.
Thanks for Ki.
.v
Les Hazlewood wrote:
> Hi Tamás,
>
> There should _always_ be a Subject. A scheduled task or daemon
> process should have a subject instance as well.
>
> That is why the security world uses the term 'Subject' instead of
> 'User', since 'User' generally implies a human being. 'Subject' is
> general in that it encompasses any state/identity information, be it a
> human or daemon process or whatever...
>
> On Mon, Dec 22, 2008 at 8:46 AM, Tamás Cservenák <tamas@cservenak.net
> <ma...@cservenak.net>> wrote:
>
> Hi there,
>
> not directly related, but I have a question: all these solutions
> assume you already have a Subject.
>
> What about cases when it is not the case? (ie. scheduled tasks?)
>
> ~t~
>
>
> On Thu, Dec 18, 2008 at 5:28 PM, Les Hazlewood
> <lhazlewood@apache.org <ma...@apache.org>> wrote:
>
> Hi JSecurity community,
>
> The JSecurity team will enable native support for the ability
> to assume another user's identity at runtime, aka 'Run As' or
> 'Switch User' functionality into the framework very soon.
> This allows the application to look, feel and react as if the
> current user is another user entirely, a functionality that is
> quite common in many applications.
>
> We're looking to the community to get feedback on what people
> prefer this be called in the API itself. Odds are very high
> that the methods to perform this switching capability will
> reside in the Subject interface (or a sub-interface of
> Subject, we haven't decided yet).
>
> So, here are a few alphabetically-ordered options that seem to
> make sense (don't forget a 'principal' is just an identifying
> attribute, like a username or user id). If you feel so
> inclined, please choose one:
>
> subject.assumeIdentity( Object principal );
> subject.runAs( Object principal );
> subject.switchUser( Object principal );
>
> Please note that whatever the naming choice, the
> implementation will retain raw traceability and auditing
> attributed to the original or 'owning' user in all cases. You
> won't 'lose' that when executing this soon-to-be-created method.
>
> Thanks for any feedback!
>
> Les
>
>
>
>
> --
> Thanks,
> ~t~
>
>
Re: Assumed Identity/Run As - we want your feedback!
Posted by Les Hazlewood <lh...@apache.org>.
As an addendum Thomas, the code I gave above _does_ work today - quite well
in fact for daemon processes or intermittent logic run on behalf of a user.
A session wouldn't be created either if you didn't call Subject.getSession()
- that would be up to code that uses the Subject instance.
In other words, don't let the Filter concept be a mental block. JSecurity
works just fine outside web environments, where no Filter exists. In these
environments, the SecurityManager acquires the subject identity not from an
incoming request, but through some other mechanism - either a remoting proxy
or some other location well known to the application - a cache, a database,
etc.
Sure, how this happens is specific to the environment, just as the Filter
mechanism is specific to web environments.
I think what you're looking for would be better-documented support for using
JSecurity outside of web environments, maybe not so much on the specifics of
how a Subject works (or maybe so, I'm just speculating).
Cheers,
Les
On Tue, Dec 23, 2008 at 11:46 AM, Tamás Cservenák <ta...@cservenak.net>wrote:
> Hi there,
> yes, Jeremy is right. I would be interested in running without a filter and
> without a session (scheduled task for example).
>
> Second, think about running a background scheduled task in some user's
> space, ie. the "creator" of that task for example (so, no filter, no
> session, but I want a given User's principal :)
>
> Is persisting/having the password really needed?
>
> Do not misunderstand me, I'm not whining, just throwing into the basket
> ideas :)
>
>
> ~t~
>
>
> On Mon, Dec 22, 2008 at 5:36 PM, Les Hazlewood <lh...@apache.org>wrote:
>
>> At the moment, you can't call subject.assumeIdentity (or runAs, whatever)
>> unless you have logged in already (this is another reason why I think
>> assumeIdentity is less misleading than runAs - runAs gives no indication
>> that you must already be logged in, whereas when you 'assume' an identity,
>> it usually means you already have one to start with - anyway, moving on...).
>>
>> Again, currently in our implementation, the subject.* calls are proxies to
>> the securityManager. The first argument is the subject's principals, the
>> second argument is the additional arguments. This is important because our
>> securityManager implementation would do a permission check (if
>> isPermitted("assumeIdentity") ) before allowing the 'assumeIdentity/runAs'
>> call to execute. You need an identity against which to perform the
>> permission check.
>>
>> If you didn't have an identity, as your first example suggests (and we
>> didn't check a permission) then you're essentially providing a subject with
>> an identity _without_ verifying it. This would provide a 'hacky' ability to
>> act as any user without verification - something I wouldn't be really
>> comfortable introducing into JSecurity, at least at first glance.
>>
>> Instead, the developer should probably do the following:
>>
>> //in the thread executing work:
>> Subject daemon = securityManager.getSubject();
>> daemon.login(new UsernamePasswordToken(daemonUsername, daemonPassword) );
>> //do work...
>> daemon.logout();
>>
>> if the daemonPassword is null, that's up to the realm implementor, as they
>> have knowledge if this is allowed in their application or not for that
>> username - not something JSecurity has to worry about.
>>
>> Also, the 'logout' call would really only need to be executed upon system
>> shutdown or when the process terminates - no need to do it on each
>> invocation of the work getting run. And also, if the subject represents a
>> system/daemon user, a developer could ensure that subject's session won't
>> time out:
>>
>> //after login
>> subject.getSession().setTimeout(-1);
>>
>> Something that is often useful for daemon/system processes.
>>
>> At least that's my $0.02
>>
>> Les
>>
>>
>> On Mon, Dec 22, 2008 at 10:50 AM, Jeremy Haile <jh...@fastmail.fm>wrote:
>>
>>> I think Tamas' point is that since a scheduled job doesn't run behind the
>>> JSecurityFilter and isn't associated with a session, it may not have a
>>> Subject based on the current session. The "run as" feature could be useful
>>> to establish a Subject by which the job should run under.
>>> For example:
>>> public void myScheduledTask() {
>>> Subject subject = securityManager.runAs( myTaskPrincipal );
>>> // Do my task
>>> subject.logout();
>>> }
>>>
>>> However, by putting these methods on the subject itself - it's not as
>>> clear, since there may not be any contextual (or thread local) subject
>>> associated with the scheduled task thread.
>>>
>>> Of course, you could currently do this:
>>> public void myScheduledTask() {
>>> Subject subject = securityManager.getSubject();
>>> subject.runAs( myTaskPrincipal );
>>> // Do my task
>>> subject.logout();
>>> }
>>>
>>> Any thoughts on which approach is clearer? The first approach could just
>>> be a shorthand way to do the second approach...
>>>
>>> Jeremy
>>>
>>>
>>>
>>> On Dec 22, 2008, at 10:35 AM, Les Hazlewood wrote:
>>>
>>> Hi Tamás,
>>>
>>> There should _always_ be a Subject. A scheduled task or daemon process
>>> should have a subject instance as well.
>>>
>>> That is why the security world uses the term 'Subject' instead of 'User',
>>> since 'User' generally implies a human being. 'Subject' is general in that
>>> it encompasses any state/identity information, be it a human or daemon
>>> process or whatever...
>>>
>>> On Mon, Dec 22, 2008 at 8:46 AM, Tamás Cservenák <ta...@cservenak.net>wrote:
>>>
>>>> Hi there,
>>>> not directly related, but I have a question: all these solutions assume
>>>> you already have a Subject.
>>>>
>>>> What about cases when it is not the case? (ie. scheduled tasks?)
>>>>
>>>> ~t~
>>>>
>>>>
>>>> On Thu, Dec 18, 2008 at 5:28 PM, Les Hazlewood <lh...@apache.org>wrote:
>>>>
>>>>> Hi JSecurity community,
>>>>>
>>>>> The JSecurity team will enable native support for the ability to assume
>>>>> another user's identity at runtime, aka 'Run As' or 'Switch User'
>>>>> functionality into the framework very soon. This allows the application to
>>>>> look, feel and react as if the current user is another user entirely, a
>>>>> functionality that is quite common in many applications.
>>>>>
>>>>> We're looking to the community to get feedback on what people prefer
>>>>> this be called in the API itself. Odds are very high that the methods to
>>>>> perform this switching capability will reside in the Subject interface (or a
>>>>> sub-interface of Subject, we haven't decided yet).
>>>>>
>>>>> So, here are a few alphabetically-ordered options that seem to make
>>>>> sense (don't forget a 'principal' is just an identifying attribute, like a
>>>>> username or user id). If you feel so inclined, please choose one:
>>>>>
>>>>> subject.assumeIdentity( Object principal );
>>>>> subject.runAs( Object principal );
>>>>> subject.switchUser( Object principal );
>>>>>
>>>>> Please note that whatever the naming choice, the implementation will
>>>>> retain raw traceability and auditing attributed to the original or 'owning'
>>>>> user in all cases. You won't 'lose' that when executing this
>>>>> soon-to-be-created method.
>>>>>
>>>>> Thanks for any feedback!
>>>>>
>>>>> Les
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Thanks,
>>>> ~t~
>>>>
>>>
>>>
>>>
>>
>
>
> --
> Thanks,
> ~t~
>
Re: Assumed Identity/Run As - we want your feedback!
Posted by Jeremy Haile <jh...@fastmail.fm>.
Well I think the biggest convenience we could offer would be able to
offer some way to tell JSecurity that the current session/context
should be running as a particular user without having to do an actual
"login." For example, I may want the scheduled process to run as a
user, but not want that user to be allowed to authenticate via my
usual Realm. Sure I could use a special AuthenticationToken and
custom realm logic to do this - but that's annoying.
It'd be simpler if it went something like this:
public void myScheduledTask() {
Subject subject = securityManager.assumeIdentity( myTaskPrincipal );
// Do my task
subject.logout();
}
or:
public void myScheduledTask() {
Subject subject = securityManager.getSubject();
subject.assumeIdentity( myTaskPrincipal );
// Do my task
subject.logout();
}
On Dec 23, 2008, at 12:35 PM, Les Hazlewood wrote:
> Oooh. This gets the old thought-crank turning.
>
> I'm thinking about how to do this cleanly - maybe something like a
> DetachedSubject or some similar concept that retains the subject
> identity but disables Session or login/logout functionality. This
> could then be handed off or 'bound' in some way to the intermittent
> process. Subject.detatch() : DetachedSubject. Who knows - I'm just
> brainstorming...
>
> I'll keep thinking. If anyone else has ideas, please speak up :)
>
> On Tue, Dec 23, 2008 at 11:46 AM, Tamás Cservenák
> <ta...@cservenak.net> wrote:
> Hi there,
>
> yes, Jeremy is right. I would be interested in running without a
> filter and without a session (scheduled task for example).
>
> Second, think about running a background scheduled task in some
> user's space, ie. the "creator" of that task for example (so, no
> filter, no session, but I want a given User's principal :)
>
> Is persisting/having the password really needed?
>
> Do not misunderstand me, I'm not whining, just throwing into the
> basket ideas :)
>
>
> ~t~
>
>
> On Mon, Dec 22, 2008 at 5:36 PM, Les Hazlewood
> <lh...@apache.org> wrote:
> At the moment, you can't call subject.assumeIdentity (or runAs,
> whatever) unless you have logged in already (this is another reason
> why I think assumeIdentity is less misleading than runAs - runAs
> gives no indication that you must already be logged in, whereas when
> you 'assume' an identity, it usually means you already have one to
> start with - anyway, moving on...).
>
> Again, currently in our implementation, the subject.* calls are
> proxies to the securityManager. The first argument is the subject's
> principals, the second argument is the additional arguments. This
> is important because our securityManager implementation would do a
> permission check (if isPermitted("assumeIdentity") ) before allowing
> the 'assumeIdentity/runAs' call to execute. You need an identity
> against which to perform the permission check.
>
> If you didn't have an identity, as your first example suggests (and
> we didn't check a permission) then you're essentially providing a
> subject with an identity _without_ verifying it. This would provide
> a 'hacky' ability to act as any user without verification -
> something I wouldn't be really comfortable introducing into
> JSecurity, at least at first glance.
>
> Instead, the developer should probably do the following:
>
> //in the thread executing work:
> Subject daemon = securityManager.getSubject();
> daemon.login(new UsernamePasswordToken(daemonUsername,
> daemonPassword) );
> //do work...
> daemon.logout();
>
> if the daemonPassword is null, that's up to the realm implementor,
> as they have knowledge if this is allowed in their application or
> not for that username - not something JSecurity has to worry about.
>
> Also, the 'logout' call would really only need to be executed upon
> system shutdown or when the process terminates - no need to do it on
> each invocation of the work getting run. And also, if the subject
> represents a system/daemon user, a developer could ensure that
> subject's session won't time out:
>
> //after login
> subject.getSession().setTimeout(-1);
>
> Something that is often useful for daemon/system processes.
>
> At least that's my $0.02
>
> Les
>
>
> On Mon, Dec 22, 2008 at 10:50 AM, Jeremy Haile <jh...@fastmail.fm>
> wrote:
> I think Tamas' point is that since a scheduled job doesn't run
> behind the JSecurityFilter and isn't associated with a session, it
> may not have a Subject based on the current session. The "run as"
> feature could be useful to establish a Subject by which the job
> should run under.
>
> For example:
> public void myScheduledTask() {
> Subject subject = securityManager.runAs( myTaskPrincipal );
> // Do my task
> subject.logout();
> }
>
> However, by putting these methods on the subject itself - it's not
> as clear, since there may not be any contextual (or thread local)
> subject associated with the scheduled task thread.
>
> Of course, you could currently do this:
> public void myScheduledTask() {
> Subject subject = securityManager.getSubject();
> subject.runAs( myTaskPrincipal );
> // Do my task
> subject.logout();
> }
>
> Any thoughts on which approach is clearer? The first approach could
> just be a shorthand way to do the second approach...
>
> Jeremy
>
>
>
> On Dec 22, 2008, at 10:35 AM, Les Hazlewood wrote:
>
>> Hi Tamás,
>>
>> There should _always_ be a Subject. A scheduled task or daemon
>> process should have a subject instance as well.
>>
>> That is why the security world uses the term 'Subject' instead of
>> 'User', since 'User' generally implies a human being. 'Subject' is
>> general in that it encompasses any state/identity information, be
>> it a human or daemon process or whatever...
>>
>> On Mon, Dec 22, 2008 at 8:46 AM, Tamás Cservenák
>> <ta...@cservenak.net> wrote:
>> Hi there,
>>
>> not directly related, but I have a question: all these solutions
>> assume you already have a Subject.
>>
>> What about cases when it is not the case? (ie. scheduled tasks?)
>>
>> ~t~
>>
>>
>> On Thu, Dec 18, 2008 at 5:28 PM, Les Hazlewood
>> <lh...@apache.org> wrote:
>> Hi JSecurity community,
>>
>> The JSecurity team will enable native support for the ability to
>> assume another user's identity at runtime, aka 'Run As' or 'Switch
>> User' functionality into the framework very soon. This allows the
>> application to look, feel and react as if the current user is
>> another user entirely, a functionality that is quite common in many
>> applications.
>>
>> We're looking to the community to get feedback on what people
>> prefer this be called in the API itself. Odds are very high that
>> the methods to perform this switching capability will reside in the
>> Subject interface (or a sub-interface of Subject, we haven't
>> decided yet).
>>
>> So, here are a few alphabetically-ordered options that seem to make
>> sense (don't forget a 'principal' is just an identifying attribute,
>> like a username or user id). If you feel so inclined, please
>> choose one:
>>
>> subject.assumeIdentity( Object principal );
>> subject.runAs( Object principal );
>> subject.switchUser( Object principal );
>>
>> Please note that whatever the naming choice, the implementation
>> will retain raw traceability and auditing attributed to the
>> original or 'owning' user in all cases. You won't 'lose' that when
>> executing this soon-to-be-created method.
>>
>> Thanks for any feedback!
>>
>> Les
>>
>>
>>
>> --
>> Thanks,
>> ~t~
>>
>
>
>
>
>
> --
> Thanks,
> ~t~
>
Re: Assumed Identity/Run As - we want your feedback!
Posted by Les Hazlewood <lh...@apache.org>.
Oooh. This gets the old thought-crank turning.
I'm thinking about how to do this cleanly - maybe something like a
DetachedSubject or some similar concept that retains the subject identity
but disables Session or login/logout functionality. This could then be
handed off or 'bound' in some way to the intermittent process.
Subject.detatch() : DetachedSubject. Who knows - I'm just brainstorming...
I'll keep thinking. If anyone else has ideas, please speak up :)
On Tue, Dec 23, 2008 at 11:46 AM, Tamás Cservenák <ta...@cservenak.net>wrote:
> Hi there,
> yes, Jeremy is right. I would be interested in running without a filter and
> without a session (scheduled task for example).
>
> Second, think about running a background scheduled task in some user's
> space, ie. the "creator" of that task for example (so, no filter, no
> session, but I want a given User's principal :)
>
> Is persisting/having the password really needed?
>
> Do not misunderstand me, I'm not whining, just throwing into the basket
> ideas :)
>
>
> ~t~
>
>
> On Mon, Dec 22, 2008 at 5:36 PM, Les Hazlewood <lh...@apache.org>wrote:
>
>> At the moment, you can't call subject.assumeIdentity (or runAs, whatever)
>> unless you have logged in already (this is another reason why I think
>> assumeIdentity is less misleading than runAs - runAs gives no indication
>> that you must already be logged in, whereas when you 'assume' an identity,
>> it usually means you already have one to start with - anyway, moving on...).
>>
>> Again, currently in our implementation, the subject.* calls are proxies to
>> the securityManager. The first argument is the subject's principals, the
>> second argument is the additional arguments. This is important because our
>> securityManager implementation would do a permission check (if
>> isPermitted("assumeIdentity") ) before allowing the 'assumeIdentity/runAs'
>> call to execute. You need an identity against which to perform the
>> permission check.
>>
>> If you didn't have an identity, as your first example suggests (and we
>> didn't check a permission) then you're essentially providing a subject with
>> an identity _without_ verifying it. This would provide a 'hacky' ability to
>> act as any user without verification - something I wouldn't be really
>> comfortable introducing into JSecurity, at least at first glance.
>>
>> Instead, the developer should probably do the following:
>>
>> //in the thread executing work:
>> Subject daemon = securityManager.getSubject();
>> daemon.login(new UsernamePasswordToken(daemonUsername, daemonPassword) );
>> //do work...
>> daemon.logout();
>>
>> if the daemonPassword is null, that's up to the realm implementor, as they
>> have knowledge if this is allowed in their application or not for that
>> username - not something JSecurity has to worry about.
>>
>> Also, the 'logout' call would really only need to be executed upon system
>> shutdown or when the process terminates - no need to do it on each
>> invocation of the work getting run. And also, if the subject represents a
>> system/daemon user, a developer could ensure that subject's session won't
>> time out:
>>
>> //after login
>> subject.getSession().setTimeout(-1);
>>
>> Something that is often useful for daemon/system processes.
>>
>> At least that's my $0.02
>>
>> Les
>>
>>
>> On Mon, Dec 22, 2008 at 10:50 AM, Jeremy Haile <jh...@fastmail.fm>wrote:
>>
>>> I think Tamas' point is that since a scheduled job doesn't run behind the
>>> JSecurityFilter and isn't associated with a session, it may not have a
>>> Subject based on the current session. The "run as" feature could be useful
>>> to establish a Subject by which the job should run under.
>>> For example:
>>> public void myScheduledTask() {
>>> Subject subject = securityManager.runAs( myTaskPrincipal );
>>> // Do my task
>>> subject.logout();
>>> }
>>>
>>> However, by putting these methods on the subject itself - it's not as
>>> clear, since there may not be any contextual (or thread local) subject
>>> associated with the scheduled task thread.
>>>
>>> Of course, you could currently do this:
>>> public void myScheduledTask() {
>>> Subject subject = securityManager.getSubject();
>>> subject.runAs( myTaskPrincipal );
>>> // Do my task
>>> subject.logout();
>>> }
>>>
>>> Any thoughts on which approach is clearer? The first approach could just
>>> be a shorthand way to do the second approach...
>>>
>>> Jeremy
>>>
>>>
>>>
>>> On Dec 22, 2008, at 10:35 AM, Les Hazlewood wrote:
>>>
>>> Hi Tamás,
>>>
>>> There should _always_ be a Subject. A scheduled task or daemon process
>>> should have a subject instance as well.
>>>
>>> That is why the security world uses the term 'Subject' instead of 'User',
>>> since 'User' generally implies a human being. 'Subject' is general in that
>>> it encompasses any state/identity information, be it a human or daemon
>>> process or whatever...
>>>
>>> On Mon, Dec 22, 2008 at 8:46 AM, Tamás Cservenák <ta...@cservenak.net>wrote:
>>>
>>>> Hi there,
>>>> not directly related, but I have a question: all these solutions assume
>>>> you already have a Subject.
>>>>
>>>> What about cases when it is not the case? (ie. scheduled tasks?)
>>>>
>>>> ~t~
>>>>
>>>>
>>>> On Thu, Dec 18, 2008 at 5:28 PM, Les Hazlewood <lh...@apache.org>wrote:
>>>>
>>>>> Hi JSecurity community,
>>>>>
>>>>> The JSecurity team will enable native support for the ability to assume
>>>>> another user's identity at runtime, aka 'Run As' or 'Switch User'
>>>>> functionality into the framework very soon. This allows the application to
>>>>> look, feel and react as if the current user is another user entirely, a
>>>>> functionality that is quite common in many applications.
>>>>>
>>>>> We're looking to the community to get feedback on what people prefer
>>>>> this be called in the API itself. Odds are very high that the methods to
>>>>> perform this switching capability will reside in the Subject interface (or a
>>>>> sub-interface of Subject, we haven't decided yet).
>>>>>
>>>>> So, here are a few alphabetically-ordered options that seem to make
>>>>> sense (don't forget a 'principal' is just an identifying attribute, like a
>>>>> username or user id). If you feel so inclined, please choose one:
>>>>>
>>>>> subject.assumeIdentity( Object principal );
>>>>> subject.runAs( Object principal );
>>>>> subject.switchUser( Object principal );
>>>>>
>>>>> Please note that whatever the naming choice, the implementation will
>>>>> retain raw traceability and auditing attributed to the original or 'owning'
>>>>> user in all cases. You won't 'lose' that when executing this
>>>>> soon-to-be-created method.
>>>>>
>>>>> Thanks for any feedback!
>>>>>
>>>>> Les
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Thanks,
>>>> ~t~
>>>>
>>>
>>>
>>>
>>
>
>
> --
> Thanks,
> ~t~
>
Re: Assumed Identity/Run As - we want your feedback!
Posted by Tamás Cservenák <ta...@cservenak.net>.
Hi there,
yes, Jeremy is right. I would be interested in running without a filter and
without a session (scheduled task for example).
Second, think about running a background scheduled task in some user's
space, ie. the "creator" of that task for example (so, no filter, no
session, but I want a given User's principal :)
Is persisting/having the password really needed?
Do not misunderstand me, I'm not whining, just throwing into the basket
ideas :)
~t~
On Mon, Dec 22, 2008 at 5:36 PM, Les Hazlewood <lh...@apache.org>wrote:
> At the moment, you can't call subject.assumeIdentity (or runAs, whatever)
> unless you have logged in already (this is another reason why I think
> assumeIdentity is less misleading than runAs - runAs gives no indication
> that you must already be logged in, whereas when you 'assume' an identity,
> it usually means you already have one to start with - anyway, moving on...).
>
> Again, currently in our implementation, the subject.* calls are proxies to
> the securityManager. The first argument is the subject's principals, the
> second argument is the additional arguments. This is important because our
> securityManager implementation would do a permission check (if
> isPermitted("assumeIdentity") ) before allowing the 'assumeIdentity/runAs'
> call to execute. You need an identity against which to perform the
> permission check.
>
> If you didn't have an identity, as your first example suggests (and we
> didn't check a permission) then you're essentially providing a subject with
> an identity _without_ verifying it. This would provide a 'hacky' ability to
> act as any user without verification - something I wouldn't be really
> comfortable introducing into JSecurity, at least at first glance.
>
> Instead, the developer should probably do the following:
>
> //in the thread executing work:
> Subject daemon = securityManager.getSubject();
> daemon.login(new UsernamePasswordToken(daemonUsername, daemonPassword) );
> //do work...
> daemon.logout();
>
> if the daemonPassword is null, that's up to the realm implementor, as they
> have knowledge if this is allowed in their application or not for that
> username - not something JSecurity has to worry about.
>
> Also, the 'logout' call would really only need to be executed upon system
> shutdown or when the process terminates - no need to do it on each
> invocation of the work getting run. And also, if the subject represents a
> system/daemon user, a developer could ensure that subject's session won't
> time out:
>
> //after login
> subject.getSession().setTimeout(-1);
>
> Something that is often useful for daemon/system processes.
>
> At least that's my $0.02
>
> Les
>
>
> On Mon, Dec 22, 2008 at 10:50 AM, Jeremy Haile <jh...@fastmail.fm> wrote:
>
>> I think Tamas' point is that since a scheduled job doesn't run behind the
>> JSecurityFilter and isn't associated with a session, it may not have a
>> Subject based on the current session. The "run as" feature could be useful
>> to establish a Subject by which the job should run under.
>> For example:
>> public void myScheduledTask() {
>> Subject subject = securityManager.runAs( myTaskPrincipal );
>> // Do my task
>> subject.logout();
>> }
>>
>> However, by putting these methods on the subject itself - it's not as
>> clear, since there may not be any contextual (or thread local) subject
>> associated with the scheduled task thread.
>>
>> Of course, you could currently do this:
>> public void myScheduledTask() {
>> Subject subject = securityManager.getSubject();
>> subject.runAs( myTaskPrincipal );
>> // Do my task
>> subject.logout();
>> }
>>
>> Any thoughts on which approach is clearer? The first approach could just
>> be a shorthand way to do the second approach...
>>
>> Jeremy
>>
>>
>>
>> On Dec 22, 2008, at 10:35 AM, Les Hazlewood wrote:
>>
>> Hi Tamás,
>>
>> There should _always_ be a Subject. A scheduled task or daemon process
>> should have a subject instance as well.
>>
>> That is why the security world uses the term 'Subject' instead of 'User',
>> since 'User' generally implies a human being. 'Subject' is general in that
>> it encompasses any state/identity information, be it a human or daemon
>> process or whatever...
>>
>> On Mon, Dec 22, 2008 at 8:46 AM, Tamás Cservenák <ta...@cservenak.net>wrote:
>>
>>> Hi there,
>>> not directly related, but I have a question: all these solutions assume
>>> you already have a Subject.
>>>
>>> What about cases when it is not the case? (ie. scheduled tasks?)
>>>
>>> ~t~
>>>
>>>
>>> On Thu, Dec 18, 2008 at 5:28 PM, Les Hazlewood <lh...@apache.org>wrote:
>>>
>>>> Hi JSecurity community,
>>>>
>>>> The JSecurity team will enable native support for the ability to assume
>>>> another user's identity at runtime, aka 'Run As' or 'Switch User'
>>>> functionality into the framework very soon. This allows the application to
>>>> look, feel and react as if the current user is another user entirely, a
>>>> functionality that is quite common in many applications.
>>>>
>>>> We're looking to the community to get feedback on what people prefer
>>>> this be called in the API itself. Odds are very high that the methods to
>>>> perform this switching capability will reside in the Subject interface (or a
>>>> sub-interface of Subject, we haven't decided yet).
>>>>
>>>> So, here are a few alphabetically-ordered options that seem to make
>>>> sense (don't forget a 'principal' is just an identifying attribute, like a
>>>> username or user id). If you feel so inclined, please choose one:
>>>>
>>>> subject.assumeIdentity( Object principal );
>>>> subject.runAs( Object principal );
>>>> subject.switchUser( Object principal );
>>>>
>>>> Please note that whatever the naming choice, the implementation will
>>>> retain raw traceability and auditing attributed to the original or 'owning'
>>>> user in all cases. You won't 'lose' that when executing this
>>>> soon-to-be-created method.
>>>>
>>>> Thanks for any feedback!
>>>>
>>>> Les
>>>>
>>>
>>>
>>>
>>> --
>>> Thanks,
>>> ~t~
>>>
>>
>>
>>
>
--
Thanks,
~t~
Re: Assumed Identity/Run As - we want your feedback!
Posted by Les Hazlewood <lh...@apache.org>.
At the moment, you can't call subject.assumeIdentity (or runAs, whatever)
unless you have logged in already (this is another reason why I think
assumeIdentity is less misleading than runAs - runAs gives no indication
that you must already be logged in, whereas when you 'assume' an identity,
it usually means you already have one to start with - anyway, moving on...).
Again, currently in our implementation, the subject.* calls are proxies to
the securityManager. The first argument is the subject's principals, the
second argument is the additional arguments. This is important because our
securityManager implementation would do a permission check (if
isPermitted("assumeIdentity") ) before allowing the 'assumeIdentity/runAs'
call to execute. You need an identity against which to perform the
permission check.
If you didn't have an identity, as your first example suggests (and we
didn't check a permission) then you're essentially providing a subject with
an identity _without_ verifying it. This would provide a 'hacky' ability to
act as any user without verification - something I wouldn't be really
comfortable introducing into JSecurity, at least at first glance.
Instead, the developer should probably do the following:
//in the thread executing work:
Subject daemon = securityManager.getSubject();
daemon.login(new UsernamePasswordToken(daemonUsername, daemonPassword) );
//do work...
daemon.logout();
if the daemonPassword is null, that's up to the realm implementor, as they
have knowledge if this is allowed in their application or not for that
username - not something JSecurity has to worry about.
Also, the 'logout' call would really only need to be executed upon system
shutdown or when the process terminates - no need to do it on each
invocation of the work getting run. And also, if the subject represents a
system/daemon user, a developer could ensure that subject's session won't
time out:
//after login
subject.getSession().setTimeout(-1);
Something that is often useful for daemon/system processes.
At least that's my $0.02
Les
On Mon, Dec 22, 2008 at 10:50 AM, Jeremy Haile <jh...@fastmail.fm> wrote:
> I think Tamas' point is that since a scheduled job doesn't run behind the
> JSecurityFilter and isn't associated with a session, it may not have a
> Subject based on the current session. The "run as" feature could be useful
> to establish a Subject by which the job should run under.
> For example:
> public void myScheduledTask() {
> Subject subject = securityManager.runAs( myTaskPrincipal );
> // Do my task
> subject.logout();
> }
>
> However, by putting these methods on the subject itself - it's not as
> clear, since there may not be any contextual (or thread local) subject
> associated with the scheduled task thread.
>
> Of course, you could currently do this:
> public void myScheduledTask() {
> Subject subject = securityManager.getSubject();
> subject.runAs( myTaskPrincipal );
> // Do my task
> subject.logout();
> }
>
> Any thoughts on which approach is clearer? The first approach could just
> be a shorthand way to do the second approach...
>
> Jeremy
>
>
>
> On Dec 22, 2008, at 10:35 AM, Les Hazlewood wrote:
>
> Hi Tamás,
>
> There should _always_ be a Subject. A scheduled task or daemon process
> should have a subject instance as well.
>
> That is why the security world uses the term 'Subject' instead of 'User',
> since 'User' generally implies a human being. 'Subject' is general in that
> it encompasses any state/identity information, be it a human or daemon
> process or whatever...
>
> On Mon, Dec 22, 2008 at 8:46 AM, Tamás Cservenák <ta...@cservenak.net>wrote:
>
>> Hi there,
>> not directly related, but I have a question: all these solutions assume
>> you already have a Subject.
>>
>> What about cases when it is not the case? (ie. scheduled tasks?)
>>
>> ~t~
>>
>>
>> On Thu, Dec 18, 2008 at 5:28 PM, Les Hazlewood <lh...@apache.org>wrote:
>>
>>> Hi JSecurity community,
>>>
>>> The JSecurity team will enable native support for the ability to assume
>>> another user's identity at runtime, aka 'Run As' or 'Switch User'
>>> functionality into the framework very soon. This allows the application to
>>> look, feel and react as if the current user is another user entirely, a
>>> functionality that is quite common in many applications.
>>>
>>> We're looking to the community to get feedback on what people prefer this
>>> be called in the API itself. Odds are very high that the methods to perform
>>> this switching capability will reside in the Subject interface (or a
>>> sub-interface of Subject, we haven't decided yet).
>>>
>>> So, here are a few alphabetically-ordered options that seem to make sense
>>> (don't forget a 'principal' is just an identifying attribute, like a
>>> username or user id). If you feel so inclined, please choose one:
>>>
>>> subject.assumeIdentity( Object principal );
>>> subject.runAs( Object principal );
>>> subject.switchUser( Object principal );
>>>
>>> Please note that whatever the naming choice, the implementation will
>>> retain raw traceability and auditing attributed to the original or 'owning'
>>> user in all cases. You won't 'lose' that when executing this
>>> soon-to-be-created method.
>>>
>>> Thanks for any feedback!
>>>
>>> Les
>>>
>>
>>
>>
>> --
>> Thanks,
>> ~t~
>>
>
>
>
Re: Assumed Identity/Run As - we want your feedback!
Posted by Jeremy Haile <jh...@fastmail.fm>.
I think Tamas' point is that since a scheduled job doesn't run behind
the JSecurityFilter and isn't associated with a session, it may not
have a Subject based on the current session. The "run as" feature
could be useful to establish a Subject by which the job should run
under.
For example:
public void myScheduledTask() {
Subject subject = securityManager.runAs( myTaskPrincipal );
// Do my task
subject.logout();
}
However, by putting these methods on the subject itself - it's not as
clear, since there may not be any contextual (or thread local) subject
associated with the scheduled task thread.
Of course, you could currently do this:
public void myScheduledTask() {
Subject subject = securityManager.getSubject();
subject.runAs( myTaskPrincipal );
// Do my task
subject.logout();
}
Any thoughts on which approach is clearer? The first approach could
just be a shorthand way to do the second approach...
Jeremy
On Dec 22, 2008, at 10:35 AM, Les Hazlewood wrote:
> Hi Tamás,
>
> There should _always_ be a Subject. A scheduled task or daemon
> process should have a subject instance as well.
>
> That is why the security world uses the term 'Subject' instead of
> 'User', since 'User' generally implies a human being. 'Subject' is
> general in that it encompasses any state/identity information, be it
> a human or daemon process or whatever...
>
> On Mon, Dec 22, 2008 at 8:46 AM, Tamás Cservenák
> <ta...@cservenak.net> wrote:
> Hi there,
>
> not directly related, but I have a question: all these solutions
> assume you already have a Subject.
>
> What about cases when it is not the case? (ie. scheduled tasks?)
>
> ~t~
>
>
> On Thu, Dec 18, 2008 at 5:28 PM, Les Hazlewood
> <lh...@apache.org> wrote:
> Hi JSecurity community,
>
> The JSecurity team will enable native support for the ability to
> assume another user's identity at runtime, aka 'Run As' or 'Switch
> User' functionality into the framework very soon. This allows the
> application to look, feel and react as if the current user is
> another user entirely, a functionality that is quite common in many
> applications.
>
> We're looking to the community to get feedback on what people prefer
> this be called in the API itself. Odds are very high that the
> methods to perform this switching capability will reside in the
> Subject interface (or a sub-interface of Subject, we haven't decided
> yet).
>
> So, here are a few alphabetically-ordered options that seem to make
> sense (don't forget a 'principal' is just an identifying attribute,
> like a username or user id). If you feel so inclined, please choose
> one:
>
> subject.assumeIdentity( Object principal );
> subject.runAs( Object principal );
> subject.switchUser( Object principal );
>
> Please note that whatever the naming choice, the implementation will
> retain raw traceability and auditing attributed to the original or
> 'owning' user in all cases. You won't 'lose' that when executing
> this soon-to-be-created method.
>
> Thanks for any feedback!
>
> Les
>
>
>
> --
> Thanks,
> ~t~
>
Re: Assumed Identity/Run As - we want your feedback!
Posted by Les Hazlewood <lh...@apache.org>.
Hi Tamás,
There should _always_ be a Subject. A scheduled task or daemon process
should have a subject instance as well.
That is why the security world uses the term 'Subject' instead of 'User',
since 'User' generally implies a human being. 'Subject' is general in that
it encompasses any state/identity information, be it a human or daemon
process or whatever...
On Mon, Dec 22, 2008 at 8:46 AM, Tamás Cservenák <ta...@cservenak.net>wrote:
> Hi there,
> not directly related, but I have a question: all these solutions assume you
> already have a Subject.
>
> What about cases when it is not the case? (ie. scheduled tasks?)
>
> ~t~
>
>
> On Thu, Dec 18, 2008 at 5:28 PM, Les Hazlewood <lh...@apache.org>wrote:
>
>> Hi JSecurity community,
>>
>> The JSecurity team will enable native support for the ability to assume
>> another user's identity at runtime, aka 'Run As' or 'Switch User'
>> functionality into the framework very soon. This allows the application to
>> look, feel and react as if the current user is another user entirely, a
>> functionality that is quite common in many applications.
>>
>> We're looking to the community to get feedback on what people prefer this
>> be called in the API itself. Odds are very high that the methods to perform
>> this switching capability will reside in the Subject interface (or a
>> sub-interface of Subject, we haven't decided yet).
>>
>> So, here are a few alphabetically-ordered options that seem to make sense
>> (don't forget a 'principal' is just an identifying attribute, like a
>> username or user id). If you feel so inclined, please choose one:
>>
>> subject.assumeIdentity( Object principal );
>> subject.runAs( Object principal );
>> subject.switchUser( Object principal );
>>
>> Please note that whatever the naming choice, the implementation will
>> retain raw traceability and auditing attributed to the original or 'owning'
>> user in all cases. You won't 'lose' that when executing this
>> soon-to-be-created method.
>>
>> Thanks for any feedback!
>>
>> Les
>>
>
>
>
> --
> Thanks,
> ~t~
>
Re: Assumed Identity/Run As - we want your feedback!
Posted by Tamás Cservenák <ta...@cservenak.net>.
Hi there,
not directly related, but I have a question: all these solutions assume you
already have a Subject.
What about cases when it is not the case? (ie. scheduled tasks?)
~t~
On Thu, Dec 18, 2008 at 5:28 PM, Les Hazlewood <lh...@apache.org>wrote:
> Hi JSecurity community,
>
> The JSecurity team will enable native support for the ability to assume
> another user's identity at runtime, aka 'Run As' or 'Switch User'
> functionality into the framework very soon. This allows the application to
> look, feel and react as if the current user is another user entirely, a
> functionality that is quite common in many applications.
>
> We're looking to the community to get feedback on what people prefer this
> be called in the API itself. Odds are very high that the methods to perform
> this switching capability will reside in the Subject interface (or a
> sub-interface of Subject, we haven't decided yet).
>
> So, here are a few alphabetically-ordered options that seem to make sense
> (don't forget a 'principal' is just an identifying attribute, like a
> username or user id). If you feel so inclined, please choose one:
>
> subject.assumeIdentity( Object principal );
> subject.runAs( Object principal );
> subject.switchUser( Object principal );
>
> Please note that whatever the naming choice, the implementation will retain
> raw traceability and auditing attributed to the original or 'owning' user in
> all cases. You won't 'lose' that when executing this soon-to-be-created
> method.
>
> Thanks for any feedback!
>
> Les
>
--
Thanks,
~t~