Authorization with WWW-Authenticate (bis)

[Sylvain Hellegouarch]

Hi all,

Following http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i78 I've
been left wondering how to convey the following semantic with HTTP:

* The request was not fulfilled due to authorization failure and the
server (does not wish to)/(cannot) specify which scheme must be used.

The context is based on HTTP requests issued from Javascript along with a
cookie based authentication system.

RFC 2616 tells me I cannot reply neither with a 401 without a scheme nor
can I use a 403 since subsequent Authorization would not help.

At first I was tempted to simply use one of the 30x code to inform the
Javascript handler that it should act accordingly but browsers don't
bubble up 30x responses to the Javascript stack which leaves me the
already burdened 400.

There seemed to be a consensus two years ago not to split the
Authorization header from its WWW-Authenticate friend but to me the
semantic of one without the other remains.

Today I'm merely seeking the group advice on what would be the best
decision to make.

Thanks,
- Sylvain
--
Sylvain Hellegouarch
http://www.defuze.org

[Thomas Broyer-2]

On Fri, Oct 23, 2009 at 5:57 PM, Sylvain Hellegouarch wrote:

>
> Following http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i78 I've
> been left wondering how to convey the following semantic with HTTP:
>
> * The request was not fulfilled due to authorization failure and the
> server (does not wish to)/(cannot) specify which scheme must be used.
>
> The context is based on HTTP requests issued from Javascript along with a
> cookie based authentication system.
>
> RFC 2616 tells me I cannot reply neither with a 401 without a scheme nor
> can I use a 403 since subsequent Authorization would not help.
>
> At first I was tempted to simply use one of the 30x code to inform the
> Javascript handler that it should act accordingly but browsers don't
> bubble up 30x responses to the Javascript stack which leaves me the
> already burdened 400.
>
> There seemed to be a consensus two years ago not to split the
> Authorization header from its WWW-Authenticate friend but to me the
> semantic of one without the other remains.
>
> Today I'm merely seeking the group advice on what would be the best
> decision to make.

Help me advancing and finishing "HTTP Cookie Auth" ;-)
http://tools.ietf.org/html/draft-broyer-http-cookie-auth
http://hg.ltgt.net/http-cookie-auth/

(this is only a matter of time I have available to work on it –much
less than I'd like–, do not see the absence of work as a giving up)

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

[Sylvain Hellegouarch]

Thomas Broyer a écrit :

> On Fri, Oct 23, 2009 at 5:57 PM, Sylvain Hellegouarch wrote:
>  
>> Following http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i78 I've
>> been left wondering how to convey the following semantic with HTTP:
>>
>> * The request was not fulfilled due to authorization failure and the
>> server (does not wish to)/(cannot) specify which scheme must be used.
>>
>> The context is based on HTTP requests issued from Javascript along with a
>> cookie based authentication system.
>>
>> RFC 2616 tells me I cannot reply neither with a 401 without a scheme nor
>> can I use a 403 since subsequent Authorization would not help.
>>
>> At first I was tempted to simply use one of the 30x code to inform the
>> Javascript handler that it should act accordingly but browsers don't
>> bubble up 30x responses to the Javascript stack which leaves me the
>> already burdened 400.
>>
>> There seemed to be a consensus two years ago not to split the
>> Authorization header from its WWW-Authenticate friend but to me the
>> semantic of one without the other remains.
>>
>> Today I'm merely seeking the group advice on what would be the best
>> decision to make.
>>    
>
> Help me advancing and finishing "HTTP Cookie Auth" ;-)
> http://tools.ietf.org/html/draft-broyer-http-cookie-auth
> http://hg.ltgt.net/http-cookie-auth/
>
> (this is only a matter of time I have available to work on it –much
> less than I'd like–, do not see the absence of work as a giving up)
>
>  

Hi Thomas,

This is indeed a good starting point. I went through your proposal and
I'm a bit unclear about the actual end-to-end workflow performed by the
UA. I'm not sure to understand how the different directives would be
applied.

- Sylvain

[Thomas Broyer-2]

On Sat, Oct 24, 2009 at 3:17 PM, Sylvain Hellegouarch wrote:

> Thomas Broyer a écrit :
>>
>> Help me advancing and finishing "HTTP Cookie Auth" ;-)
>> http://tools.ietf.org/html/draft-broyer-http-cookie-auth
>> http://hg.ltgt.net/http-cookie-auth/
>
> Hi Thomas,
>
> This is indeed a good starting point. I went through your proposal and I'm a
> bit unclear about the actual end-to-end workflow performed by the UA. I'm
> not sure to understand how the different directives would be applied.

