On Mon, Apr 4, 2011 at 8:04 PM, Erik Beeson <[email protected]> wrote: > Hi Les, > I'm very interested in REST as well. I'd be happy to contribute to this > effort where able. > (comments inline) > On Mon, Apr 4, 2011 at 7:17 PM, Les Hazlewood <[email protected]> wrote: >> >> ... >> 1. Support authentication caching (key: AuthenticationToken, value: >> AuthenticationInfo). Since REST calls usually use HTTP BASIC >> authentication and assume no server state, it would be ideal if we >> didn't have a roundtrip to the datastore(s) for each REST call. > > Yes, but I would encourage this to be optional (truly stateless).
It will be optional, but I can't think of a good reason to disable this except for very small apps. Without caching, you would 'hit' your backend authentication data store(s) for _every_ REST request that was serviced. 100% stateless architectures are, in practice, often impractical. Data locality is king for performance and why caching is used everywhere from large scale web apps to hard disks to individual CPUs. Of course, everyone's app is different, and this might be turned off with no ill-effect for small apps. But the larger the app and the larger the number of authentications per hour (or number of REST requests per hour), the more caching would be a real requirement. YMMV :) >> 2. Support custom authentication 'binding'. Currently when Shiro >> authenticates a subject it puts the resulting PrincipalCollection and >> authentication state in the Session to ensure it is available for the >> remainder of the Subject's interaction with the application during >> that session. Of course, with REST being stateless, it would be ideal >> to turn this off for any authentication that occurred during a REST >> call. > > What do you think this would look like? This seems like it is the part most > orthogonal to how Shiro works now. > Would it be possible to do a stateless session cookie approach? With at > least 4k of space in a cookie, maybe the existing Shiro session could be > serialized/deserialized to/from a cookie on each request? There's a > non-trivial cost involved of course, but it's a cost-space tradeoff, and it > would allow the existing Shiro session mechanism to port directly to RESTful > applications in a truly stateless way. I wouldn't want to do this - to have identity and authentication state in a cookie means that state could be tampered with before transit. It could potentially allow someone to impersonate another user or fake authentication - too risky with cookies IMO. I was thinking more of a SubjectBinder that would decide whether or not to attach identity and authentication state to the session after the request-initiated login. In a rest environment, a Rest filter (or authcBasic filter) would add a request attribute that indicates a stateless operation. The SubjectBinder can look at this request attribute, and if it exists, _not_ bind the subject state to the Session. For these requests, no session would ever be created, so the Subject state effectively vanishes at the end of every request. For all other requests, it would function as it currently does. Does that make sense? Do you guys see any holes with this approach? Cheers, -- Les Hazlewood Founder, Katasoft, Inc. Application Security Products & Professional Apache Shiro Support and Training: http://www.katasoft.com
