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~ >
