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

From: Jason Crawford <[email-masked]>
Date: Wed, 18 Sep 2002 11:33:10 -0400

On Tuesday, 09/17/2002 at 11:12 MST, "Lisa Dusseault" wrote:
> > -----Original Message-----
> > > There may be other methods which an unauthenticated user can
> > > receive a
> > > success response, but which would work even better if the user were
> > > authenticated.
> >
> > Shouldn't the server just ask for authentication for those methods?
> >
>
> Not necessarily; if it's possible for the request to return a success
> response if the user is unauthenticated, then the server must do so
> right away or it may never be able to give a success response.
>
> If a 401 error is returned the first time a client asks to do one of
> these methods (like a PROPFIND to a partially-readable collection), how
> does the server know the client will ever make the same request?  Maybe
> the user doesn't know a username/password and so hits "cancel", and the
> client doesn't retry.  And if the client software retries, again without
> a username/password, by your logic the server would just respond 401
> again.

So let me turn this around.  Instead of a client asking to be
authenticated, what if the approach becomes that the client asks
not to be authenticated.   Three options...

1) The client just has a header saying that he choses to be unauthenticated
on a given request.   If the server doesn't see this, and the method could
change it's behavior if authenticated, the server asks for authentication.

or

2) The server simply tries to authenticate and the client responds with
something that indicates that he choses not to authenticate or choses
to authenticate anonymously.  The way to do that can be standardized
or the server can pass info to indicate how to do that... which can be
standardized.

or

3) The user is simply told by other means what userid and password
to use to authenticate themselves as an underprivledged (probably
anonymous) user.   And if they subsequently want to change who they
are authenticated as, the user does that in their client GUI.
Subsequent requests are submitted unauthenticated and when the
server finally wants authentication info for a request, it will ask.

I assume this takes care of this one test case.  Will it take care of the
other test cases?

Please forgive me if the above options seem silly, but I don't really
know what the other test cases are.   I could come up with one, but
I don't want to create a red herring.   Could we clearly state what the
scenarios are that we'd like to address?    Lisa has done a good job
outlining this one, but I haven't seen any other scenerio clearly
outlined.

J.

---

From: "Dyer, Kevin" <[email-masked]>
Date: Wed, 18 Sep 2002 12:50:54 -0400

I believe that Stefan was implying for a server to validate through the ACLs
that a resource is protected and that a user has not been authenticated. If
both are true then a server would not give out such information because to
some people even the names of the files are competition sensitive.

If the ACLs indicate that a resource is unprotected then it would not matter
if the client has provided authentication credentials or not.

That said, there is nothing in RFC2518 that states a client and server can
not communicate through an out of band communication path, say LDAP or
application registry, to initialize the client. This would allow a client to
be able to ask up front for authentication credentials. 

-----Original Message-----
From: Lisa Dusseault
To: 'Stefan Eissing'
Cc: Webdav WG
Sent: 9/18/02 12:29 PM
Subject: RE: Interop issue: how can clients force authentication?

> First, I bet that 100% of all non-broken, existing servers do
> authentication checks before looking at the request resource and
> its properities like locks. It's the sensible thing to do, as a
> user might not even have read permission on the resource. So
> one probably should prevent him/her from finding out about the lock
> status of the resource.

No, and why should they?  There's nothing in RFC2518 that requires
servers to support locks only for authenticated users.  If a resource is
publicly writable, there may be nothing to prevent unauthenticated users
from taking out locks and using lock tokens.  Recall that the If header
can also be used with ETags, which are not at all associated with how a
user is authenticated.

Also, recall that in order to "do authentication checks", the server
must respond to the client with a 401 with the WWW-Authenticate header,
then the client must make another request.  

Of course if the client sent its authentication information on the first
request, the server is likely to check it.  However, the client can't
even send its authentication information if it doesn't yet know whether
the server supports digest or basic, or what realm, nonce, etc.  That's
why Ilya wants to be able to ask the server to reply with a
WWW-Authenticate header.  

Lisa

---

From: Jason Crawford <[email-masked]>
Date: Thu, 19 Sep 2002 23:32:03 -0400

On Thursday, 09/19/2002 at 02:27 MST, Ilya Kirnos wrote:
> the fact that this may already work with some implementations is a plus.
on
> the other hand it would pretty much be a hack.  when i see something like
> If: ("a" Not "a"), client authentication is not exactly the first thing
that
> comes to mind.  a new header would make this idea very explicit and
probably
> less prone to implementation errors.  however, i'd like to see this
feature
> implemented in some shape or form, so if there's consensus on the If
header,
> it'd be fine with me.

I'd like to see two things...

1) A clear problem statement with scenarios
2) A clear statement of the/this proposal

Thanks guys

J.

---

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 20 Sep 2002 08:39:33 -0400

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.

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).

As a general design note wrt some of the alternatives proposed:
Adding new protocol semantics (e.g. a new header) for each interesting
use case would rapidly produce a protocol so complex as to be
unusable.  I believe adding explicit marshalling for semantics that
are already supported adds complexity, not clarity, and that increased
complexity will increase the implementation errors, not decrease them.

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:[email-masked]]

on
that
probably
feature
header,

Thanks guys

J.

---

From: "Dyer, Kevin" <[email-masked]>
Date: Fri, 20 Sep 2002 11:31:08 -0400

>From: Clemm, Geoff [mailto:[email-masked]]

With this as the problem statement, I believe that we need to look outside
of our own protocol here and take a look at one or more protocols that only
deal with the authentication and authorization of users and systems. Why
does WebDAV have to come up with the whole package themselves? If we look at
the SAML specifications for a moment, it provides the ability to request
from a server what a particular user is asking for and get back a complete
answer. Yes, it is another call but the user is guaranteed to have a
complete answer as to authentication and authorization across a large circle
of influence. By adopting SAML as the back-end mechanism we will also pick
up a true single sign-on capability for WebDAV, something we've talked about
and alluded to but have not considered it in the RFC.

			Comments, rocks, bottles, or stones?

				Kevin

____________________________________________ 
Kevin J. Dyer
Sr. Technologist, Product Management
[email-masked]

TEL:     978-322-2011
FAX:     978-322-2040
MOBILE:  978-549-0971

MatrixOne, Inc.
Two Executive Drive
Chelmsford, MA  01824  USA
www.matrixone.com

"Changing the way the world brings products to market" (tm)
____________________________________________

---

From: Jason Crawford <[email-masked]>
Date: Sun, 22 Sep 2002 22:37:14 -0400

> With this as the problem statement, I believe that we need to look
outside of
> our own protocol here and take a look at one or more protocols that only
deal
> with the authentication and authorization of users and systems. Why does
WebDAV
> have to come up with the whole package themselves? If we look at the SAML

> specifications for a moment, it provides the ability to request from a
server
> what a particular user is asking for and get back a complete answer. Yes,
it is
> another call but the user is guaranteed to have a complete answer as to
> authentication and authorization across a large circle of influence. By
> adopting SAML as the back-end mechanism we will also pick up a true
single
> sign-on capability for WebDAV, something we've talked about and alluded
to but
> have not considered it in the RFC.
>

SAML is probably pretty good, but our needs appear to be minimal (or less)
and
as you can see from Geoff's posting, providing that capability in some form
would
probably be trivial. That doesn't mean that clients shouldn't/can't use
SAML.  They
can if they want.  But it's not something that is generally required to
achieve the
WebDAV functionality and interoperability, at least not for
this problem,  so it probably doesn't need to go in the base WebDAV spec.