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 <[email protected]> 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 <[email protected]>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 <[email protected]>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~
>>
>
>
>
