shiro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Les Hazlewood" <lhazlew...@apache.org>
Subject Re: Assumed Identity/Run As - we want your feedback!
Date Tue, 23 Dec 2008 17:35:50 GMT
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 <tamas@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 <lhazlewood@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 <jhaile@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 <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>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~
>
Mime
View raw message