Think of how HTML form and cookie-based auth is done today. Now:
 1. replace any "redirect to login form" with either a 3xx
"Unauthorized, See Other" (to be defined, in preparation for the -01
draft, would need a <meta>-refresh for backwards compat though) or,
better, a 401 with the HTML form (some form-based auth already use 200
with no-cache).
 2. serve the HTML login page with a 401 and a WWW-Authentication:
Cookie. The only required field is the realm (per RFC 2617), fields
about the cookie(s) are RECOMMENDED, and fields about the form (-01
will add two fields to make "machine driven" auth easier, without
having to parse the response body, which might not even be HTML with a
form) are OPTIONAL (because http-cookie-auth doesn't even require that
there is a "form" to be submitted; the cookie could be set by any
mean, including some JS or Flash or ... included in the 401 response).
 3. there's no Authorization request header entering into play, the
Cookie header is enough to convey credentials (which means
authenticated responses should be sent with the appropriate Vary:
Cookie and Cache-Control: private headers).

http-cookie-auth is totally backwards compatible (except unfortunately
with Opera pre-10.0, as Opera will then display an error page about
the auth scheme not being supported); and should require only very
minimal changes to any existing cookie-based auth (including SSOs).
I'm successfully using a similar, custom, auth scheme in an enterprise
app; which I plan to migrate to http-cookie-auth when it will be
"stable" enough.

And now let's continue this discussion in private (and in French ;-) )
or on ietf-http-auth@... ;-)

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

[Nicolas Alvarez-2]

Thomas Broyer wrote:
> http-cookie-auth is totally backwards compatible (except unfortunately
> with Opera pre-10.0, as Opera will then display an error page about
> the auth scheme not being supported);

To avoid this problem again: does the spec say what user agents should do if
they find an unrecognized auth scheme? (ignore vs fail)

[Thomas Broyer-2]

[to the list this time; sorry for the fupe Nicolas]

On Wed, Nov 11, 2009 at 8:36 PM, Nicolas Alvarez
<nicolas.alvarez@...> wrote:
> Thomas Broyer wrote:
>> http-cookie-auth is totally backwards compatible (except unfortunately
>> with Opera pre-10.0, as Opera will then display an error page about
>> the auth scheme not being supported);
>
> To avoid this problem again: does the spec say what user agents should do if
> they find an unrecognized auth scheme? (ignore vs fail)

In the absence of such a thing in HTTP (or HTTPbis), HTML5 defines the
browsers' expected behavior (ignore):
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigating-across-documents

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

[Henrik Nordstrom-5]

ons 2009-11-11 klockan 16:36 -0300 skrev Nicolas Alvarez:
> Thomas Broyer wrote:
> > http-cookie-auth is totally backwards compatible (except unfortunately
> > with Opera pre-10.0, as Opera will then display an error page about
> > the auth scheme not being supported);
>
> To avoid this problem again: does the spec say what user agents should do if
> they find an unrecognized auth scheme? (ignore vs fail)

Relevant quote from RFC2617 which is still the authorative document on
this:

   The user agent MUST
   choose to use one of the challenges with the strongest auth-scheme it
   understands and request credentials from the user based upon that
   challenge.

Wording in RFC2617 is not the greatest, but imho it's pretty clear to
anyone reading the document that scheme is extensible with new schemes
and unknown schemes should be ignored by the user agent.

What is unspecified is how the user agent should behave if none of the
provided challenges is understood. It seems to me that most user agents
then fall back on basic auth with unspecified realm which imho is not a
bad thing to do. Both unlikely to be accepted by the server AND exposing
password details in the plain for no good value, better to abort the
request with an error.

Regards
Henrik

[Nicolas Alvarez-2]

