Security at the ATHENA level or the webserver level?

[Gary Moore]

We're working on designing security for ATHENA and I had the thought that we might not want to put security in the ATHENA layer. Apache already has robust and battle tested tools (reverse proxying and mod_security). Re-inventing all this stuff at the web-application level, while cool, could be redundant.

Currently, The goal of ATHENA-Security is simply to enforce that web-clients using ATHENA are authorized to do so. We aren't (yet) concerned with users, access control, LDAP, etc..

Upsides to putting this on Apache:
- It's been done
- It's been tested
- It's a fairly common solution
- mod_proxy and mod_security are open source
- Offers some more routing and balancing solutions for ATHENA components

Downsides:
- We're trying *really* hard to avoid technology lock-in. Mandating that ATHENA installations use Apache runs contrary to that.
- ATHENA installations can't be "secure" unless sitting behind Apache

I figured that most ATHENA installs will be behind a webserver of some sort, but making that part of the package feels wrong for some reason.

Thoughts, please.

Gary

--
Gary Moore | gary....@fracturedatlas.org | @gsmoore
Fork us on Github: http://github.com/fracturedatlas/
Join us on IRC: ##athena on irc.freenode.net

[Adam Huttler]

I'm a big fan of Digest Authentication for this, which comes more or less
"out of the box" with Apache. If HTTP is the messaging protocol for web
clients talking to ATHENA, then why not using an authentication protocol
that was designed for HTTP? It also avoids the tech lock-in problem, since
it's trivial to implement outside of Apache.

Digest Authentication would be pretty nasty for user authentication, but
it seems like a great fit for client authentication in this case.

> --
> Visit: http://athena.fracturedatlas.org/tix
> Fork: http://github.com/fracturedatlas
> Chat: ##athena on Freenode
>
> You received this email because you are subscribed to the "ATHENA Tix
> Developers" group on Google Groups.
>
> To post, email: athena-t...@googlegroups.com
> To unsubscribe, email: athena-tix-dev...@googlegroups.com
> For more, visit: http://groups.google.com/group/athena-tix-devel?hl=en

[Christopher Ashworth]

(mobile)

On Jan 3, 2011, at 5:03 PM, Gary Moore <gary....@fracturedatlas.org> wrote:

> Re-inventing all this stuff at the web-application level, while cool, could be redundant.

My security geek friends advocate for avoiding the reinvention of security stuff if at all possible, on the basis that it's often hard to get right.

Thumbs up re-use!

-C

[Fintan Donaghy]

2 legged Oauth (AKA "signed fetch") does what we want

http://www.kyle-jensen.com/secure-your-api-with-two-legged-oauth

http://sites.google.com/site/oauthgoog/2leggedoauth/2opensocialrestapi

--------------------------------------------------
From: "Christopher Ashworth" <ch...@figure53.com>
Sent: Monday, January 03, 2011 10:48 PM
To: <athena-t...@googlegroups.com>
Subject: Re: [athena-tix-devel] Security at the ATHENA level or the
webserver level?

>
>

[Gary Moore]

My original concern with Digest and two-legged OAuth was this:

Right now, ATHENA only cares about what client application is talking to ATHENA. ATHENA does not care about *what user is logged into that application*

Eventually, though, ATHENA will care. If we use, say, Digest Authentication to authenticate the client, will that interfere with whatever solution we use to authenticate the user? Will it be difficult for clients to implement client authentication with Digest AND user authentication with OAuth (or whatever)?

Or, at the the point where we care about users, do we stop caring about clients? (I argue that we still care about the client).

This was my original argument for API-key auth for clients. It's simple to implement and doesn't preclude end-use authentication schemes.

Gary

[Adam Huttler]

I don't know much about 2-legged OAuth, but I do have experience with
Digest. Digest authentication is handled entirely via HTTP headers, so as
far as I know it shouldn't preclude any other mechanism for authenticating
end users, including OAuth. As long as we're committed to API calls being
made over HTTP, then we'll always have headers to deal with and there's no
reason that I can think of that Digest wouldn't work.

And yeah, it basically *is* API-key auth (this is exactly what I'm
currently using it for) in so far as it's just a username (i.e. client
identifier) and password (i.e. API key). It just has the added benefit
that you never have to send a password over plaintext, even if you don't
have an SSL-encrypted connection.

(FWIW, I agree that we always have to be concerned with the client.)

[Stjepan Rajko]

I've had good experiences with OAuth 2 recently.  From a client perspective, using the protocol was really easy, and on the server side it doesn't seem like it would be much more complicated.  OAuth 1 on the other hand pretty much requires using a library (many of which are available), or going through a lot of pain, on both client and server side.

OAuth 1 and OAuth 2 include both client and user authentication/authorization, so if you're planning ahead for user authorization OAuth might be a good choice.

I am not sure on this, but I suspect that there may be conflicts in using both Digest and OAuth, because parts of OAuth use the Authorization header (as does Digest, if I'm not mistaken), so there might be a conflict there.  A la http://stackoverflow.com/questions/3761845/multiple-authentication-schemes-for-http-authorization-header

One thing about OAuth 2 to consider is that it relies pretty heavily on https for security. So if you're wanting to keep http an option you may want to look into this more deeply. But since you are building a sales system, maybe using https exclusively for authorized requests is a safer route anyway (OAuth1 does not suffer from this, btw).

Best,

Stjepan

On Tue, Jan 4, 2011 at 8:28 AM, Adam Huttler <adam.h...@fracturedatlas.org> wrote:

I don't know much about 2-legged OAuth, but I do have experience with
Digest. Digest authentication is handled entirely via HTTP headers, so as
far as I know it shouldn't preclude any other mechanism for authenticating
end users, including OAuth. As long as we're committed to API calls being
made over HTTP, then we'll always have headers to deal with and there's no
reason that I can think of that Digest wouldn't work.

And yeah, it basically *is* API-key auth (this is exactly what I'm
currently using it for) in so far as it's just a username (i.e. client
identifier) and password (i.e. API key). It just has the added benefit
that you never have to send a password over plaintext, even if you don't
have an SSL-encrypted connection.

