Changeset 1344


Ignore:
Timestamp:
Jul 24, 2011, 11:59:48 AM (8 years ago)
Author:
julian.reschke@…
Message:

Restructure section 2 (auth framework) in order to decouple Realm

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p7-auth.html

    r1343 r1344  
    543543         </li>
    544544         <li>2.&nbsp;&nbsp;&nbsp;<a href="#access.authentication.framework">Access Authentication Framework</a><ul>
    545                <li>2.1&nbsp;&nbsp;&nbsp;<a href="#authentication.scheme.registry">Authentication Scheme Registry</a></li>
     545               <li>2.1&nbsp;&nbsp;&nbsp;<a href="#challenge.and.response">Challenge and Response</a></li>
     546               <li>2.2&nbsp;&nbsp;&nbsp;<a href="#protection.space">Protection Space (Realm)</a></li>
     547               <li>2.3&nbsp;&nbsp;&nbsp;<a href="#authentication.scheme.registry">Authentication Scheme Registry</a></li>
    546548            </ul>
    547549         </li>
     
    629631  <a href="#core.rules" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt;
    630632</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="access.authentication.framework" href="#access.authentication.framework">Access Authentication Framework</a></h1>
    631       <p id="rfc.section.2.p.1">HTTP provides a simple challenge-response authentication mechanism that can be used by a server to challenge a client request
     633      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="challenge.and.response" href="#challenge.and.response">Challenge and Response</a></h2>
     634      <p id="rfc.section.2.1.p.1">HTTP provides a simple challenge-response authentication mechanism that can be used by a server to challenge a client request
    632635         and by a client to provide authentication information. It uses an extensible, case-insensitive token to identify the authentication
    633636         scheme, followed by a comma-separated list of attribute-value pairs which carry the parameters necessary for achieving authentication
     
    636639      <div id="rfc.figure.u.2"></div><pre class="inline"><span id="rfc.iref.a.1"></span><span id="rfc.iref.a.2"></span>  auth-scheme    = token
    637640  auth-param     = token "=" ( token / quoted-string )
    638 </pre><p id="rfc.section.2.p.3">The 401 (Unauthorized) response message is used by an origin server to challenge the authorization of a user agent. This response <em class="bcp14">MUST</em> include a WWW-Authenticate header field containing at least one challenge applicable to the requested resource. The 407 (Proxy
    639          Authentication Required) response message is used by a proxy to challenge the authorization of a client and <em class="bcp14">MUST</em> include a Proxy-Authenticate header field containing at least one challenge applicable to the proxy for the requested resource.
    640       </p>
    641       <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.c.1"></span>  <a href="#access.authentication.framework" class="smpl">challenge</a>   = <a href="#access.authentication.framework" class="smpl">auth-scheme</a> 1*<a href="#notation" class="smpl">SP</a> 1#<a href="#access.authentication.framework" class="smpl">auth-param</a>
    642 </pre><div class="note" id="rfc.section.2.p.5">
     641</pre><p id="rfc.section.2.1.p.3">The 401 (Unauthorized) response message is used by an origin server to challenge the authorization of a user agent. This response <em class="bcp14">MUST</em> include a WWW-Authenticate header field containing at least one challenge applicable to the requested resource.
     642      </p>
     643      <p id="rfc.section.2.1.p.4">The 407 (Proxy Authentication Required) response message is used by a proxy to challenge the authorization of a client and <em class="bcp14">MUST</em> include a Proxy-Authenticate header field containing at least one challenge applicable to the proxy for the requested resource.
     644      </p>
     645      <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.c.1"></span>  <a href="#challenge.and.response" class="smpl">challenge</a>   = <a href="#challenge.and.response" class="smpl">auth-scheme</a> 1*<a href="#notation" class="smpl">SP</a> 1#<a href="#challenge.and.response" class="smpl">auth-param</a>
     646</pre><div class="note" id="rfc.section.2.1.p.6">
    643647         <p> <b>Note:</b> User agents will need to take special care in parsing the WWW-Authenticate and Proxy-Authenticate header field values because
    644648            they can contain more than one challenge, or if more than one of each is provided, since the contents of a challenge can itself
     
    646650         </p>
    647651      </div>
    648       <div class="note" id="rfc.section.2.p.6">
     652      <div class="note" id="rfc.section.2.1.p.7">
    649653         <p> <b>Note:</b> Many browsers fail to parse challenges containing unknown schemes. A workaround for this problem is to list well-supported
    650             schemes (such as "basic") first.
     654            schemes (such as "basic") first. 
    651655         </p>
    652656      </div>
    653       <p id="rfc.section.2.p.7">The authentication parameter realm is defined for all authentication schemes:</p>
    654       <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.r.1"></span><span id="rfc.iref.r.2"></span>  realm       = "realm" "=" realm-value
     657      <p id="rfc.section.2.1.p.8">A user agent that wishes to authenticate itself with an origin server — usually, but not necessarily, after receiving a 401
     658         (Unauthorized) — <em class="bcp14">MAY</em> do so by including an Authorization header field with the request.
     659      </p>
     660      <p id="rfc.section.2.1.p.9">A client that wishes to authenticate itself with a proxy — usually, but not necessarily, after receiving a 407 (Proxy Authentication
     661         Required) — <em class="bcp14">MAY</em> do so by including a Proxy-Authorization header field with the request.
     662      </p>
     663      <p id="rfc.section.2.1.p.10">Both the Authorization field value and the Proxy-Authorization field value consist of credentials containing the authentication
     664         information of the client for the realm of the resource being requested. The user agent <em class="bcp14">MUST</em> choose to use one of the challenges with the strongest auth-scheme it understands and request credentials from the user based
     665         upon that challenge.
     666      </p>
     667      <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.c.2"></span>  <a href="#challenge.and.response" class="smpl">credentials</a> = <a href="#challenge.and.response" class="smpl">auth-scheme</a> ( <a href="#core.rules" class="smpl">token</a>
     668                            / <a href="#core.rules" class="smpl">quoted-string</a>
     669                            / #<a href="#challenge.and.response" class="smpl">auth-param</a> )
     670</pre><p id="rfc.section.2.1.p.12">If the origin server does not wish to accept the credentials sent with a request, it <em class="bcp14">SHOULD</em> return a 401 (Unauthorized) response. The response <em class="bcp14">MUST</em> include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource.
     671      </p>
     672      <p id="rfc.section.2.1.p.13">If a proxy does not accept the credentials sent with a request, it <em class="bcp14">SHOULD</em> return a 407 (Proxy Authentication Required). The response <em class="bcp14">MUST</em> include a Proxy-Authenticate header field containing a (possibly new) challenge applicable to the proxy for the requested
     673         resource.
     674      </p>
     675      <p id="rfc.section.2.1.p.14">The HTTP protocol does not restrict applications to this simple challenge-response mechanism for access authentication. Additional
     676         mechanisms <em class="bcp14">MAY</em> be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying
     677         authentication information. However, such additional mechanisms are not defined by this specification.
     678      </p>
     679      <p id="rfc.section.2.1.p.15">Proxies <em class="bcp14">MUST</em> forward the WWW-Authenticate and Authorization headers unmodified and follow the rules found in <a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section&nbsp;4.1</a>.
     680      </p>
     681      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="protection.space" href="#protection.space">Protection Space (Realm)</a></h2>
     682      <p id="rfc.section.2.2.p.1">The authentication parameter realm is defined for all authentication schemes:</p>
     683      <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.r.1"></span><span id="rfc.iref.r.2"></span>  realm       = "realm" "=" realm-value
    655684  realm-value = quoted-string
    656 </pre><p id="rfc.section.2.p.9">The realm directive (case-insensitive) is required for all authentication schemes that issue a challenge. The realm value
     685</pre><p id="rfc.section.2.2.p.3">The realm directive (case-insensitive) is required for all authentication schemes that issue a challenge. The realm value
    657686         (case-sensitive), in combination with the canonical root URI (the scheme and authority components of the effective request
    658687         URI; see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) of the server being accessed, defines the protection space. These realms allow the protected resources on a server to be
     
    661690         scheme. Note that there can be multiple challenges with the same auth-scheme but different realms.
    662691      </p>
    663       <p id="rfc.section.2.p.10">A user agent that wishes to authenticate itself with an origin server — usually, but not necessarily, after receiving a 401
    664          (Unauthorized) — <em class="bcp14">MAY</em> do so by including an Authorization header field with the request. A client that wishes to authenticate itself with a proxy
    665          — usually, but not necessarily, after receiving a 407 (Proxy Authentication Required) — <em class="bcp14">MAY</em> do so by including a Proxy-Authorization header field with the request. Both the Authorization field value and the Proxy-Authorization
    666          field value consist of credentials containing the authentication information of the client for the realm of the resource being
    667          requested. The user agent <em class="bcp14">MUST</em> choose to use one of the challenges with the strongest auth-scheme it understands and request credentials from the user based
    668          upon that challenge.
    669       </p>
    670       <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.c.2"></span>  <a href="#access.authentication.framework" class="smpl">credentials</a> = <a href="#access.authentication.framework" class="smpl">auth-scheme</a> ( <a href="#core.rules" class="smpl">token</a>
    671                             / <a href="#core.rules" class="smpl">quoted-string</a>
    672                             / #<a href="#access.authentication.framework" class="smpl">auth-param</a> )
    673 </pre><p id="rfc.section.2.p.12">The protection space determines the domain over which credentials can be automatically applied. If a prior request has been
     692      <p id="rfc.section.2.2.p.4">The protection space determines the domain over which credentials can be automatically applied. If a prior request has been
    674693         authorized, the same credentials <em class="bcp14">MAY</em> be reused for all other requests within that protection space for a period of time determined by the authentication scheme,
    675694         parameters, and/or user preference. Unless otherwise defined by the authentication scheme, a single protection space cannot
    676695         extend outside the scope of its server.
    677696      </p>
    678       <p id="rfc.section.2.p.13">If the origin server does not wish to accept the credentials sent with a request, it <em class="bcp14">SHOULD</em> return a 401 (Unauthorized) response. The response <em class="bcp14">MUST</em> include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource.
    679          If a proxy does not accept the credentials sent with a request, it <em class="bcp14">SHOULD</em> return a 407 (Proxy Authentication Required). The response <em class="bcp14">MUST</em> include a Proxy-Authenticate header field containing a (possibly new) challenge applicable to the proxy for the requested
    680          resource.
    681       </p>
    682       <p id="rfc.section.2.p.14">The HTTP protocol does not restrict applications to this simple challenge-response mechanism for access authentication. Additional
    683          mechanisms <em class="bcp14">MAY</em> be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying
    684          authentication information. However, such additional mechanisms are not defined by this specification.
    685       </p>
    686       <p id="rfc.section.2.p.15">Proxies <em class="bcp14">MUST</em> forward the WWW-Authenticate and Authorization headers unmodified and follow the rules found in <a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section&nbsp;4.1</a>.
    687       </p>
    688       <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="authentication.scheme.registry" href="#authentication.scheme.registry">Authentication Scheme Registry</a></h2>
    689       <p id="rfc.section.2.1.p.1">The HTTP Authentication Scheme Registry defines the name space for the authentication schemes in challenges and credentials.</p>
    690       <p id="rfc.section.2.1.p.2">Registrations <em class="bcp14">MUST</em> include the following fields:
     697      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="authentication.scheme.registry" href="#authentication.scheme.registry">Authentication Scheme Registry</a></h2>
     698      <p id="rfc.section.2.3.p.1">The HTTP Authentication Scheme Registry defines the name space for the authentication schemes in challenges and credentials.</p>
     699      <p id="rfc.section.2.3.p.2">Registrations <em class="bcp14">MUST</em> include the following fields:
    691700      </p>
    692701      <ul>
     
    694703         <li>Pointer to specification text</li>
    695704      </ul>
    696       <p id="rfc.section.2.1.p.3">Values to be added to this name space are subject to IETF review (<a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>).
    697       </p>
    698       <p id="rfc.section.2.1.p.4">The registry itself is maintained at &lt;<a href="http://www.iana.org/assignments/http-authschemes">http://www.iana.org/assignments/http-authschemes</a>&gt;.
     705      <p id="rfc.section.2.3.p.3">Values to be added to this name space are subject to IETF review (<a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>).
     706      </p>
     707      <p id="rfc.section.2.3.p.4">The registry itself is maintained at &lt;<a href="http://www.iana.org/assignments/http-authschemes">http://www.iana.org/assignments/http-authschemes</a>&gt;.
    699708      </p>
    700709      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="status.code.definitions" href="#status.code.definitions">Status Code Definitions</a></h1>
     
    722731         for the realm of the resource being requested.
    723732      </p>
    724       <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#header.authorization" class="smpl">Authorization</a> = <a href="#access.authentication.framework" class="smpl">credentials</a>
     733      <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#header.authorization" class="smpl">Authorization</a> = <a href="#challenge.and.response" class="smpl">credentials</a>
    725734</pre><p id="rfc.section.4.1.p.3">If a request is authenticated and a realm specified, the same credentials <em class="bcp14">SHOULD</em> be valid for all other requests within this realm (assuming that the authentication scheme itself does not require otherwise,
    726735         such as credentials that vary according to a challenge value or using synchronized clocks).
     
    745754         to the proxy for this effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response.
    746755      </p>
    747       <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.2"></span>  <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> = 1#<a href="#access.authentication.framework" class="smpl">challenge</a>
     756      <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.2"></span>  <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> = 1#<a href="#challenge.and.response" class="smpl">challenge</a>
    748757</pre><p id="rfc.section.4.2.p.3">Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to the current connection and <em class="bcp14">SHOULD NOT</em> be passed on to downstream clients. However, an intermediate proxy might need to obtain its own credentials by requesting
    749758         them from the downstream client, which in some circumstances will appear as if the proxy is forwarding the Proxy-Authenticate
     
    757766         the resource being requested.
    758767      </p>
    759       <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.3"></span>  <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> = <a href="#access.authentication.framework" class="smpl">credentials</a>
     768      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.3"></span>  <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> = <a href="#challenge.and.response" class="smpl">credentials</a>
    760769</pre><p id="rfc.section.4.3.p.3">Unlike Authorization, the Proxy-Authorization header field applies only to the next outbound proxy that demanded authentication
    761770         using the Proxy-Authenticate field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed
     
    769778         applicable to the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages.
    770779      </p>
    771       <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.4"></span>  <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> = 1#<a href="#access.authentication.framework" class="smpl">challenge</a>
     780      <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.4"></span>  <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> = 1#<a href="#challenge.and.response" class="smpl">challenge</a>
    772781</pre><p id="rfc.section.4.4.p.3">User agents are advised to take special care in parsing the WWW-Authenticate field value as it might contain more than one
    773782         challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a
     
    776785      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    777786      <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="authentication.scheme.registration" href="#authentication.scheme.registration">Authenticaton Scheme Registry</a></h2>
    778       <p id="rfc.section.5.1.p.1">The registration procedure for HTTP Authentication Schemes is defined by <a href="#authentication.scheme.registry" title="Authentication Scheme Registry">Section&nbsp;2.1</a> of this document.
     787      <p id="rfc.section.5.1.p.1">The registration procedure for HTTP Authentication Schemes is defined by <a href="#authentication.scheme.registry" title="Authentication Scheme Registry">Section&nbsp;2.3</a> of this document.
    779788      </p>
    780789      <p id="rfc.section.5.1.p.2">The HTTP Method Authentication Scheme shall be created at &lt;<a href="http://www.iana.org/assignments/http-authschemes">http://www.iana.org/assignments/http-authschemes</a>&gt;.
     
    969978 ] )
    970979
    971 <a href="#access.authentication.framework" class="smpl">auth-param</a> = token "=" ( token / quoted-string )
    972 <a href="#access.authentication.framework" class="smpl">auth-scheme</a> = token
    973 
    974 <a href="#access.authentication.framework" class="smpl">challenge</a> = auth-scheme 1*SP *( "," OWS ) auth-param *( OWS "," [ OWS
     980<a href="#challenge.and.response" class="smpl">auth-param</a> = token "=" ( token / quoted-string )
     981<a href="#challenge.and.response" class="smpl">auth-scheme</a> = token
     982
     983<a href="#challenge.and.response" class="smpl">challenge</a> = auth-scheme 1*SP *( "," OWS ) auth-param *( OWS "," [ OWS
    975984 auth-param ] )
    976 <a href="#access.authentication.framework" class="smpl">credentials</a> = auth-scheme ( token / quoted-string / [ ( "," /
     985<a href="#challenge.and.response" class="smpl">credentials</a> = auth-scheme ( token / quoted-string / [ ( "," /
    977986 auth-param ) *( OWS "," [ OWS auth-param ] ) ] )
    978987
     
    10881097            </li>
    10891098            <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul>
    1090                   <li><tt>auth-param</tt>&nbsp;&nbsp;<a href="#rfc.iref.a.2"><b>2</b></a></li>
    1091                   <li><tt>auth-scheme</tt>&nbsp;&nbsp;<a href="#rfc.iref.a.1"><b>2</b></a></li>
    1092                   <li>Authorization header field&nbsp;&nbsp;<a href="#rfc.xref.header.authorization.1">2</a>, <a href="#rfc.xref.header.authorization.2">3.1</a>, <a href="#rfc.iref.a.3"><b>4.1</b></a>, <a href="#rfc.xref.header.authorization.3">5.3</a></li>
     1099                  <li><tt>auth-param</tt>&nbsp;&nbsp;<a href="#rfc.iref.a.2"><b>2.1</b></a></li>
     1100                  <li><tt>auth-scheme</tt>&nbsp;&nbsp;<a href="#rfc.iref.a.1"><b>2.1</b></a></li>
     1101                  <li>Authorization header field&nbsp;&nbsp;<a href="#rfc.xref.header.authorization.1">2.1</a>, <a href="#rfc.xref.header.authorization.2">3.1</a>, <a href="#rfc.iref.a.3"><b>4.1</b></a>, <a href="#rfc.xref.header.authorization.3">5.3</a></li>
    10931102               </ul>
    10941103            </li>
    10951104            <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul>
    1096                   <li><tt>challenge</tt>&nbsp;&nbsp;<a href="#rfc.iref.c.1"><b>2</b></a></li>
    1097                   <li><tt>credentials</tt>&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2</b></a></li>
     1105                  <li><tt>challenge</tt>&nbsp;&nbsp;<a href="#rfc.iref.c.1"><b>2.1</b></a></li>
     1106                  <li><tt>credentials</tt>&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    10981107               </ul>
    10991108            </li>
     
    11121121                  <li>Header Fields&nbsp;&nbsp;
    11131122                     <ul>
    1114                         <li>Authorization&nbsp;&nbsp;<a href="#rfc.xref.header.authorization.1">2</a>, <a href="#rfc.xref.header.authorization.2">3.1</a>, <a href="#rfc.iref.h.1"><b>4.1</b></a>, <a href="#rfc.xref.header.authorization.3">5.3</a></li>
     1123                        <li>Authorization&nbsp;&nbsp;<a href="#rfc.xref.header.authorization.1">2.1</a>, <a href="#rfc.xref.header.authorization.2">3.1</a>, <a href="#rfc.iref.h.1"><b>4.1</b></a>, <a href="#rfc.xref.header.authorization.3">5.3</a></li>
    11151124                        <li>Proxy-Authenticate&nbsp;&nbsp;<a href="#rfc.xref.header.proxy-authenticate.1">3.2</a>, <a href="#rfc.iref.h.2"><b>4.2</b></a>, <a href="#rfc.xref.header.proxy-authenticate.2">5.3</a></li>
    11161125                        <li>Proxy-Authorization&nbsp;&nbsp;<a href="#rfc.xref.header.proxy-authorization.1">3.2</a>, <a href="#rfc.iref.h.3"><b>4.3</b></a>, <a href="#rfc.xref.header.proxy-authorization.2">5.3</a></li>
     
    11211130            </li>
    11221131            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    1123                   <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.2</a>, <a href="#rfc.xref.Part1.2">1.2.1</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">4.2</a>, <a href="#rfc.xref.Part1.8">4.4</a>, <a href="#Part1"><b>8.1</b></a><ul>
     1132                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.2</a>, <a href="#rfc.xref.Part1.2">1.2.1</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">2.2</a>, <a href="#rfc.xref.Part1.7">4.2</a>, <a href="#rfc.xref.Part1.8">4.4</a>, <a href="#Part1"><b>8.1</b></a><ul>
    11241133                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.2</a></li>
    11251134                        <li><em>Section 1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.2.1</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a></li>
    1126                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">4.2</a>, <a href="#rfc.xref.Part1.8">4.4</a></li>
     1135                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">2.2</a>, <a href="#rfc.xref.Part1.7">4.2</a>, <a href="#rfc.xref.Part1.8">4.4</a></li>
    11271136                     </ul>
    11281137                  </li>
     
    11361145            </li>
    11371146            <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul>
    1138                   <li><tt>realm</tt>&nbsp;&nbsp;<a href="#rfc.iref.r.1"><b>2</b></a></li>
    1139                   <li><tt>realm-value</tt>&nbsp;&nbsp;<a href="#rfc.iref.r.2"><b>2</b></a></li>
     1147                  <li><tt>realm</tt>&nbsp;&nbsp;<a href="#rfc.iref.r.1"><b>2.2</b></a></li>
     1148                  <li><tt>realm-value</tt>&nbsp;&nbsp;<a href="#rfc.iref.r.2"><b>2.2</b></a></li>
    11401149                  <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>8.1</b></a></li>
    11411150                  <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">7</a>, <a href="#RFC2616"><b>8.2</b></a>, <a href="#rfc.xref.RFC2616.3">C.1</a></li>
    11421151                  <li><em>RFC2617</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2617.1">1</a>, <a href="#rfc.xref.RFC2617.2">1</a>, <a href="#RFC2617"><b>8.2</b></a></li>
    11431152                  <li><em>RFC3864</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3864.1">5.3</a>, <a href="#RFC3864"><b>8.2</b></a></li>
    1144                   <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">2.1</a>, <a href="#RFC5226"><b>8.2</b></a><ul>
    1145                         <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">2.1</a></li>
     1153                  <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">2.3</a>, <a href="#RFC5226"><b>8.2</b></a><ul>
     1154                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">2.3</a></li>
    11461155                     </ul>
    11471156                  </li>
  • draft-ietf-httpbis/latest/p7-auth.xml

    r1343 r1344  
    285285
    286286<section title="Access Authentication Framework" anchor="access.authentication.framework">
     287
     288<section title="Challenge and Response" anchor="challenge.and.response">
    287289  <x:anchor-alias value="auth-scheme"/>
    288290  <x:anchor-alias value="auth-param"/>
     
    306308   to challenge the authorization of a user agent. This response &MUST;
    307309   include a WWW-Authenticate header field containing at least one
    308    challenge applicable to the requested resource. The 407 (Proxy
    309    Authentication Required) response message is used by a proxy to
     310   challenge applicable to the requested resource.
     311</t>
     312<t>   
     313   The 407 (Proxy Authentication Required) response message is used by a proxy to
    310314   challenge the authorization of a client and &MUST; include a Proxy-Authenticate
    311315   header field containing at least one challenge
     
    328332     <x:h>Note:</x:h> Many browsers fail to parse challenges containing unknown
    329333     schemes. A workaround for this problem is to list well-supported schemes
    330      (such as "basic") first.
     334     (such as "basic") first.<!-- see http://greenbytes.de/tech/tc/httpauth/#multibasicunknown2 -->
    331335  </t>
    332336</x:note>
     337<t>
     338   A user agent that wishes to authenticate itself with an origin server
     339   &mdash; usually, but not necessarily, after receiving a 401 (Unauthorized)
     340   &mdash; &MAY; do so by including an Authorization header field with the
     341   request.
     342</t>
     343<t>   
     344   A client that wishes to authenticate itself with a proxy &mdash; usually,
     345   but not necessarily, after receiving a 407 (Proxy Authentication Required)
     346   &mdash; &MAY; do so by including a Proxy-Authorization header field with the
     347   request.
     348</t>
     349<t>   
     350   Both the Authorization field value and the Proxy-Authorization field value
     351   consist of credentials containing the authentication information of the
     352   client for the realm of the resource being requested. The user agent &MUST;
     353   choose to use one of the challenges with the strongest auth-scheme it
     354   understands and request credentials from the user based upon that challenge.
     355</t>
     356<figure><artwork type="abnf2616"><iref item="credentials" primary="true"/>
     357  <x:ref>credentials</x:ref> = <x:ref>auth-scheme</x:ref> ( <x:ref>token</x:ref>
     358                            / <x:ref>quoted-string</x:ref>
     359                            / #<x:ref>auth-param</x:ref> )
     360</artwork></figure>
     361<t>
     362   If the origin server does not wish to accept the credentials sent
     363   with a request, it &SHOULD; return a 401 (Unauthorized) response. The
     364   response &MUST; include a WWW-Authenticate header field containing at
     365   least one (possibly new) challenge applicable to the requested
     366   resource.
     367</t>
     368<t>
     369   If a proxy does not accept the credentials sent with a
     370   request, it &SHOULD; return a 407 (Proxy Authentication Required). The
     371   response &MUST; include a Proxy-Authenticate header field containing a
     372   (possibly new) challenge applicable to the proxy for the requested
     373   resource.
     374</t>
     375<t>
     376   The HTTP protocol does not restrict applications to this simple
     377   challenge-response mechanism for access authentication. Additional
     378   mechanisms &MAY; be used, such as encryption at the transport level or
     379   via message encapsulation, and with additional header fields
     380   specifying authentication information. However, such additional
     381   mechanisms are not defined by this specification.
     382</t>
     383<t>
     384   Proxies &MUST; forward the WWW-Authenticate and Authorization headers
     385   unmodified and follow the rules found in <xref target="header.authorization"/>.
     386</t>
     387</section>
     388
     389<section title="Protection Space (Realm)" anchor="protection.space">
    333390<t>
    334391   The authentication parameter realm is defined for all authentication
     
    354411</t>
    355412<t>
    356    A user agent that wishes to authenticate itself with an origin
    357    server &mdash; usually, but not necessarily, after receiving a 401
    358    (Unauthorized) &mdash; &MAY; do so by including an Authorization header field
    359    with the request. A client that wishes to authenticate itself with a
    360    proxy &mdash; usually, but not necessarily, after receiving a 407 (Proxy
    361    Authentication Required) &mdash; &MAY; do so by including a Proxy-Authorization
    362    header field with the request.  Both the Authorization
    363    field value and the Proxy-Authorization field value consist of
    364    credentials containing the authentication information of the client
    365    for the realm of the resource being requested. The user agent &MUST;
    366    choose to use one of the challenges with the strongest auth-scheme it
    367    understands and request credentials from the user based upon that
    368    challenge.
    369 </t>
    370 <figure><artwork type="abnf2616"><iref item="credentials" primary="true"/>
    371   <x:ref>credentials</x:ref> = <x:ref>auth-scheme</x:ref> ( <x:ref>token</x:ref>
    372                             / <x:ref>quoted-string</x:ref>
    373                             / #<x:ref>auth-param</x:ref> )
    374 </artwork></figure>
    375 <t>
    376413   The protection space determines the domain over which credentials can
    377414   be automatically applied. If a prior request has been authorized, the
     
    382419   space cannot extend outside the scope of its server.
    383420</t>
    384 <t>
    385    If the origin server does not wish to accept the credentials sent
    386    with a request, it &SHOULD; return a 401 (Unauthorized) response. The
    387    response &MUST; include a WWW-Authenticate header field containing at
    388    least one (possibly new) challenge applicable to the requested
    389    resource. If a proxy does not accept the credentials sent with a
    390    request, it &SHOULD; return a 407 (Proxy Authentication Required). The
    391    response &MUST; include a Proxy-Authenticate header field containing a
    392    (possibly new) challenge applicable to the proxy for the requested
    393    resource.
    394 </t>
    395 <t>
    396    The HTTP protocol does not restrict applications to this simple
    397    challenge-response mechanism for access authentication. Additional
    398    mechanisms &MAY; be used, such as encryption at the transport level or
    399    via message encapsulation, and with additional header fields
    400    specifying authentication information. However, such additional
    401    mechanisms are not defined by this specification.
    402 </t>
    403 <t>
    404    Proxies &MUST; forward the WWW-Authenticate and Authorization headers
    405    unmodified and follow the rules found in <xref target="header.authorization"/>.
    406 </t>
     421</section>
    407422
    408423<section title="Authentication Scheme Registry" anchor="authentication.scheme.registry">
Note: See TracChangeset for help on using the changeset viewer.