RE: realms

Thanks James. This is very useful.

I think we should open an issue (unless there is already one) with HTTPbis about this given the current state of P7 and the opportunity to clarify this.

EHL

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Manger, James H
Sent: Saturday, October 03, 2009 9:26 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] realms

Realms have been discussed a lot this week. There are different opinions about their worth, but there also seem to be different understandings about the technical details as well which is hindering progress. Below is my understanding.

RFC 2617 “HTTP Authentication” defines a realm parameter.

A realm is required in any WWW-Authentication header returned by a server (usually in a 401 response).

A realm is a string. It does not have to be a URI, and usually isn’t in my experience.

The only defined operation with a realm is to compare the realm values from different 401 responses from the same origin (scheme/host/port). If they match then the same authentication credentials should work for both resources.

A specific HTTP authentication scheme can add it own additional semantics to realm.

The same realm value from two different servers does not imply anything. It certainly does not imply credentials should be shared across the domains.

Once a client has learnt the realm for one resource it is reasonable to assume any sub-resource has the same realm. You should NOT assume non-sub-resources are in the same realm. Consequently, it is sensible for a client to proactively authenticate requests to sub-resources (without waiting for a 401 to an unauthenticated request).

Web browsers support realms.

I tested Internet Explorer 8 and Firefox 3.5 by visiting 4 URIs in turn within the same browser session. All four required HTTP BASIC authentication. Three specified a realm of “AAAA”, one specified a realm of “BBBB”. IE8 and FF3.5 both behaved the same way.
1.  http://example.net/realmA/

2.  http://example.net /alsoRealmA/
3.  http://example.net /realmB/
4.  http://different.net/realmA/


1. Visiting /realmA/ resulted in a 401 that triggered a browser prompt for a username/password, then the browser retried the request successfully with an Authorization header.
2. The Authorization header was NOT sent when subsequently visting /alsoRealmA/. However, there was NO PROMPT as the 401 response had the same realm so the browser automatically retried the request with the Authorization header.
3. Similarly, the Authorization header was NOT sent when subsequently visting /realmB/. After this request there was ANOTHER PROMPT for a username/password — because the realm was different.
4. Visiting the /realmA/ at a different host (actually the same web server, same IP address, just a different domain name) triggered ANOTHER PROMPT. The browser recognized that the same realm value is irrelevant if the origin is different.



-> GET /realmA/
<- 401 … WWW-Authenticate: BASIC realm=”AAAA”
Browser prompts for username/password
-> GET /realmA/ … Authorization: Zm9vOmJhcg==
<- 200

-> GET /alsoRealmA/
<- 401 … WWW-Authenticate: BASIC realm=”AAAA”
No browser prompt
-> GET /alsoRealmA/ … Authorization: Zm9vOmJhcg==
<- 200

-> GET /realmB/
<- 401 … WWW-Authenticate: BASIC realm=”BBBB”
Browser prompts for username/password
-> GET /realmB/ … Authorization: z39vOmJhwQ==
<- 200

-> GET /realmA/ … Host: different.net
<- 401 … WWW-Authenticate: BASIC realm=”AAAA”
Browser prompts for username/password
-> GET /realmA/ … Authorization: Zm9vOmJhcg==
<- 200


Selected text from RFC 2617 “HTTP Authentication”:



1.2 Access Authentication Framework

…

   The authentication parameter realm is defined for all authentication

   schemes:



      realm       = "realm" "=" realm-value

      realm-value = quoted-string



   The realm directive (case-insensitive) is required for all

   authentication schemes that issue a challenge. The realm value

   (case-sensitive), in combination with the canonical root URL (the

   absoluteURI for the server whose abs_path is empty; see section 5.1.2<http://tools.ietf.org/rfcmarkup?doc=2617#section-5.1.2>

   of [2<http://tools.ietf.org/rfcmarkup?doc=2617#ref-2>]) 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. Note that

   there may be multiple challenges with the same auth-scheme but

   different realms.
…

2 Basic Authentication Scheme

   …The realm value should be considered an opaque string
   which can only be compared for equality with other realms on that
   server.
…
3 Digest Access Authentication Scheme
…

       digest-challenge  = 1#( realm | [ domain ] | nonce |…


   realm

     A string to be displayed to users so they know which username and

     password to use.

…

       digest-response  = 1#( username | realm | nonce | digest-uri…





James Manger
James.H.Manger@team.telstra.com<mailto:James.H.Manger@team.telstra.com>
Identity and security team — Chief Technology Office — Telstra