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
of [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 at team.telstra.com
Identity and security team
— Chief Technology Office
— Telstra