Changeset 998 for draft-ietf-httpbis/latest/p7-auth.xml
- Timestamp:
- 13/09/10 14:47:24 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p7-auth.xml
r994 r998 19 19 <!ENTITY basic-rules "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 20 20 <!ENTITY effective-request-uri "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 21 <!ENTITY end-to-end.and-hop-by-hop "<xref target='Part1' x:rel='#end-to-end.and.hop-by-hop.header-fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 21 22 <!ENTITY shared-and-non-shared-caches "<xref target='Part6' x:rel='#shared.and.non-shared.caches' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 22 23 ]> … … 207 208 <section title="Introduction" anchor="introduction"> 208 209 <t> 209 This document defines HTTP/1.1 access control and authentication. Right now it 210 includes the extracted relevant sections of 211 <xref target="RFC2616" x:fmt="none">RFC 2616</xref> with only minor changes. 212 The intention is to move the general framework for HTTP authentication here, 213 as currently specified in <xref target="RFC2617"/>, and allow the individual 214 authentication mechanisms to be defined elsewhere. This introduction will 215 be rewritten when that occurs. 210 This document defines HTTP/1.1 access control and authentication. It 211 includes the relevant parts of <xref target="RFC2616" x:fmt="none">RFC 2616</xref> 212 with only minor changes, plus the general framework for HTTP authentication, 213 as previously defined in "HTTP Authentication: Basic and Digest Access 214 Authentication" (<xref target="RFC2617"/>). 216 215 </t> 217 216 <t> 218 217 HTTP provides several &OPTIONAL; challenge-response authentication 219 mechanisms which can be used by a server to challenge a client 220 request and by a client to provide authentication information. The 221 general framework for access authentication, and the specification of 222 "basic" and "digest" authentication, are specified in "HTTP 223 Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. This 224 specification adopts the definitions of "challenge" and "credentials" 225 from that specification. 218 mechanisms which can be used by a server to challenge a client request and 219 by a client to provide authentication information. The "basic" and "digest" 220 authentication schemes continue to be specified in 221 <xref target="RFC2617" x:fmt="none">RFC 2617</xref>. 226 222 </t> 227 223 … … 250 246 <x:anchor-alias value="OCTET"/> 251 247 <x:anchor-alias value="VCHAR"/> 248 <x:anchor-alias value="SP"/> 252 249 <x:anchor-alias value="WSP"/> 253 250 <t> … … 269 266 270 267 <section title="Core Rules" anchor="core.rules"> 271 <x:anchor-alias value="OWS"/> 272 <t> 273 The core rules below are defined in &basic-rules;: 268 <x:anchor-alias value="quoted-string"/> 269 <x:anchor-alias value="token"/> 270 <x:anchor-alias value="OWS"/> 271 <t> 272 The core rules below are defined in &basic-rules;: 274 273 </t> 275 274 <figure><artwork type="abnf2616"> 276 <x:ref>OWS</x:ref> = <OWS, defined in &basic-rules;> 275 <x:ref>quoted-string</x:ref> = <quoted-string, defined in &basic-rules;> 276 <x:ref>token</x:ref> = <token, defined in &basic-rules;> 277 <x:ref>OWS</x:ref> = <OWS, defined in &basic-rules;> 277 278 </artwork></figure> 278 279 </section> 279 280 <section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies"> 280 </section> 281 </section> 282 283 <section title="Access Authentication Framework" anchor="access.authentication.framework"> 284 <x:anchor-alias value="auth-scheme"/> 285 <x:anchor-alias value="auth-param"/> 281 286 <x:anchor-alias value="challenge"/> 282 287 <x:anchor-alias value="credentials"/> 283 288 <t> 284 <x:anchor-alias value="OWS"/> 285 The ABNF rules below are defined in other specifications: 286 </t> 287 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="challenge"/><iref primary="true" item="Grammar" subitem="credentials"/> 288 <x:ref>challenge</x:ref> = <challenge, defined in <xref target="RFC2617" x:fmt="," x:sec="1.2"/>> 289 <x:ref>credentials</x:ref> = <credentials, defined in <xref target="RFC2617" x:fmt="," x:sec="1.2"/>> 289 HTTP provides a simple challenge-response authentication mechanism 290 that can be used by a server to challenge a client request and by a 291 client to provide authentication information. It uses an extensible, 292 case-insensitive token to identify the authentication scheme, 293 followed by a comma-separated list of attribute-value pairs which 294 carry the parameters necessary for achieving authentication via that 295 scheme. 296 </t> 297 <figure><artwork type="abnf2616"><iref item="auth-scheme" primary="true"/><iref item="auth-param" primary="true"/> 298 auth-scheme = token 299 auth-param = token "=" ( token / quoted-string ) 290 300 </artwork></figure> 291 </section> 292 293 </section> 294 295 </section> 296 301 <t> 302 The 401 (Unauthorized) response message is used by an origin server 303 to challenge the authorization of a user agent. This response &MUST; 304 include a WWW-Authenticate header field containing at least one 305 challenge applicable to the requested resource. The 407 (Proxy 306 Authentication Required) response message is used by a proxy to 307 challenge the authorization of a client and &MUST; include a Proxy-Authenticate 308 header field containing at least one challenge 309 applicable to the proxy for the requested resource. 310 </t> 311 <figure><artwork type="abnf2616"><iref item="challenge" primary="true"/> 312 <x:ref>challenge</x:ref> = <x:ref>auth-scheme</x:ref> 1*<x:ref>SP</x:ref> 1#<x:ref>auth-param</x:ref> 313 </artwork></figure> 314 <x:note> 315 <t> 316 <x:h>Note:</x:h> User agents will need to take special care in parsing the WWW-Authenticate 317 or Proxy-Authenticate header field value if it contains 318 more than one challenge, or if more than one WWW-Authenticate header 319 field is provided, since the contents of a challenge can itself 320 contain a comma-separated list of authentication parameters. 321 </t> 322 </x:note> 323 <t> 324 The authentication parameter realm is defined for all authentication 325 schemes: 326 </t> 327 <figure><artwork type="abnf2616"><iref item="realm" primary="true"/><iref item="realm-value" primary="true"/> 328 realm = "realm" "=" realm-value 329 realm-value = quoted-string 330 </artwork></figure> 331 <t> 332 The realm directive (case-insensitive) is required for all 333 authentication schemes that issue a challenge. The realm value 334 (case-sensitive), in combination with the canonical root URL ( 335 the scheme and authority components of the effective request URI; see <xref target="Part1" x:fmt="of" x:rel="#effective.request.uri"/>) of the server being accessed, defines the protection space. 336 These realms allow the protected resources on a server to be 337 partitioned into a set of protection spaces, each with its own 338 authentication scheme and/or authorization database. The realm value 339 is a string, generally assigned by the origin server, which can have 340 additional semantics specific to the authentication scheme. Note that 341 there can be multiple challenges with the same auth-scheme but 342 different realms. 343 </t> 344 <t> 345 A user agent that wishes to authenticate itself with an origin 346 server -- usually, but not necessarily, after receiving a 401 347 (Unauthorized) -- &MAY; do so by including an Authorization header field 348 with the request. A client that wishes to authenticate itself with a 349 proxy -- usually, but not necessarily, after receiving a 407 (Proxy 350 Authentication Required) -- &MAY; do so by including a Proxy-Authorization 351 header field with the request. Both the Authorization 352 field value and the Proxy-Authorization field value consist of 353 credentials containing the authentication information of the client 354 for the realm of the resource being requested. The user agent &MUST; 355 choose to use one of the challenges with the strongest auth-scheme it 356 understands and request credentials from the user based upon that 357 challenge. 358 </t> 359 <figure><artwork type="abnf2616"><iref item="credentials" primary="true"/> 360 <x:ref>credentials</x:ref> = <x:ref>auth-scheme</x:ref> ( <x:ref>token</x:ref> 361 / <x:ref>quoted-string</x:ref> 362 / #<x:ref>auth-param</x:ref> ) 363 </artwork></figure> 364 <x:note> 365 <t> 366 <x:h>Note:</x:h> many browsers will only recognize Basic and will require 367 that it be the first auth-scheme presented. Servers should only 368 include Basic if it is minimally acceptable.<cref>Either rephrase and add reference or drop.</cref> 369 </t> 370 </x:note> 371 <t> 372 The protection space determines the domain over which credentials can 373 be automatically applied. If a prior request has been authorized, the 374 same credentials &MAY; be reused for all other requests within that 375 protection space for a period of time determined by the 376 authentication scheme, parameters, and/or user preference. Unless 377 otherwise defined by the authentication scheme, a single protection 378 space cannot extend outside the scope of its server. 379 </t> 380 <t> 381 If the origin server does not wish to accept the credentials sent 382 with a request, it &SHOULD; return a 401 (Unauthorized) response. The 383 response &MUST; include a WWW-Authenticate header field containing at 384 least one (possibly new) challenge applicable to the requested 385 resource. If a proxy does not accept the credentials sent with a 386 request, it &SHOULD; return a 407 (Proxy Authentication Required). The 387 response &MUST; include a Proxy-Authenticate header field containing a 388 (possibly new) challenge applicable to the proxy for the requested 389 resource. 390 </t> 391 <t> 392 The HTTP protocol does not restrict applications to this simple 393 challenge-response mechanism for access authentication. Additional 394 mechanisms &MAY; be used, such as encryption at the transport level or 395 via message encapsulation, and with additional header fields 396 specifying authentication information. However, these additional 397 mechanisms are not defined by this specification. 398 </t> 399 <t> 400 Proxies &MUST; be completely transparent regarding user agent 401 authentication by origin servers. That is, they &MUST; forward the 402 WWW-Authenticate and Authorization headers untouched, and follow the 403 rules found in <xref target="header.authorization"/>. Both the Proxy-Authenticate and 404 the Proxy-Authorization header fields are hop-by-hop headers (see 405 &end-to-end.and-hop-by-hop;). 406 </t> 407 </section> 297 408 298 409 <section title="Status Code Definitions" anchor="status.code.definitions"> … … 311 422 authentication at least once, then the user &SHOULD; be presented the 312 423 representation that was given in the response, since that representation might 313 include relevant diagnostic information. HTTP access authentication 314 is explained in "HTTP Authentication: Basic and Digest Access 315 Authentication" <xref target="RFC2617"/>. 424 include relevant diagnostic information. 316 425 </t> 317 426 </section> … … 321 430 <t> 322 431 This code is similar to 401 (Unauthorized), but indicates that the 323 client mustfirst authenticate itself with the proxy. The proxy &MUST;432 client ought to first authenticate itself with the proxy. The proxy &MUST; 324 433 return a Proxy-Authenticate header field (<xref target="header.proxy-authenticate"/>) containing a 325 434 challenge applicable to the proxy for the target resource. The 326 435 client &MAY; repeat the request with a suitable Proxy-Authorization 327 header field (<xref target="header.proxy-authorization"/>). HTTP access authentication is explained 328 in "HTTP Authentication: Basic and Digest Access Authentication" 329 <xref target="RFC2617"/>. 436 header field (<xref target="header.proxy-authorization"/>). 330 437 </t> 331 438 </section> … … 355 462 </artwork></figure> 356 463 <t> 357 HTTP access authentication is described in "HTTP Authentication: 358 Basic and Digest Access Authentication" <xref target="RFC2617"/>. If a request is 464 If a request is 359 465 authenticated and a realm specified, the same credentials &SHOULD; 360 466 be valid for all other requests within this realm (assuming that … … 411 517 </artwork></figure> 412 518 <t> 413 The HTTP access authentication process is described in "HTTP 414 Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. Unlike 415 WWW-Authenticate, the Proxy-Authenticate header field applies only to 519 Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to 416 520 the current connection and &SHOULD-NOT; be passed on to downstream 417 521 clients. However, an intermediate proxy might need to obtain its own … … 440 544 </artwork></figure> 441 545 <t> 442 The HTTP access authentication process is described in "HTTP 443 Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. Unlike 444 Authorization, the Proxy-Authorization header field applies only to 546 Unlike Authorization, the Proxy-Authorization header field applies only to 445 547 the next outbound proxy that demanded authentication using the Proxy-Authenticate 446 548 field. When multiple proxies are used in a chain, the … … 469 571 </artwork></figure> 470 572 <t> 471 The HTTP access authentication process is described in "HTTP 472 Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. User 473 agents are advised to take special care in parsing the WWW-Authenticate 573 User agents are advised to take special care in parsing the WWW-Authenticate 474 574 field value as it might contain more than one challenge, 475 575 or if more than one WWW-Authenticate header field is provided, the … … 597 697 <section title="Acknowledgments" anchor="ack"> 598 698 <t> 599 <cref anchor="acks">TBD.</cref> 699 This specification takes over the definition of the HTTP Authentication 700 Framework, previously defined in <xref target="RFC2616" x:fmt="none">RFC 2617</xref>. We thank to John Franks, 701 Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence, 702 Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for their work 703 on that specification. 704 </t> 705 <t> 706 <cref anchor="acks">HTTPbis acknowledgements.</cref> 600 707 </t> 601 708 </section> … … 710 817 <seriesInfo name="BCP" value="14"/> 711 818 <seriesInfo name="RFC" value="2119"/> 712 </reference>713 714 <reference anchor="RFC2617">715 <front>716 <title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title>717 <author initials="J." surname="Franks" fullname="John Franks">718 <organization>Northwestern University, Department of Mathematics</organization>719 <address><email>john@math.nwu.edu</email></address>720 </author>721 <author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker">722 <organization>Verisign Inc.</organization>723 <address><email>pbaker@verisign.com</email></address>724 </author>725 <author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler">726 <organization>AbiSource, Inc.</organization>727 <address><email>jeff@AbiSource.com</email></address>728 </author>729 <author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence">730 <organization>Agranat Systems, Inc.</organization>731 <address><email>lawrence@agranat.com</email></address>732 </author>733 <author initials="P.J." surname="Leach" fullname="Paul J. Leach">734 <organization>Microsoft Corporation</organization>735 <address><email>paulle@microsoft.com</email></address>736 </author>737 <author initials="A." surname="Luotonen" fullname="Ari Luotonen">738 <organization>Netscape Communications Corporation</organization>739 </author>740 <author initials="L." surname="Stewart" fullname="Lawrence C. Stewart">741 <organization>Open Market, Inc.</organization>742 <address><email>stewart@OpenMarket.com</email></address>743 </author>744 <date month="June" year="1999"/>745 </front>746 <seriesInfo name="RFC" value="2617"/>747 819 </reference> 748 820 … … 808 880 </reference> 809 881 882 <reference anchor="RFC2617"> 883 <front> 884 <title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title> 885 <author initials="J." surname="Franks" fullname="John Franks"> 886 <organization>Northwestern University, Department of Mathematics</organization> 887 <address><email>john@math.nwu.edu</email></address> 888 </author> 889 <author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker"> 890 <organization>Verisign Inc.</organization> 891 <address><email>pbaker@verisign.com</email></address> 892 </author> 893 <author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler"> 894 <organization>AbiSource, Inc.</organization> 895 <address><email>jeff@AbiSource.com</email></address> 896 </author> 897 <author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence"> 898 <organization>Agranat Systems, Inc.</organization> 899 <address><email>lawrence@agranat.com</email></address> 900 </author> 901 <author initials="P.J." surname="Leach" fullname="Paul J. Leach"> 902 <organization>Microsoft Corporation</organization> 903 <address><email>paulle@microsoft.com</email></address> 904 </author> 905 <author initials="A." surname="Luotonen" fullname="Ari Luotonen"> 906 <organization>Netscape Communications Corporation</organization> 907 </author> 908 <author initials="L." surname="Stewart" fullname="Lawrence C. Stewart"> 909 <organization>Open Market, Inc.</organization> 910 <address><email>stewart@OpenMarket.com</email></address> 911 </author> 912 <date month="June" year="1999"/> 913 </front> 914 <seriesInfo name="RFC" value="2617"/> 915 </reference> 916 810 917 <reference anchor='RFC3864'> 811 918 <front> … … 856 963 challenge ] ) 857 964 858 <x:ref>challenge</x:ref> = <challenge, defined in [RFC2617], Section 1.2> 859 <x:ref>credentials</x:ref> = <credentials, defined in [RFC2617], Section 1.2> 965 <x:ref>auth-param</x:ref> = token "=" ( token / quoted-string ) 966 <x:ref>auth-scheme</x:ref> = token 967 968 <x:ref>challenge</x:ref> = auth-scheme 1*SP *( "," OWS ) auth-param *( OWS "," [ OWS 969 auth-param ] ) 970 <x:ref>credentials</x:ref> = auth-scheme ( token / quoted-string / [ ( "," / 971 auth-param ) *( OWS "," [ OWS auth-param ] ) ] ) 972 973 <x:ref>quoted-string</x:ref> = <quoted-string, defined in [Part1], Section 1.2.2> 974 975 realm = "realm=" realm-value 976 realm-value = quoted-string 977 978 <x:ref>token</x:ref> = <token, defined in [Part1], Section 1.2.2> 860 979 </artwork> 861 980 </figure> … … 865 984 ; Proxy-Authorization defined but not used 866 985 ; WWW-Authenticate defined but not used 986 ; realm defined but not used 867 987 </artwork></figure></section> 868 988 <?ENDINC p7-auth.abnf-appendix ?> … … 993 1113 <section title="Since draft-ietf-httpbis-p7-auth-11" anchor="changes.since.11"> 994 1114 <t> 995 None yet. 1115 Closed issues: 1116 <list style="symbols"> 1117 <t> 1118 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/195"/>: 1119 "auth-param syntax" 1120 </t> 1121 <t> 1122 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/237"/>: 1123 "absorbing the auth framework from 2617" 1124 </t> 1125 </list> 996 1126 </t> 997 1127 </section>
Note: See TracChangeset
for help on using the changeset viewer.