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~