(FWIW, I agree that we always have to be concerned with the client.)

> -----Original Message-----
> From: athena-t...@googlegroups.com [mailto:athena-tix-
> de...@googlegroups.com] On Behalf Of Gary Moore

> Sent: Tuesday, January 04, 2011 10:21 AM
> To: athena-t...@googlegroups.com

[Adam Huttler]

Digest and OAuth would only conflict if they both needed to be used for client authentication, right? Or are you saying that using Digest for the client authentication would somehow preclude using OAuth for the user authentication?

[Stjepan Rajko]

On Tue, Jan 4, 2011 at 6:45 PM, Adam Huttler <adam.h...@fracturedatlas.org> wrote:

Digest and OAuth would only conflict if they both needed to be used for client authentication, right? Or are you saying that using Digest for the client authentication would somehow preclude using OAuth for the user authentication?

I'm not an expert on this, so please consider this only my best attempt at accurate statements:

A client could not, in a single request, include both client auth using Digest and user auth using OAuth in the Authorization header.  A client could perhaps include client auth using Digest in the Authorization header while using a different method to supply the OAuth user auth (e.g., supplying the oauth token in the URL), but this strikes me as unconventional and might complicate things for clients.

Also, as OAuth includes both client auth and user auth (and authenticating the client in OAuth is a prerequisite for user authorization), it would seem unnecessary to use both Digest and OAuth.

Perhaps one solution would be to use the same client credentials for both Digest and OAuth, and allow the client to use either Digest or OAuth, but not both in the same request.  This might slightly complicate things on the server side but provide clients with more options.

The sense I get is that OAuth is becoming the standard for online APIs, and OAuth2 seems to be pushing out OAuth1.

Best,

Stjepan

[Gary Moore]

Adam,

"Digest and OAuth would only conflict if they both needed to be used for client authentication, right?"

They are compatible in that they don't use the same header names (except maybe "nonce" have to double check). The problem is ease of client implementation. There are client-side libraries that support both, but I'm sure they woul dbe had to work in concert together (arts reference!)

Stjepan,

I'm a big fan of OAuth2, but the reliance on SSL hurts a bit. We're trying not to require SSL for all ATHENA implementations.

[Adam Huttler]

OAuth2 does sound like a more flexible and forward-compatible approach,
but I share your concern about requiring SSL. Does it mitigate that
problem at all to support self-signed certificates? (Perhaps some future
version of ATHENA could even manage the process of creating the SSL cert.)

You also expressed concerns about ease/speed of development. Apache makes
it super simple to deploy server-side digest authentication... Is there an
existing open source Java library that could accomplish the same thing
with OAuth2?

> -----Original Message-----
> From: athena-t...@googlegroups.com [mailto:athena-tix-
> de...@googlegroups.com] On Behalf Of Gary Moore
> Sent: Tuesday, January 04, 2011 10:39 PM
> To: athena-t...@googlegroups.com
> Subject: Re: [athena-tix-devel] Security at the ATHENA level or the
> webserver level?
>

> devel+un...@googlegroups.com

> Visit: http://athena.fracturedatlas.org/tix
> Fork: http://github.com/fracturedatlas
> Chat: ##athena on Freenode
>
> You received this email because you are subscribed to the "ATHENA Tix
> Developers" group on Google Groups.
>
> To post, email: athena-t...@googlegroups.com
> To unsubscribe, email: athena-tix-dev...@googlegroups.com
> For more, visit: http://groups.google.com/group/athena-tix-devel?hl=en
>
> --
> Visit: http://athena.fracturedatlas.org/tix
> Fork: http://github.com/fracturedatlas
> Chat: ##athena on Freenode
>
> You received this email because you are subscribed to the "ATHENA Tix
> Developers" group on Google Groups.
>
> To post, email: athena-t...@googlegroups.com
> To unsubscribe, email: athena-tix-dev...@googlegroups.com
> For more, visit: http://groups.google.com/group/athena-tix-devel?hl=en
>
> --
> Gary Moore | gary....@fracturedatlas.org | @gsmoore
> Fork us on Github: http://github.com/fracturedatlas/
> Join us on IRC: ##athena on irc.freenode.net
>

[Gary Moore]

All,

Thanks much for the comments.

I propose to use Digest Auth for Authing Client Applications in ATHENA 1.0. The reasons are outlined below:

0) The data provided by ATHENA is too sensitive to rely simply on an API key. Accessing ATHENA with only an API key is akin to using an API key for your database access.

1) Digest is widely supported by both server and client libraries.

2) It is implementable at different levels. ATHENA implementors can turn it on at the Apache, Web Container, or ATHENA level without impact to Client Applications.

3) Digest is supported by our testing tools: RESTClient and curl. It is also supported within Jersey, the framework on which we built our HTTP/JSON endpoints

4) OAuth1 is being superseded by OAuth2

5) OAuth2 requires SSL and we don't want to have to require it in kind.

6) This at least gives us a story to stick to when migrating to user auth at some later date. The Client Application can replace its credentials with that of the user.

Thanks, all. Drop into our Athena Chatroom on Freenode if you've got a sec: ##athena