- From: Peter J Churchyard <pjc@trusted.com>
- Date: Wed, 31 Jan 1996 10:13:03 -0500 (EST)
- 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. Pete. ------------------------------------------------------------------------- 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