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~