Henrik Nordstrom wrote:
> What is unspecified is how the user agent should behave if none of the
> provided challenges is understood. It seems to me that most user agents
> then fall back on basic auth with unspecified realm which imho is not a
> bad thing to do. Both unlikely to be accepted by the server AND exposing
> password details in the plain for no good value, better to abort the
> request with an error.

Your third sentence makes me think you meant "is a bad thing" or "is not a
good thing" in the second one...

[Thomas Broyer-2]

On Wed, Nov 11, 2009 at 11:52 PM, Henrik Nordstrom wrote:
>
> What is unspecified is how the user agent should behave if none of the
> provided challenges is understood. It seems to me that most user agents
> then fall back on basic auth with unspecified realm which imho is not a
> bad thing to do. Both unlikely to be accepted by the server AND exposing
> password details in the plain for no good value, better to abort the
> request with an error.

All user agents I tested just displayed the response entity, except
Opera pre-10 which displayed an error page about the auth scheme not
being recognized:
http://hg.ltgt.net/http-cookie-auth/raw-file/tip/ua-compat.html

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

[Sylvain Hellegouarch]

Thomas Broyer a écrit :

> On Wed, Nov 11, 2009 at 11:52 PM, Henrik Nordstrom wrote:
>  
>> What is unspecified is how the user agent should behave if none of the
>> provided challenges is understood. It seems to me that most user agents
>> then fall back on basic auth with unspecified realm which imho is not a
>> bad thing to do. Both unlikely to be accepted by the server AND exposing
>> password details in the plain for no good value, better to abort the
>> request with an error.
>>    
>
> All user agents I tested just displayed the response entity, except
> Opera pre-10 which displayed an error page about the auth scheme not
> being recognized:
> http://hg.ltgt.net/http-cookie-auth/raw-file/tip/ua-compat.html
>
>  

Based on the context this scheme would be used (meaning I assume mostly
along with Ajax), I guess this shouldn't be much of a problem anyway.

- Sylvain

[Thomas Broyer-2]

On Thu, Nov 12, 2009 at 8:25 PM, Sylvain Hellegouarch <sh@...> wrote:

> Thomas Broyer a écrit :
>>
>> On Wed, Nov 11, 2009 at 11:52 PM, Henrik Nordstrom wrote:
>>
>>>
>>> What is unspecified is how the user agent should behave if none of the
>>> provided challenges is understood. It seems to me that most user agents
>>> then fall back on basic auth with unspecified realm which imho is not a
>>> bad thing to do. Both unlikely to be accepted by the server AND exposing
>>> password details in the plain for no good value, better to abort the
>>> request with an error.
>>
>> All user agents I tested just displayed the response entity, except
>> Opera pre-10 which displayed an error page about the auth scheme not
>> being recognized:
>> http://hg.ltgt.net/http-cookie-auth/raw-file/tip/ua-compat.html
>
> Based on the context this scheme would be used (meaning I assume mostly
> along with Ajax), I guess this shouldn't be much of a problem anyway.

http-cookie-auth isn't at all limited to AJAX uses!
See http://hg.ltgt.net/http-cookie-auth/raw-file/tip/research.html

There are many frameworks out there where you settle for an auth
mechanism and it gets applied to each and every resource (URL) in your
app (e.g. ASP.NET, Alfresco's WebScripts framework, etc.)

For instance, we're using a custom scheme very similar to Cookie (it
also allows the credentials to be passed in an Authorization header,
for use with... AJAX! yes, AJAX calls use Authorization and cookies
are only used for non-AJAX requests, in our case, the admin section)
in an Enterprise app (this means admins cannot use Opera pre-10, but
we're only actually targeting IE6 only):
Demo AJAX app: https://ubic.atolcd.com/
Demo "web 1.0" admin interface:
https://ubic.atolcd.com/alfresco/us/ubic/admin/ (the login screen is
returned in a 401 response)
(presentation of the project:
http://storage.pardot.com/47721_Alfresco_Case_Study_EADS_Astrium.pdf
or in French: http://www2.alfresco.com/l/1234/2009-11-02/FLDWF/48971_Alfresco_Case_Study_EADS_Astrium_fr.pdf
)

--
Thomas Broyer
/tɔ.ma.bʁwa.je/