Re: [Bug 18] no record of consensus for force-authenticate

>

Julian writes:

> So this is a process issue -- if it's supposed to become part of  
> WebDAV, it has to make it through the process of (1) define what  
> the problem is, then (2) find a WG consensus of how to resolve  
> this. "Force-Authenticate" may very well be the solution.

OK, I feel pretty strongly about this feature, so let me do the due  
diligence here.

PROBLEM STATEMENT

Some WebDAV servers are configured to allow live authoring, where the  
authored changes are immediately visible to the external world. In  
this situation, resources typically have access controls set such  
that GET, HEAD, POST, PROPFIND and OPTIONS can be performed by any  
user without authentication. Write operations such as PUT, LOCK,  
UNLOCK, MKCOL, MOVE, and COPY require authentication and access  
permissions. In some cases, a client would do a series of operations  
that do not require authentication, then perform a PUT of a large  
resource (this can happen with the common Microsoft Web Folders  
client). In this situation, the large resource body needs to be sent  
twice: the initial PUT (which gets a 401 response), and the second  
PUT, with authentication credentials.

Ideally, a client would like to test a resource to see whether it  
should ever send authentication credentials. It is far more  
convenient for a client author to make a single test at the beginning  
of a session, discover that some methods will require authentication  
credentials, and then consistently supply those authentication  
credentials for every method invocation thereafter. Since a client  
does not know which authentication scheme is in use, or what nonce  
values will be used in Digest Auth, it cannot speculatively provide  
authentication values without receiving a challenge (401) from the  
server first. While in general it is the case that authentication  
requirements can vary by method, even on the same resource, this  
configuration is extremely unusual. Hence, a client that proactively  
supplies a set of authentication credentials gathered from testing  
one method that requires authentication (PUT, say), will likely find  
that these same authentication credentials will work for all other  
methods (LOCK, UNLOCK, etc.) on the same resource that also require  
authentication.

SOLUTION REQUIREMENTS

R1: A client must be able to request an authentication challenge  
without causing a state change on the server
R2:  The mechanism for the authentication challenge must be clearly  
identifiable within the specification
R3: The client must be able to indicate which method the challenge  
pertains to (since this can potentially vary by method, though it  
usually doesn't)

SOLUTION PROPOSAL

I like the Force-Authenticate header as defined in the current draft.  
I don't like the If approach (submit an If header with a known bad  
lock token, hence the method will fail) for three reasons:

* I feel uncomfortable depending on an unintended use of the If  
header -- especially for PUT, if a server ever doesn't handle If  
correctly, the forcing of authentication could inadvertently change  
the contents of the resource (assuming you'd force authentication  
with a zero length body with PUT)
* It depends on the execution order of authentication vs. If header  
processing within servers (I note this was rebutted in:
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/ 
0335.html  and I also note that mod_dav does do authentication checks  
before If checks)
* It's a really obscure way of satisfying the requirements (i.e., it  
fails requirement R2)


My strong preference is for a new mechanism here (Force- 
Authenticate), though I could perhaps be swayed to adding a new  
section to the specification that explicitly describes the use of If  
to force authentication, and gives an example of how this works. I  
don't think this mechanism is one that most implementors would think  
of, even if the have a deep understanding of the spec (like, me, for  
example, who never thought of this).

- Jim

Received on Friday, 28 October 2005 00:33:56 UTC