[2.0] Shiro integration

[Will Sargent]

Hi all,

I tried my hand last night at a Shiro integration with the Play 2.0 code.  I'm giving up on it for now after realizing that it's going to be more than a couple of hours hack, but figured it was worth writing up.

The attraction behind Shiro was fine grained authentication (i.e. "remember me" cookies) and role based authentication (admin rights, "is member of group", etc.)

So as I understand the Play framework, it starts with NettyServer.messageReceived, goes through the Invoker, and then if it's a HandleAction, the Invoker passes the action through and it gets routed to the controller.

There is no direct access to Netty's HttpRequest or HttpResponse objects, and HttpSession is also right.  This means that a straight integration to shiro-web is out.

Initially I thought about creating a Play module just modelled on shiro-web, but there's a more subtle problem involved.  Shiro-web and even shiro-core is based around the idea of mutable objects, and Play sessions and cookies are built around the concept of immutable state that is aggregated and encoded as a cookie during the result using withCookies.  Also, I couldn't find any way of filtering shiro integration through a chain, like a Rails before_filter.

This is where I'd mapped things out to (it's worth checking out shiro-core and shiro-web for reference)

http://grepcode.com/file/repo1.maven.org/maven2/org.apache.shiro/shiro-web/1.1.0/org/apache/shiro/web/session/mgt/DefaultWebSessionManager.java?av=f

PlaySecurityManager:

  Creates session manager.

  Creates session context from the subject context.

  Creates / gets session keys using the subject context.

  Creates subjects (using the subject factory)

PlaySubjectContext: 

  Contains all the info needed for creating a subject.  In WebSubjectContext this had links to the servlet request / response.

  Should have a session id associated with it (it gets passed on to the session context), but I couldn't see where that was set.

PlaySubjectFactory: 

  This creates subjects using the subject context.  Subjects are the user / principal that are tested to see if they have the right security privileges.

PlaySession:

  This is the shiro session that is used to carry session information.  It's not the same as the Play session object, as I was worried about the immutability constraints,

  but it is / should be cookie backed.  (If you look at shiro-web, the closest analogy would be SimpleCookie).

  It looks like the session doesn't start off with an id, and that has to be assigned directly from somewhere.  (HttpServletSession cheats by using httpSession.getId())

PlaySessionContext:

   A session context should have a session id, and allows sessions to be retrieved from a store.  In DefaultWebSessionManager, this carries a request/response pair.

   This is used by the factory for creating new sessions.

PlaySessionManager: 

  Modelled on DefaultWebSessionManager.  

  It creates new PlaySessionKey objects or pulls them from a cookie and also removes cookies when session is over.  

  Creates sessions using the session factory, through the DefaultSessionManager super class.  There's an internal sessionDAO that stores all of the active sessions.

PlaySessionKey:

   Created from the SecurityManager, using the sessionContext.  This is the session id as a serializable, and is a pure ID -- it's used for lookup and saving to cookies.

It all looks doable in theory; Play has cookies and can look up cookies, and as far as I know you're using the same thread for the duration of the Action, so SecurityUtils.getSubject() should work fine... but it's a solid project and there doesn't seem to be a quick and easy way to get the two to mesh.

Will.