W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2002

Re: Interop issue: how can clients force authentication?

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Tue, 17 Sep 2002 11:20:55 +0200
Cc: Webdav WG <w3c-dist-auth@w3c.org>
To: Ilya Kirnos <ilya.kirnos@oracle.com>
Message-Id: <C4FA8640-CA1E-11D6-9F78-00039384827E@greenbytes.de>

Ilya,

Am Dienstag den, 17. September 2002, um 01:35, schrieb Ilya Kirnos:

>
> Clients currently have no reliable means of forcing the server to
> authenticate them (they can try to preemptively send credentials, but
> this works only for basic auth, not for digest).  This can lead to
> situations where the client finds out that it was required to
> authenticate too late and only after doing lots of work, such as when
> putting a large file only to get a 401 back at the end of the transfer.

A bad user experience, agreed.

However it would be more elegant if the client could send
the request without the server executing it and checking thus
the authentication for the specific method call. That would also
give any intermediates, like proxies, a chance to determine if
they need any authorization.

My idea would be to use the IF header for this purpose. A client
can send a request with an invalid lock token in the IF header.
The server, being DAV-compliant, will never execute the request.

Now this solution depends on the order of authentication vs. IF
header check. Therefore my proposal depends on

- does every known server check authentication before lock tokens?
- could 2518bis say something like: "All user authentication SHOULD
   take place before other request headers like IF are processed."?

//Stefan

> To address this problem, it was proposed to add a Force-Authenticate
> OPTIONS header which would force a compliant server to issue an
> authentication challenge to the client, a la:
>
> Force-Authenticate = "Force-Authenticate" ":" ("T" | "F")
>
> The Force-Authenticate header would be used with the OPTIONS method to
> specify that the client wants to be
> challenged for authentication credentials to the resource identified by
> the Request-URI.  A value of "T"
> indicates that a compliant DAV server MUST respond with a 401
> Unauthorized status code (see
> [RFC2068], section 10.4.2) if the resource identified by the 
> Request-URI
> is protected, i.e., there exists a  DAV method (read,  write, or
> otherwise) that may result in a 401 response for this Request-URI.  Put
> another way, if the server does *not* respond with a 401, it is
> guaranteeing to the client that any DAV operation it may want to apply
> to the Request-URI will not return a 401.
>
> This means that the client has a way of finding out beforehand whether
> it needs credentials to perform an operation, and the server has the
> option of saying "no credentials necessary" if it is sure that in fact
> no credentials are necessary (for example, servers that have no access
> control at all, if any such exist).  I thought it was important to keep
> this option open, although I suspect that most servers would 
> always want
> to challenge since they couldn't really be sure.
>
> Comments?
>
> -ilya
>
>
Received on Tuesday, 17 September 2002 05:21:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:01 GMT