Les, I think it's great you are working on REST support. Is your work going to integrate with REST frameworks such as Jersey?
I haven't felt like I needed more from Shiro to support REST, but my usage isn't really REST. I'm currently using a REST-like API, but it isn't truly RESTful. A session is created and remember me cookies are used as well. My API is very user-centric, for instance going to "/events" would display a list of the currently logged-in user's events. However, part of the API is also non-user specific. For instance, "/user/5212" would get the details of user id 5212. I plan to eventually make this API fully RESTful and use OAuth for authentication. My only real comment is that you do not limit authentication to using basic auth only, and that OAuth or other techniques be able to be used. I'm sure you wouldn't do this, but I just wanted to state the obvious. Tauren On Mon, Apr 4, 2011 at 7:17 PM, Les Hazlewood <[email protected]> wrote: > Hi all, > > I've been working on Shiro's internals today to simplify support for > REST applications. My motivation is partially selfish, since I'm > using Shiro to protect REST endpoints at work, and I'll need to ensure > this all goes smoothly. > > Before I get too far involved, I was wondering if anyone had any > problems they've come across in the past and would like to share or > any ideas in general that they think would make REST security easier. > > I have 2 things on my list that I think are relatively obvious: > > 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. > > 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. > > Anything else? > > Any ideas? > > Thanks, > > -- > Les Hazlewood > Founder, Katasoft, Inc. > Application Security Products & Professional Apache Shiro Support and > Training: > http://www.katasoft.com >
