As an addendum Thomas, the code I gave above _does_ work today - quite well in fact for daemon processes or intermittent logic run on behalf of a user.
A session wouldn't be created either if you didn't call Subject.getSession() - that would be up to code that uses the Subject instance. In other words, don't let the Filter concept be a mental block. JSecurity works just fine outside web environments, where no Filter exists. In these environments, the SecurityManager acquires the subject identity not from an incoming request, but through some other mechanism - either a remoting proxy or some other location well known to the application - a cache, a database, etc. Sure, how this happens is specific to the environment, just as the Filter mechanism is specific to web environments. I think what you're looking for would be better-documented support for using JSecurity outside of web environments, maybe not so much on the specifics of how a Subject works (or maybe so, I'm just speculating). Cheers, Les 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~ >
