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