4. Definitionen der Header-Felder (Header Field Definitions)

Dieser Abschnitt definiert die Syntax und Semantik der Header-Felder, die mit dem HTTP-Authentifizierungsrahmenwerk zusammenhängen.

4.1 WWW-Authenticate

Das Header-Feld "WWW-Authenticate" gibt die Authentifizierungsschemata und -parameter an, die auf die Zielressource anwendbar sind.

WWW-Authenticate = 1#challenge

Ein Server, der eine 401-(Unauthorized-)Antwort erzeugt, muss ein Header-Feld WWW-Authenticate senden, das mindestens eine Challenge enthält (MUST). Ein Server kann ein Header-Feld WWW-Authenticate in anderen Antwortnachrichten erzeugen, um anzuzeigen, dass die Bereitstellung von Anmeldedaten (oder anderen Anmeldedaten) die Antwort beeinflussen könnte (MAY).

Ein Proxy, der eine Antwort weiterleitet, darf keine WWW-Authenticate-Felder in dieser Antwort verändern (MUST NOT).

Benutzeragenten wird geraten, beim Analysieren des Feldwerts besondere Sorgfalt walten zu lassen, da er mehr als eine Challenge enthalten kann und jede Challenge eine kommagetrennte Liste von Authentifizierungsparametern enthalten kann. Darüber hinaus kann das Header-Feld selbst mehrfach vorkommen.

Zum Beispiel:

WWW-Authenticate: Newauth realm="apps", type=1,
                  title="Login to \"apps\"", Basic realm="simple"

Dieses Header-Feld enthält zwei Challenges: eine für das Schema "Newauth" mit einem realm-Wert von "apps" und zwei zusätzlichen Parametern "type" und "title", und eine weitere für das Schema "Basic" mit einem realm-Wert von "simple".

Hinweis: Die Grammatikproduktion challenge verwendet ebenfalls die Listensyntax. Daher kann eine Folge von Komma, Leerraum und Komma entweder als auf die vorangehende Challenge bezogen oder als leerer Eintrag in der Liste der Challenges betrachtet werden. In der Praxis wirkt sich diese Mehrdeutigkeit nicht auf die Semantik des Header-Feldwerts aus und ist somit harmlos.

4.2 Authorization

Das Header-Feld "Authorization" erlaubt es einem Benutzeragenten, sich gegenüber einem Ursprungsserver zu authentifizieren — üblicherweise, aber nicht notwendigerweise, nachdem er eine 401-(Unauthorized-)Antwort empfangen hat. Sein Wert besteht aus Anmeldedaten, die die Authentifizierungsinformationen des Benutzeragenten für den Realm der angeforderten Ressource enthalten.

Authorization = credentials

Wenn eine Anfrage authentifiziert und ein Realm angegeben ist, wird angenommen, dass dieselben Anmeldedaten für alle anderen Anfragen innerhalb dieses Realms gültig sind (vorausgesetzt, das Authentifizierungsschema selbst verlangt nichts anderes, etwa Anmeldedaten, die je nach Challenge-Wert variieren oder synchronisierte Uhren verwenden).

Ein Proxy, der eine Anfrage weiterleitet, darf keine Authorization-Felder in dieser Anfrage verändern (MUST NOT). Einzelheiten zu und Anforderungen an die Behandlung des Feldes Authorization durch HTTP-Zwischenspeicher finden Sie in Abschnitt 3.2 von [RFC7234].

4.3 Proxy-Authenticate

Das Header-Feld "Proxy-Authenticate" besteht aus mindestens einer Challenge, die die Authentifizierungsschemata und -parameter angibt, die für diese effektive Anfrage-URI (Abschnitt 5.5 von [RFC7230]) auf den Proxy anwendbar sind. Ein Proxy muss in jeder 407-(Proxy Authentication Required-)Antwort, die er erzeugt, mindestens ein Header-Feld Proxy-Authenticate senden (MUST).

Proxy-Authenticate = 1#challenge

Anders als WWW-Authenticate gilt das Header-Feld Proxy-Authenticate nur für den nächsten ausgehenden Client in der Antwortkette. Der Grund dafür ist, dass wahrscheinlich nur der Client, der einen bestimmten Proxy ausgewählt hat, über die für die Authentifizierung erforderlichen Anmeldedaten verfügt. Wenn jedoch mehrere Proxys innerhalb derselben Verwaltungsdomäne verwendet werden, etwa Büro- und regionale Zwischenspeicher-Proxys innerhalb eines großen Unternehmensnetzes, ist es üblich, dass Anmeldedaten vom Benutzeragenten erzeugt und durch die Hierarchie weitergegeben werden, bis sie verbraucht sind. In einer solchen Konfiguration wird es daher so erscheinen, als würde Proxy-Authenticate weitergeleitet, weil jeder Proxy dieselbe Challenge-Menge sendet.

Beachten Sie, dass die Analyseüberlegungen für WWW-Authenticate auch für dieses Header-Feld gelten; Einzelheiten finden Sie in Abschnitt 4.1.

4.4 Proxy-Authorization

Das Header-Feld "Proxy-Authorization" erlaubt es dem Client, sich (oder seinen Benutzer) gegenüber einem Proxy zu identifizieren, der eine Authentifizierung verlangt. Sein Wert besteht aus Anmeldedaten, die die Authentifizierungsinformationen des Clients für den Proxy und/oder den Realm der angeforderten Ressource enthalten.

Proxy-Authorization = credentials

Anders als Authorization gilt das Header-Feld Proxy-Authorization nur für den nächsten eingehenden Proxy, der unter Verwendung des Feldes Proxy-Authenticate eine Authentifizierung verlangt hat. Wenn mehrere Proxys in einer Kette verwendet werden, wird das Header-Feld Proxy-Authorization von dem ersten eingehenden Proxy verbraucht, der den Empfang von Anmeldedaten erwartete. Ein Proxy kann die Anmeldedaten aus der Client-Anfrage an den nächsten Proxy weitergeben, wenn dies der Mechanismus ist, mit dem die Proxys eine gegebene Anfrage gemeinsam authentifizieren (MAY).

---