[RT] Extending the authentication bundle

[Carsten Ziegeler <cz...@apache.org>]

Hi,

I think the new authentication bundle is a great step forward. However
:) I think we should enhance it a little bit to support cookie/session
based authentication.

For basic auth everything works fine as user/password are send on each
request by design.

With cookie/session based authentication you usually have a form which
you use to authenticate once and then you get some kind of an id - this
can be a session id or some id in a cookie identifying you. Whenever the
server receives this id it verifies that the id has not been hijacked
and by looking at the id does the authentication for this request.
Currently this is done by an authentication handler and to properly do
this, it requires the authentication handler to store the user and
password somewhere - either in the cookie, the session, the repository,
in memory etc. Regardless of where the password is stored, it is imho
bad practice to store the password at all.

When the authentication handler receives the id and has successfully
performed the hijacking check, the handler knows from which user the
request is comming and that this user has already successfully
authenticated.

So what about adding something like a trusted credentials object which
is added to the authentication info in this case. This credentials
object contains just the user.

The trusted credentials object can be used by the Authenticator to do
whatever is appropriate to authenticate this user.

Now, this solution seems a little bit unsecure to me as the
authentication handler can just create a trusted credentials with the
user. So we could secure this a little bit more by using the feedback
mechanism. If the first request is authenticated by the Authenticator
successfully, it calls the feedback handler and could provide some key
which the authentication handler has to put into the trusted credentials
for this user on further requests. Obivously this key should not be the
password :)

WDYT?

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: [RT] Extending the authentication bundle

[Carsten Ziegeler <cz...@apache.org>]

Vidar Ramdal wrote:
> On Thu, Jan 28, 2010 at 9:17 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> 
>> I think the new authentication bundle is a great step forward. However
>> :) I think we should enhance it a little bit to support cookie/session
>> based authentication.
>> [...]
>> WDYT?
> 
> Two questions immediately comes to mind when considering user sessions:
> 1. Is it really RESTful?
> 2. How do we handle sessions in clustered environment?
Ok, I guess sessions are not restful :) and maybe I shouldn't have
mentioned session in my RT at all :)
Therefore I think we should not care about sessions. However if you want
to use sessions, app servers usually provide replication mechanisms for
a clustered environment or you use sticky sessions.

Nevertheless, the cookie contains some kind if id which identifies the
user - so this can be compared to a session id. If you want to use such
ids with cookies you have to replicate them in a clustered environment
or again use sticky "sessions". These ids can easily be replicated by
storing them in the repository.

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: [RT] Extending the authentication bundle

[Ian Boston <ie...@tfd.co.uk>]

On 28 Jan 2010, at 10:18, Alexander Klimetschek wrote:

> On Thu, Jan 28, 2010 at 11:02, Vidar Ramdal <vi...@idium.no> wrote:
>> Two questions immediately comes to mind when considering user sessions:
>> 1. Is it really RESTful?
> 
> Unfortunately experience has shown that you don't get proper, flexible
> and modern authentication mechanisms to work together with a "full
> restful" authentication. The latter is only achieved by HTTP basic
> auth in practice, but this has a few drawbacks:
> - needs encrypted transport, eg. SSL, as credentials are sent with every request
> - umlauts not properly supported across all browsers (big no go if
> people have secure passwords with umlauts and other special
> characters)
> 
> Kerberos, OpenID, etc., which are secure and/or flexible,
> state-of-the-art on the web, require a session to be kept with the
> request.
> 
> Note that the session should be as small as possible, eg. basically
> only some ID, to reduce the problems associated with them.
> 
>> 2. How do we handle sessions in clustered environment?
> 
> Sticky sessions is probably the best answer, which is handled by the
> proxy/dispatcher. A cluster might not be fast enough (replication done
> in XX ms, since requests for css or image resources are typically sent
> very quickly after the original page) and HTTP session clustering in
> app servers does not scale.


I have been using a a cluster cookie service. The login cookie is a SHA1 of a secret, some info about the user and on the end is a cluster ID of the originating server.

When the cookie enters a app server node, it looks at the cookie, extracts the cluster ID, and calls home to validate the cookie. Once validated its cached on that server. At the moment the "call home" is using an ehcache replicated cache, but the intention is to move that to an using and existing http service for app server to app server cookie validation.


BTW,
I also recently added a TrustedCredentials super class and AnonCredentials and AdministrativeCredentials to Sling to allow Sling to perform logins without the password. The latter 2 are final and not exposed outside the server bundle, but the former could be used for this purpose in some way and all the LoginModule infrastructure is already there (you have to provide CallbackHandlers to decouple Jackrabbits binding to SimpleCredentials in the core JR code).

Ian




> 
> Regards,
> Alex
> 
> -- 
> Alexander Klimetschek
> alexander.klimetschek@day.com

Re: [RT] Extending the authentication bundle

