In der Regel werden geschäftsrelevante und sehr vertrauliche Daten verarbeitet. Der Zugang hierzu muss daher gut gesichert werden, was mittels verschiedener Techniken der Zugangskontrolle erreicht werden kann (Web-Authentication). Wir unterstützen für einkommende Daten die Methoden/Schemata "Basic" und "Digest". In beiden Fällen kann sowohl in einem HTTP-Kanal, als auch im Profil selbst ein Benutzer-/Passwort-Paar hinterlegt werden. Details dazu finden Sie in der Online-Hilfe.

Für ausgehende Verbindungen werden, neben den bereits oben genannten Methoden, zudem noch OAuth in den Versionen 1 und 2, NTLM und Client-Zertifikate unterstützt.

Grundsätzlich sieht der Workflow für die Authentifizierung wie folgt aus:

Der Client sendet eine Anfrage ohne Anmeldecredentials.
Der Server bemerkt die fehlenden Credentials und sendet einen Statuscode (HTTP 401 - Unauthorized), sowie einen HTTP-Header (WWW-Authenticate), in dem die zu verwendende Methode angegeben ist, zurück (Challenge).
Der Client liest den zurückerhaltenen Header aus (darin ist die Authentifizierungsmethode angegeben), z. B. WWW-Authenticate: Basic realm="RealmName" (Authentifizierung nach Basic-Verfahren).
Der Client verwendet die hinterlegten Credentials, um diese korrekt zu setzen, wenn möglich.

Nachfolgend finden Sie eine Übersicht der Methoden und eine ausführliche Beschreibung finden Sie unter https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization.

Basic

Beim Basic-Verfahren werden Username und Passwort in der Form Username:Passwort mit dem Base64-Verfahren kodiert und anschließend als HTTP-Header in folgender Form gesetzt:

Authorization: Basic d2lraTpwZWRpYQ==

Wichtig ist, dass Basic in der Form vorhanden sein muss. Der hinterlegte String bedeutet dekodiert wiki:pedia. Somit handelt es sich hier um Username:wiki und Passwort:pedia. Zum Kodieren/Dekodieren von Base64-Strings können Sie unser internes Zusatztool Passwort erzeugen in der Admin-Konsole verwenden.

Wichtiger Hinweis: Basic überträgt die Credentials unverschlüsselt im Header, daher sollte es nur in Verbindung mit HTTPS eingesetzt werden, ansonsten kann ein Angreifer die Zugangsdaten problemlos abgreifen.

Digest

Digest ist sicherer als Basic, da hier die Credentials nicht direkt übertragen werden. Vielmehr sendet der Client stattdessen die Prüfsumme als MD5-Hash aus einer Kombination von Benutzername, Passwort, Nonce und Realm an den Server. Da MD5 mittlerweile nicht mehr sicher ist, gilt es auch hier, die Verbindung über HTTPS zu setzen. Es gibt weitere im Standard enthaltene Möglichkeiten neuere Digest-Methoden, wie SHA256, einzusetzen, dennoch muss man davon ausgehen, dass nicht alle Clients diese implementieren.

OAuth 2.0

Bei den Methoden Basic und Digest werden im Prinzip immer Credentials benötigt, die unter Umständen höhere Berechtigungen besitzen, als benötigt. Das gezielte Erteilen bzw. Entziehen von Berechtigungen ist mit diesen Methoden nicht möglich, was einige Nachteile mit sich bringt:

Wenn der Benutzer beispielsweise sein Kennwort ändert, funktioniert der konfigurierte Zugriff nicht mehr.
Möchte man den Zugriff auf eine Seite (Ressource) verweigern, ist das nicht einfach möglich.
Man kann keinen zeitlich begrenzten Zugriff erteilen.
Die Zugangsdaten können einem Unberechtigten in die Hände fallen, mit allen Konsequenzen die sich daraus ergeben.

Daher empfehlen wir den Ansatz, nicht die User-Credentials, sondern vielmehr einen zeitlich begrenzten, für spezielle Zwecke autorisierten, "Benutzerausweis" (Token) zu verwenden. Das bekannteste und verbreitetste Verfahren ist OAuth2, welches als Standard im RFC 6749 spezifiziert ist.

Einen guten Überblick über das Verfahren finden Sie unter https://oauth.net/.

NTLM

Über den Windows NT LAN Manager können die Einträge zu Benutzername und Passwort gesetzt werden. Im Feld für den Benutzernamen wird dann folgende Syntax erwartet (bitte doppelten Backslash beachten):

NTLMv1 und v2 Syntax

domain//user