Subject: Re: Interop issue: how can clients force authentication?

From: Dan Brotsky <[email-masked]>
Date: Wed, 16 Oct 2002 08:50:45 -0700

As usual, sorry for letting so much time pass before jumping in.

On Friday, September 20, 2002, at 05:39 AM, Clemm, Geoff wrote:
> I believe the problem statement is:
>
> The problem: A client wants to check if the current user is
> authenticated to do an operation before it has that user provide the
> input for that operation, and before it performs expensive
> computations to set up the input for that request.

Almost.  As you can see from my other message, I believe it's actually 
more:

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: Document in the 2518bis that the authentication check
> SHOULD be performed before the If header check (so that a simple
> contradictory If header can be used to check the authentication for
> "dummy version" of the operation, i.e. one with dummy values that did
> not require user input or expensive calculations on the client).

Unfortunately this (a) doesn't allow checking for a number of different 
methods in a single call, and (b) doesn't require the server to check 
authorization, just authentication.  What's wanted is for the server to 
return 401 unless the user is actually authorized to perform all those 
methods, not simply authenticated.  I don't believe it's actually 
reasonable to require servers to perform authorization checks before 
they perform IF checks (consider that IF checks may be much cheaper to 
perform than going to some back-end LDAP database to get ACL info).  In 
addition, many servers are going to want to simply return 403 to the 
request (indicating that the current user is not authorized for that) 
rather than to re-challenge, which is what the client wants to happen.

I'm afraid that the extensive discussion around this is causing me to 
believe that it's beyond the scope of what we can cover in 2518-bis, 
and quite possibly what we can cover in any extension of DAV.  But 
there's a proposal of Julian's (do PROPPATCH on a specially known live 
property) that I believe has some chance of doing what we want, and 
I'll send another message with just that revised proposal.

     dan

---

From: Dan Brotsky <[email-masked]>
Date: Wed, 16 Oct 2002 08:52:19 -0700

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

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 21 Oct 2002 10:47:10 +0200

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: [email-masked]
> [mailto:[email-masked]]On Behalf Of Dan Brotsky
> Sent: Wednesday, October 16, 2002 5:52 PM
> To: [email-masked]
> Cc: Dan Brotsky
> Subject: Re: Interop issue: how can clients force authentication?
>
>
>