Authentifizierung bei Webanwendungen HIT/ZID

Eine Authentifizierung dient der Identifizierung eines Anwenders bzw. dessen Bezeugung der Echtheit. Diese legt jedoch nicht die Zugriffsberechtigungen fest, was der Anwender mit seiner Authentifizierung innerhalb einer Anweldung sehen und/oder bearbeiten darf. Dafür ist die Autorisierung zuständig, welche nicht Bestandteil dieser Übersichtsseite ist.

Orte

	Anmeldung innerhalb Webseite in HIT v1, HIT v3, ZID v1 und ZID v2
	Anmeldung via REST-Schnittstelle in HIT v2 und HIT v3
	Anmeldung mit HTTP-Header Authorization (derzeit nur) in HIT v1
	Authentifizierung ohne Anmeldung via OIDC-OAuth-Schnittstelle

Details

Anmeldung Webseite

Die Authentifizierung zur Nutzung der Webanwendungen HIT und ZID geschieht innerhalb der Webanwendung:
wird eine Seite ohne gültige Anmeldung betreten, wird zur Anmeldeseite weitergeleitet. Nach einer erfolgreichen Anmeldung kehrt man automatisch wieder zurück zur gewünschten Seite.

Zur Prüfung wird eine aktive Sitzung überprüft, ob diese anhand des noch gültigen Session-Cookies seitens des Webbrowsers noch existiert.
↳ Wenn ja, wird überprüft, ob eine Verbindung zwischen Webserver und Hitserver besteht.
↳ Wenn auch dies gegeben ist, wird überprüft, ob diese Verbindung mit einem No operation-Befehl noch auf Anfragen antwortet.
→ Ist auch dies erfüllt, dann kann die aufgerufene Seite ohne erneute Anmeldung angesehen werden.

Von extern hat man keinen Einfluss auf diesen Prüf- und Anmeldeprozess.

Anmeldung REST

Diese Art der Anmeldung ist in einem eigenen Dokument beschrieben.

Man hat dort die Möglichkeit, die Anmeldung mit der Benutzerkennung vorzunehmen. Mit HIT v3 (nicht v2!) kann man auch mit einem von der OIDC-Schnittstelle erhaltenen Access Token anmelden, wobei aus Sicherheitsgründen auch die bei der OIDC-Kommunikation verwendete Client-ID angegeben werden muss.

Unter Zuhilfenahme eines Cache-Token lässt sich wie in einer klassischen Webanwendung eine Nutzeranmeldung über mehrere Anfragen hinweg nutzen.

Anmeldung mit HTTP-Header

Für das HIT v1 wurde die Möglichkeit geschaffen, aus einer externen Anwendung (Webseite oder Programm) heraus mit einer dort bestehenden Anmeldung ohne erneute Anmeldung sich in unserer HIT-Webanwendung einzuklinken. Dazu wird der im RFC 7235 Kapitel 4.2 beschriebene Authorization-Header des Hypertext Transfer Protocol (HTTP) verwendet. Da das klassische Schema Basic nicht sinnvoll verwendet werden kann (dieses besteht nur aus Benutzername und Passwort) und kein weiteres bekanntes Schema dafür geeignet ist, wird hier ein eigenes Schema in Form von Schlüssel-Wert-Paaren verwendet.

Da HIT v1 ausschließlich TLS-verschlüsselte Verbindungen zulässt, können die für die Anmeldung notwendigen Parameter (wie in einer Anmeldemaske übrigens auch) unverschlüsselt angegeben werden, da sie vor dem Versand über die HTTP-Verbindung automatisch verschlüsselt werden.

Ablauf

Wird ein Authorization-Header mitgesendet, dann wird geprüft, ob bereits eine Anmeldung besteht.
Falls ja, dann werden die Angaben mit der aktuellen Anmeldung abgeglichen. Sind sie deckungsgleich, wird ohne erneute Anmeldung fortgesetzt. Sind sie nicht deckungsgleich, wird der aktuelle Anwender ab- und der neue aus dem Header angemeldet.
Bestand keine Anmeldung, wird die Anmeldung mit den Daten aus dem Header durchgeführt.

Schlägt diese Anmeldung fehl, wird auf unsere Anmeldeseite weitergeleitet, so dass der Benutzer dennoch die Möglichkeit hat, sich bei uns anzumelden.

Auch wenn die Anmeldung zwar erfolgreich war, aber die PIN bereits abgelaufen ist, wird man ebenfalls auf unsere Anmeldeseite weitergeleitet.

Wird kein oder ein fehlerhafter Authorization-Header mitgesendet, dann verhält sich die Webanwendung wie oben unter "Anmeldung Webseite" beschrieben. Eine Fehlermeldung erhält man hierbei nicht!

Aufbau

Authorization: "HitLogin" WS <key> OWS "=" OWS <value> (OWS "," OWS <key> OWS "=" OWS <value>)*

HitLogin ist das Schema des Headers, WS ist ein erforderliches Leerzeichen (white space), OWS sind optionale Leerzeichen (optional white space). Die Token in "" werden as-is (ohne die "") verwendet. Der hintere Ausdruck (...)* zeigt an, dass dieser als ganzes 0..n Mal wiederholt werden darf.

Schlüssel <key> bestehen per Definition aus alphanumerischen Zeichen plus ein paar wenige Satzzeichen ohne Leerzeichen.
Folgende sind daher für das Schema HitLogin vorgegeben:

	bnr - erforderliche Anmeldebetriebsnummer
	mbn - optional eine Mitbenutzerkennung des Betriebs
	pin - erforderliches zu bnr (und ggf. mbn) gehörendes Passwort
	mandant - optional eine Mandantenbetriebsnummer, wenn eine Anmeldung in dessen Auftrag stattfinden soll

Ein Wert <value> enthält Werte mit entweder dem gleichen Zeichensatz wie beim Schlüssel (s.o.) oder -wenn dies nicht genügt- eine Zeichenkette in doppelten Hochkommas (quoted string). Letzteres gilt insbesondere dann, wenn Leerzeichen im Wert vorkommen. Sonderzeichen wie das doppelte Hochkomma selbst oder Zeichen der oberen 7bit des 8bit-ASCII-Zeichensatzes werden mit einem vorangestellten Backslash (\) maskiert.

Beispiele

Beispiel einer Anmeldung im Testsystem:

Authorization: HitLogin bnr="09 000 000 0001", pin=900001

Hiermit findet die Anmeldung mit der Betriebsnummer 09 000 000 0001 und dessen PIN 900001 statt und man erhält den gewünschten Inhalt der Seite, ohne zur HIT-eigenen Anmeldemaske springen zu müssen. Der Anwender ist anschließend natürlich auch für weitere Seiten in der Webanwendung angemeldet, als hätte er sich über unsere eigene Anmeldemaske angemeldet.

Obiges Beispiel liese sich auch ohne Leerzeichen im Wert nutzen:

Authorization: HitLogin bnr=276090000000001, pin=900001

Eine PIN mit erhöhter Komplexität (derzeit noch nicht möglich) würde etwa so aussehen:

Authorization: HitLogin bnr=276110000000004, pin="G=\"f.(Dw\\i2a"

Hier sind das doppelte Hochkomma " und der Backslash \ des Passworts mit einem \ vorangestellt maskiert.

Authentifizierung via OIDC-OAuth-Schnittstelle

Dies ist in einem eigenen Dokument beschrieben. Ein von dort erhaltenes Access Token kann nur bei der REST-Schnittstelle verwendet werden, um sich damit anmelden zu können. In erster Linie dient dieses jedoch nur der Authentifizierung.

.