Les,
Thanks for your insights. See inline below.
> 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.
Yes, I'm fully aware of this, but thanks for pointing it out.
> 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
This solution would certainly be easiest to meet my current needs, and
I will probably do this initially for my single-page webapp version.
But would it help for a public API that has 3rd party applications
connecting to it?
Also, how is this configuration made using Spring? I'm not using INI
config. Is it as simple as something like this?
<bean id="securityManager"
class="org.apache.shiro.web.mgt.DefaultWebSecurityManager">
<property name="rememberMeManager" ref="myRememberMeManager"/>
</bean>
<bean name="myRememberMeManager"
class="com.mysite.security.MyRememberMeManager">
<property name="cookie.domain" value=".mysite.com"/>
</bean>
> 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).
So doing this would mean that a 3rd party app would need to direct its
users to my login page for them to login, which would then redirect
them back to the 3rd party app? It would have to do that each time a
new session is created, right? The 3rd party app would need to be able
to handle cookies, but I'm sure most platforms can already do that.
> 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.
This is where I get confused on how to proceed. If my API requires
auth on every request, wouldn't the 3rd party app need to somehow
store that auth information and send it with every request? What are
some good methods of doing this in a secure manner?
Let me be clear here... when I say 3rd party app, I mean several
different things:
1. A mobile client (iPhone, Android, Blackberry, Symbian, etc.)
2. A web-based JAVASCRIPT client, without a server-side component,
hosted on someone else's server.
3. A RIA client, such as an AIR app or something similar
If the application is just a single page of Javascript, it doesn't
seem safe for it to request a username and password and store them in
JS variables to send with each request. I'm starting to think that a
server-side component might be a requirement to do this right for
3rd-party apps.
I guess there are two approaches:
1. The 3rd party app runs completely in the client, and the client
makes requests directly to my API
2. The 3rd party app runs in the client, but makes requests to a
3rd-party server component. The server component makes requests to my
API.
I'm just trying to determine what the best practices are for these
different types of scenarios. My goal is to simply expose a RESTful
API, and all clients would use it, including my own web-based and
mobile clients.
> 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.
So I assume your 3rd party applications are running on a server, and
that your secret key is protected from the public?
> 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.
I'll look into this more.
>> 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 :)
I've barely got me feet wet yet in researching OAuth, but from the
little I've seen, it appears it would help solve some problems. I'm
going to research this further and perhaps offer some suggestions.
Thanks again for your thoughts.
Tauren
