Hi Tauren, Please see inline.
> There have been a few messages recently about Shiro and Jersey that prompted > me to resurrect this old related thread. > My application currently has some wicket pages for login, logout, account > creation, and a few other things. It also uses a rememberme cookie for > authentication. Just a quick note - rememberMe cookies do not perform authentication - they just remember an identity, and that identity is _assumed_ to be correct on subsequent requests. Until someone logs-in, they haven't proved their identity, so we can't call this legitimate 'authentication'. I know you probably know this already since you've used Shiro's API for a while now, I just want to point this out for anyone who comes across this thread in the future. > Once you are logged in, there is a section of the > application that is entirely a single page javascript application. This JS > app uses ajax calls to a RESTful jersey service hosted on the same server. > The cookie works fine to authenticate for the jersey services as well. > The problem is that I'd like to move my API from http://mysite.com/api to > http://api.mysite.com/. If I do this, I won't be able to use the cookie auth > anymore. Plus, as Tamas suggested below, it is probably best to be stateless > on the server side and expect the user to auth for every REST call. Lastly, > I intend to open up the API in the future, and I'm not sure relying on > cookies is the best technique. You could probably use a subdomain cookie that can be shared across hosts in the same domain. Just set the 'domain' cookie property to .mysite.com (notice the leading '.'). For example, in shiro.ini: securityManager.rememberMeManager.cookie.domain = .mysite.com I'm not sure this is a bad idea, but if you didn't want to go this route, you have a few options: 1. Authenticate once per session, and ensure the session id cookie is also a subdomain cookie and then just ensure the session id accompanies every request. Granted, this does require server state (Sessions), and only you will know how many sessions your server (or cluster). Just make sure you configure Shiro with a Cache if you use its native session support (and a distributed cache if running more than one application node in a cluster). 2. Authenticate on every request, which means Shiro will no longer need to store its authentication state in the session. If you have other parts of code that rely on a Session, you'll still need to go with an approach like #1. My company's product currently uses #2 as the approach with REST based services - it is an Amazon EC2-like model: Each API Consumer (essentially a 3rd-party application) that is allowed to call into my system is assigned its own 'Access ID' (think of this as a consumer-specific 'userername') and a corresponding 'Secret Key' (essentially an application-level 'password'). When an API consumer is registered within my application, I auto generate its Access ID and Secret Key - they're both just randomly generated UUIDs with the dashes stripped out. The Access ID is shown in the UI freely - the Secret Key is hidden unless the end-user requests to see it. Each request that comes in to the system specifies both the Access ID and Secret Key as HTTP headers (all of this is encrypted over a TLS connection). I then have a servlet filter that extracts them, performs the authentication attempt, and if successful, allows the request to continue through the filter chain. If it fails, I immediately return an HTTP 401 Unauthorized status code. 3. However, I'm re-thinking this - HTTP Digest authentication essentially is the same thing in a more secure way and HTTPS isn't required. That might be a better approach than #2. 4. Potentially better than any of these approaches would be TLS mutual authentication, but this has been discussed in a few forums, saying that it incurs a heavy performance hit due to the mutual handshake. It is pretty rock solid though, so pick your poison. > Any advice or insights on how to proceed would be extremely helpful! Without > OAuth support, I'm unclear on the approaches that other are taking. I can't speak for all of the dev team - it would have to be discussed - but I wouldn't have any objections to supporting OAuth in Shiro if the community wanted it. It is just low priority for me personally, so that's why I don't work on it. If anyone would like to help us work on this, I'm sure we'd be quite open to suggestions on the dev list :) Cheers, Les
