You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Alexander Klimetschek <ak...@day.com> on 2010/06/04 13:52:42 UTC

HTTP Digest Authentication with Sling

Hi all,

(sorry for cross-posting)

did anyone implement a Sling AuthenticationHandler for HTTP digest
auth already (or at least looked into it)?

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: HTTP Digest Authentication with Sling

Posted by Justin Edelson <ju...@gmail.com>.

On Jun 6, 2010, at 9:31 AM, Alexander Klimetschek <ak...@day.com>  
wrote:

> On Fri, Jun 4, 2010 at 20:25, Felix Meschberger <fm...@gmail.com>  
> wrote:
>> Hi,
>>
>> This does not sound to add real security, since the passwords are
>> essentially stored in plain text (with respect to gaining access to  
>> the
>> system).
>
> No, as I've written md5 of "username : realm : password" would be
> stored in the repository. If that md5 is created upon user
> registration already, no plain text of the password would be stored on
> the server-side at any time.
>
> But I think that because of somehow being the end-user password the
> shared secret between server and client, digest auth is generally not
> very practical. I think OpenID is better for my use case, especially
> because the user management system is external and is a "given". Next:
> convince the ones who came up with using digest auth ;-)

This actually sounds like SAML would be a better fit.

Just my 2 cents.

Justin

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

Re: HTTP Digest Authentication with Sling

Posted by Alexander Klimetschek <ak...@day.com>.
On Fri, Jun 4, 2010 at 20:25, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> This does not sound to add real security, since the passwords are
> essentially stored in plain text (with respect to gaining access to the
> system).

No, as I've written md5 of "username : realm : password" would be
stored in the repository. If that md5 is created upon user
registration already, no plain text of the password would be stored on
the server-side at any time.

But I think that because of somehow being the end-user password the
shared secret between server and client, digest auth is generally not
very practical. I think OpenID is better for my use case, especially
because the user management system is external and is a "given". Next:
convince the ones who came up with using digest auth ;-)

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: HTTP Digest Authentication with Sling

Posted by Felix Meschberger <fm...@gmail.com>.
Hi,

This does not sound to add real security, since the passwords are
essentially stored in plain text (with respect to gaining access to the
system).

Regards
Felix

On 04.06.2010 19:55, Alexander Klimetschek wrote:
> On Fri, Jun 4, 2010 at 16:17, Felix Meschberger <fm...@gmail.com> wrote:
>> As you said "password's md5": This is IIUIC the problem. Doesn't digest
>> auth need to know the plaintext password to be able to generate the
>> challenge ?
> 
> Not necessarily, the server "only" needs to know/store an MD5 of
> "username : realm : password", where the realm can be a fixed string
> (see section 4.13 of RFC-2617 [1]). I think in my scenario it could be
> possible to store this information inside the repository, but I am
> still investigating.
> 
> [1] http://tools.ietf.org/html/rfc2617#section-4.13
> 
> Regards,
> Alex
> 

Re: HTTP Digest Authentication with Sling

Posted by Alexander Klimetschek <ak...@day.com>.
On Fri, Jun 4, 2010 at 16:17, Felix Meschberger <fm...@gmail.com> wrote:
> As you said "password's md5": This is IIUIC the problem. Doesn't digest
> auth need to know the plaintext password to be able to generate the
> challenge ?

Not necessarily, the server "only" needs to know/store an MD5 of
"username : realm : password", where the realm can be a fixed string
(see section 4.13 of RFC-2617 [1]). I think in my scenario it could be
possible to store this information inside the repository, but I am
still investigating.

[1] http://tools.ietf.org/html/rfc2617#section-4.13

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: HTTP Digest Authentication with Sling

Posted by Felix Meschberger <fm...@gmail.com>.
Hi,

On 04.06.2010 15:20, Alexander Klimetschek wrote:
> On Fri, Jun 4, 2010 at 14:34, Felix Meschberger <fm...@gmail.com> wrote:
>> I am not sure, whether this is easy to achieve given the algorithm
>> description for HTTP digest authentication and not knowing the plain
>> text password on the server side.
> 
> True, but in my case a custom jackrabbit LoginModule would be present
> anyway, syncing users (and their password's md5s) from an external
> system.

As you said "password's md5": This is IIUIC the problem. Doesn't digest
auth need to know the plaintext password to be able to generate the
challenge ?

Also, once you hit the LoginModule throught Repository.login there is no
chance to get back at the client to ask for credentials. So your
authentication handler needs to be able to access user password upfront
before going to the login module and indicate a pre-authenticated request.

Regards
Felix

> 
> Regards,
> Alex
> 

Re: HTTP Digest Authentication with Sling

Posted by Alexander Klimetschek <ak...@day.com>.
On Fri, Jun 4, 2010 at 14:34, Felix Meschberger <fm...@gmail.com> wrote:
> I am not sure, whether this is easy to achieve given the algorithm
> description for HTTP digest authentication and not knowing the plain
> text password on the server side.

True, but in my case a custom jackrabbit LoginModule would be present
anyway, syncing users (and their password's md5s) from an external
system.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: HTTP Digest Authentication with Sling

Posted by Felix Meschberger <fm...@gmail.com>.
Hi,

On 04.06.2010 13:52, Alexander Klimetschek wrote:
> Hi all,
> 
> (sorry for cross-posting)
> 
> did anyone implement a Sling AuthenticationHandler for HTTP digest
> auth already (or at least looked into it)?

Not to my knowledge.

I am not sure, whether this is easy to achieve given the algorithm
description for HTTP digest authentication and not knowing the plain
text password on the server side.

Regards
Felix