I just finished doing something similar. I'm using ehcache to cache the authenticated subjects. Then, I'm using a custom authentication filter to load the subject from the cache if a session token has been passed in the request headers. That way, the subject gets bound to the current thread local variable and from that point forward, I can just retrieve it with SecurityUtils.getSubject(). As this is the already authenticated subject that was cached, there is no need to muck with the session attributes. This approach seems to be working quite well for us.
All this said, I agree with Les in the end that it is far better to avoid state in your REST services, and as such, pass your user/password or API key along with each request rather than mucking with a separate authentication call. In my case, I didn't have a choice because we were replacing an existing custom authentication mechanism in an existing service that was already in use in our organization. As such, there was no way I could up and change the API without affecting our existing service consumers. If I were building a green-field API, would have done has Les suggested. I may clean up my filter and contribute it to Les to see if he would like to include it in a future version of Shiro. I believe I can provide a code fragment if desired, but it's pretty basic. Note, for this to work, if you're running in a cluster, you will need a clustered caching solution to make it work such as Terracotta. We just use the free community version. -- Sean Blaes Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Tuesday, 21 August 2012 at 19:20, ankur wrote: > Hi All , > > I have rest service for which i am trying to use shiro authentication > mechnism.Below is the scenario : > > Client gives username/password to rest service. Service uses shiro to > authenticate and return a session id in response. > > Client makes all future request using above session id. > When service gets a request , it gets the session id. It tries to create > a subject using > Subject s = new Subject.Builder().sessionId(sessionId).buildSubject(); > and check if(subject.isAuthenticated()) > > I was getting false for above check and my service request was failing > always. > > I tried to implement something which is mentioned here > "https://issues.apache.org/jira/browse/SHIRO-170"; but that did not help me. > I went through > "http://stackoverflow.com/questions/8501058/shiro-authentication-with-sessionid-or-usernamepassword"; > > > Then I tried something like : > When user logs in i create a session and set attribute > session.setAttribute(DefaultSubjectContext.AUTHENTICATED_SESSION_KEY,Boolean.TRUE); > > > and when user log out i set above key to false and do subject.logout();. > > I want to know what are side effect of setting > session.setAttribute(DefaultSubjectContext.AUTHENTICATED_SESSION_KEY,Boolean.TRUE) > explicitly? > > Please reply as this is very important for me. > > Also, please suggest me a better way for above implementation. > Regards > ankur > > > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/what-are-the-drawback-of-setting-DefaultSubjectContext-AUTHENTICATED-SESSION-KEY-in-session-explicit-tp7577719.html > Sent from the Shiro User mailing list archive at Nabble.com > (http://Nabble.com). > >
