Subject: [OAUTH-WG] realms

From: "Manger, James H" <[email-masked]>
Date: Sun, 4 Oct 2009 03:26:27 +1100

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
[email-masked]<mailto:[email-masked]>
Identity and security team — Chief Technology Office — Telstra

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 3 Oct 2009 10:23:07 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Saturday, October 03, 2009 9:26 AM
To: [email-masked]
Subject: [OAUTH-WG] realms

-> GET /realmA/

-> GET /alsoRealmA/

-> GET /realmB/

…

   schemes:

   different realms.
…

   realm

     password to use.

…

James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Sun, 4 Oct 2009 11:55:47 +1100

> 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.

Opening an HTTPbis issue sounds ok -- though I am not sure which specific aspects need clarifying as I am not certain that the RFC 2617 spec text was the (reasonably direct) source of the different understandings.

James Manger

---

From: Dan Winship <[email-masked]>
Date: Sun, 04 Oct 2009 10:11:49 -0400

On 10/03/2009 12:26 PM, Manger, James H wrote:
> The only defined operation with a realm is to compare the realm values
> from different 401 responses from the same origin (scheme/host/port).

Although it's not really a "defined" operation, realms are also often
used in the UI by web browsers when presenting the password dialog; "The
web site has requested a password for '$realm'" or something.

> Once a client has learnt the realm for one resource it is reasonable to
> assume any sub-resource has the same realm.

This is not generically true, it's just something Basic and Digest both
explicitly add to the generic realm semantics. If it was convenient for
OAuth, you could say that the 401 response applies only to the exact URI
that it was returned from, and user agents should not attempt to reuse
the same authentication for any other URIs. Or you could do something
like Digest's "domain" parameter, giving an explicit list of other URIs
where the same auth can be reused.

-- Dan