Hello
 We have happily been using Shiro for some years now for our Spring MVC web
application authentication and authorisation using standard Shiro filters to
login and logout users.
Recently we implemented an asynchronous 'export' feature where a request
launches a background thread to perform a possibly long running ( a few
minutes) task. The request returns a job ID that the client app can use to
interrogate progress.  We bind the Subject to the Callable using <code>task
= subject.associateWith(task);</code> and it all works fine, as in the web
application the user generally remains logged in while the export is
happening.

We now expose this export feature through an API. Here is where we get a
problem, maybe we are not using Shiro correctly here.
 - We have implemented a Realm that checks for access token validity
 - we have set noSessionCreation to be active as the API requests are
supposed to be stateless 
- if all ok we call SecurityUtils.getSubject().login so that there is an
authenticated principal to do permissions checks on access to resources that
are going to be exported.
- When the API call is finished, in a filter we call 
SecurityUtils.getSubject().logout() before returning the response. This has
the effect of setting the principalsCollection to null, so all subsequent
permission lookups fail for the Subject. This means that permission lookups
performed by the background thread now fail.

Does anyone have any suggestions for how to keep a subject usable in a
background thread after logout() has been called? There seem to be several
options:

- not call logout() at the end of each API request. Would this be bad
practice? Would there be some accumulation of Subject or Http Session
instances over time and 000s of API requests?
- stop using Shiro for API permissions lookups - we would prefer to use the
same permissions mechanism for all clients, so this option is not attractive
- Use reflection to set the PrincipalCollection back into the Subject after
calling logout - this seems a bit hacky and potentially fragile

Any advice or examples of using Shiro to secure APIs would be greatly
appreciated, thanks Richard



--
Sent from: http://shiro-user.582556.n2.nabble.com/

Reply via email to