W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Authentication - with authentication points.

From: Peter J Churchyard <pjc@trusted.com>
Date: Wed, 31 Jan 1996 10:13:03 -0500 (EST)
Message-Id: <9601311513.AA02865@hilo.trusted.com>
To: pjc <pjc@hilo.trusted.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Here I present a different mechanism for providing authentication point
information. This allows WWW-Authenticate to be used by Proxies and
Gateways to do authentication. I beleive this would remove the need for
proxy-authenticate which can then be treated as a special case of WWW-Auth.
It is compatible with current 1.0 practices.

11.  Access Authentication

   HTTP provides a simple challenge-response authentication mechanism 
|  which may be used by an authentication point to challenge a client
|  request and by a client to provide authentication information. An 
|  authentication point is normally a server but it may also be a proxy
|  or gateway. It uses an extensible, case-insensitive token to identify
   the authentication scheme, followed by a comma-separated list of 
   attribute-value pairs which carry the parameters necessary for achieving
   authentication via that scheme.

       auth-scheme    = token

       auth-param     = token "=" quoted-string

   The 401 (unauthorized) response message is used by an origin server 
   to challenge the authorization of a user agent. This response must 
   include a WWW-Authenticate header field containing at least one 
   challenge applicable to the requested resource.

|      challenge      = *1auth-point auth-scheme 1*SP realm *( "," auth-param )

       realm          = "realm" "=" realm-value
       realm-value    = quoted-string

|      auth-point     = "@"quoted-string

|  The challenge starts with an optional auth-point. If the auth-point
|  is not specified then this implies that the challenge refers to the
|  origin server. If the auth-point is specified as just "@" then this
|  implies the current authentication point (proxy/gateway/origin server).
|  proxies and gateways should just pass on the header as-is. Authentication
|  points should look for their information in responses and remove it before
|  passing whats left onward. If the field becomes empty, then the whole
|  header can be removed.

   The realm attribute (case-insensitive) is required for all 
   authentication schemes which issue a challenge. The realm value 
   (case-sensitive), in combination with the canonical root URL of the 
   server being accessed, defines the protection space. These realms 
   allow the protected resources on a server to be partitioned into a 
   set of protection spaces, each with its own authentication scheme 
   and/or authorization database. The realm value is a string, 
   generally assigned by the origin server, which may have additional 
   semantics specific to the authentication scheme.

   A user agent that wishes to authenticate itself with a 
   server--usually, but not necessarily, after receiving a 401 
   response--may do so by including an Authorization header field with 
   the request. The Authorization field value consists of credentials 
   containing the authentication information of the user agent for the 
   realm of the resource being requested.

|      credentials    = 1*( *1auth-point basic-credentials)
|                     | 1*( *1auth-point auth-scheme #auth-param )

   The domain over which credentials can be automatically applied by a 
   user agent is determined by the protection space. If a prior 
   request has been authorized, the same credentials may be reused for 
   all other requests within that protection space for a period of 
   time determined by the authentication scheme, parameters, and/or 
   user preference. Unless otherwise defined by the authentication 
   scheme, a single protection space cannot extend outside the scope 
   of its server.

   If the authentication point does not wish to accept the credentials
   sent with a request, it should return a 403 (forbidden) response.

   The HTTP protocol does not restrict applications to this simple 
   challenge-response mechanism for access authentication. Additional 
   mechanisms may be used, such as encryption at the transport level 
   or via message encapsulation, and with additional header fields 
   specifying authentication information. However, these additional 
   mechanisms are not defined by this specification.

|  Proxies/gateways that are not acting as authentication points for this
|  request should pass WWW-Authenticate and Authorization headers without
|  modification. Existing implementations should already be doing this. 

|  Authentication points may insert their challenges into WWW-Authenticate
|  headers and must remove their answers from the Authorization headers. 

|  If the authentication point is the first one upstream from the server
|  then the response may be cached as if the cache was on the server side
|  of the authentication point. If the authentication point is not the
|  first one then the response may be cached if retrieval is for the same
|  "user".

TIS Network Security Products Group
voice: 301-527-9500 x123 fax: 301-527-0482
2277 Research Boulevard, 5th Floor, Rockville, MD 20850
Received on Wednesday, 31 January 1996 15:14:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:16 UTC