RE: Interop issue: how can clients force authentication?

A couple of comments:

- Many servers will not be able to perform "what if" calculations,
or will only be able to perform them on a limited set of (probably
less interesting) methods.

- Even if the server comes back and says "yes, you could do that",
by the time you get around to trying it, it may fail because the
state on the server has changed, so a client needs to be prepared
to handle the "not authorized" response in the middle of a stream
of requests anyway.

- And assuming the preceding reasons haven't convinced you that this
isn't worth doing (:-), I'd suggest the alternative proposal, which
says that a server that wants to provide this capability does two
things: 

 - Do authentication checks before "If" header checks
 - Correctly support the "If" header (in particular, support "Not")

Then a client just submits the sequence of requests it wants the
server to pre-authenticate, but includes with each request the header:
 If: ("A" Not "A")
Then if you get an authentication error, you know you are not 
authenticated, but if you get a precondition-failed error, you
know you are authenticated.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Monday, October 21, 2002 4:47 AM
To: w3c-dist-auth@w3.org
Subject: RE: Interop issue: how can clients force authentication?



Dan,

a few comments:

- trying to set a dead property before going on with resource modifications
certainly is interoperable,

- I don't think that the information "which methods can I invoke with the
current credentials" belongs into a live property -- it certainly sounds
like an additional optional REPORT (for which support can be detected using
DAV:supported-report-set),

- I've got the feeling that this isn't how authentication should work in
HTTP. Either you are authenticated, or you aren't. If your current
privileges are not sufficient for a specific method, you'll get a 403. IMHO,
if a client thinks that it might succeed with different credentials, it
should be initiate the new authentication itself.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dan Brotsky
> Sent: Wednesday, October 16, 2002 5:52 PM
> To: w3c-dist-auth@w3.org
> Cc: Dan Brotsky
> Subject: Re: Interop issue: how can clients force authentication?
>
>
>
> The problem: Before starting a sequence of requests on a resource, a
> client wants to ensure that it is authenticated as a principal who is
> authorized to perform all the various methods in the sequence.  If it
> is not so authenticated, it wants to be rechallenged so it can
> reauthenticate.
>
> The proposal (with thanks but no blame to Julian): The client sends a
> (probably unauthorized) request to PROPPATCH the DAV:authorized-methods
> property of the resource with an methods element containing a
> checkauthorization element and elements for each of the methods it
> wishes to use.
>
>    <!ELEMENT methods (checkauthorization? options? get? put? mkcol?
> lock? ...) >
>    <!ELEMENT checkauthorization EMPTY >
>    <!ELEMENT options EMPTY >
>    <!ELEMENT get EMPTY >
>    ...
>    (extra credit: guess who desperately needs Julian, Stefan, and Geoff
> to fix his XML...)
>
> In the wonderfully-future-compliant case: the server actually looks at
> the value of the property specified, and continues to challenge (401)
> the client until the client authenticates as a user who is actually
> authorized to perform all those methods on that resource.  At that
> point the server return 409 because (ha!) DAV:authorized-methods is
> actually a read-only property.
>
> In the currently compliant server case: the server just
> authenticates/authorizes the user for the PROPPATCH on the resource,
> and then either sets the (dead) property or refuses the request (403,
> presumably), because the user is trying to set a property in the DAV:
> space that's not mentioned in the current version of the spec. :^)
>
> ----------
>
> PROPOSED LANGUAGE (first shot, sort of):
>
> - Define the property DAV:authorized-methods as a live property whose
> value is a methods element.
>
> - A server SHOULD return, as the result of a PROPFIND on
> DAV:authorized-methods, EITHER the set of methods that the requesting
> principal is authorized for over that resource OR 404 Not Found
> (meaning the server doesn't want to or is unable to tell you).
>
> - A server MAY treat DAV:authorized-methods as a dead property (for
> backward compatibility).
>
> - If a client attempts to PROPPATCH the value of
> DAV:authorized-methods, it MUST use a checkauthorization element as the
> first member of the property, and it MUST include all the methods that
> it want to check authorization for.
>
> - Servers SHOULD respond to client attempts to PROPPATCH the value of
> DAV:authorized-methods by responding with 401 until the client
> authenticates as a principal authorized to perform all such methods on
> the target resource (if there were a target resource).
>
> - Servers MAY respond to client attempts to PROPPATCH the value of
> DAV:authorized-methods as if DAV:authorized-methods were a dead
> property.
>
> ----------
>
> Some impressions and issues:
>
> 1. Sheesh.  What a hack.  But at least it covers the fairly common case
> of servers that authorize LOCK, PUT, PROPPATCH, UNLOCK (and usually
> DELETE) the same way.  Those servers just treat the new property as
> dead, and clients get what they want.
>
> 2. What exactly happens if you PROPPATCH an URL that's not bound to a
> resource, anyway?  That's going to be a very common case if you were
> planning to LOCK the resource first, and you probably don't want the
> server creating the resource on the PROPPATCH.
>
> OK, folks, have at it! :^)
>
>      dan
>