[Alexander Klimetschek <ak...@day.com>]

On Thu, Jan 28, 2010 at 11:02, Vidar Ramdal <vi...@idium.no> wrote:
> Two questions immediately comes to mind when considering user sessions:
> 1. Is it really RESTful?

Unfortunately experience has shown that you don't get proper, flexible
and modern authentication mechanisms to work together with a "full
restful" authentication. The latter is only achieved by HTTP basic
auth in practice, but this has a few drawbacks:
- needs encrypted transport, eg. SSL, as credentials are sent with every request
- umlauts not properly supported across all browsers (big no go if
people have secure passwords with umlauts and other special
characters)

Kerberos, OpenID, etc., which are secure and/or flexible,
state-of-the-art on the web, require a session to be kept with the
request.

Note that the session should be as small as possible, eg. basically
only some ID, to reduce the problems associated with them.

> 2. How do we handle sessions in clustered environment?

Sticky sessions is probably the best answer, which is handled by the
proxy/dispatcher. A cluster might not be fast enough (replication done
in XX ms, since requests for css or image resources are typically sent
very quickly after the original page) and HTTP session clustering in
app servers does not scale.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: [RT] Extending the authentication bundle

[Felix Meschberger <fm...@gmail.com>]

Hi,

On 28.01.2010 11:02, Vidar Ramdal wrote:
> On Thu, Jan 28, 2010 at 9:17 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> 
>> I think the new authentication bundle is a great step forward. However
>> :) I think we should enhance it a little bit to support cookie/session
>> based authentication.
>> [...]
>> WDYT?
> 
> Two questions immediately comes to mind when considering user sessions:
> 1. Is it really RESTful?

Probably not. But we still have the plain HTTP Basic authentication.

> 2. How do we handle sessions in clustered environment?

If we have HTTP Sessions, the cluster should handle this for. In the
case of plain cookies, there are two options: Sticky sessions or
implement a functionality to publish the state amongst the cluster
instances.

Regards
Felix

Re: [RT] Extending the authentication bundle

[Vidar Ramdal <vi...@idium.no>]

On Thu, Jan 28, 2010 at 9:17 AM, Carsten Ziegeler <cz...@apache.org> wrote:

> I think the new authentication bundle is a great step forward. However
> :) I think we should enhance it a little bit to support cookie/session
> based authentication.
> [...]
> WDYT?

Two questions immediately comes to mind when considering user sessions:
1. Is it really RESTful?
2. How do we handle sessions in clustered environment?

-- 
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070

Re: [RT] Extending the authentication bundle

[Felix Meschberger <fm...@gmail.com>]

Hi,

On 28.01.2010 09:17, Carsten Ziegeler wrote:
> Hi,
> 
> I think the new authentication bundle is a great step forward. However
> :) I think we should enhance it a little bit to support cookie/session
> based authentication.
> 
> For basic auth everything works fine as user/password are send on each
> request by design.
> 
> With cookie/session based authentication you usually have a form which
> you use to authenticate once and then you get some kind of an id - this
> can be a session id or some id in a cookie identifying you. Whenever the
> server receives this id it verifies that the id has not been hijacked
> and by looking at the id does the authentication for this request.
> Currently this is done by an authentication handler and to properly do
> this, it requires the authentication handler to store the user and
> password somewhere - either in the cookie, the session, the repository,
> in memory etc. Regardless of where the password is stored, it is imho
> bad practice to store the password at all.
> 
> When the authentication handler receives the id and has successfully
> performed the hijacking check, the handler knows from which user the
> request is comming and that this user has already successfully
> authenticated.
> 
> So what about adding something like a trusted credentials object which
> is added to the authentication info in this case. This credentials
> object contains just the user.

I was thinking along the very same lines while looking at the
authentication handlers from SLING-1116. My solution would be:

The handler stores a special Credentials object into the
AuthenticationInfo object. This is then used by the SlingAuthenticator
to login.

The handler also provides a LoginModulePlugin to accept these special
credentials and verify the identity towards the repository.

Of course, the Credentials implementation is private to the login
handler bundle and thus is reasonable safe to not be abused.

> 
> The trusted credentials object can be used by the Authenticator to do
> whatever is appropriate to authenticate this user.
> 
> Now, this solution seems a little bit unsecure to me as the
> authentication handler can just create a trusted credentials with the
> user. So we could secure this a little bit more by using the feedback
> mechanism. If the first request is authenticated by the Authenticator
> successfully, it calls the feedback handler and could provide some key
> which the authentication handler has to put into the trusted credentials
> for this user on further requests. Obivously this key should not be the
> password :)

So this would mean, that we would have to keep two stores per user
logged in: A store in the Authenticator to be able to verify the "keys"
and a store in the AuthenticationHandler to be able to provide the key
(well the AuthenticationHandler will have a store anyway to be able to
validate the client request).

Regards
Felix