Was meint eigentlich “Login”?
Im Beitrag “Welche Daten fallen an?” habe ich beschrieben, wie der Ablauf bei der Nutzung der E-ID in einem zentralen Modell aussieht, wenn die Relying Party einen Vertrag mit ihrem IdP hat. Es ist der folgende Ablauf:
(Zur Erinnerung: Dieser Ablauf wird komplizierter, wenn die Relying Party nicht denselben IdP verwendet wie die Nutzerin. Doch darauf möchte ich in eine separaten Beitrag eingehen.)
In Schritt #3 hat die Relying Party den IdP darüber informiert, dass bei ihr ein Login-Wunsch angefallen ist und sie den IdP bittet, die Identität zu bestätigen. In Schritt #5 legitimiert sich die Nutzerin erfolgreich mit den Faktoren, die der IdP im Rahmen des Authentisierungsvorgangs (Schritt #5) prüft.
Schritt #5 ist das Login, von dem z.B. im Beitrag “E-ID: Was ist das? (ein Login)” die Rede ist.
Nachdem das Login der Nutzerin auf den Systemen des IdP somit erfolgreich war, übermittelt der IdP der Relying Party einen sog. Token (Schritt #6). Ein Token ist z.B. eine Datei, in der Daten gespeichert werden und auf die ein System zugreifen möchte, um weitere Operationen daran anzuknüpfen.
Sobald die Relying Party den Token erhalten hat, fragt sie die aus ihrer Sicht für die Fortsetzung der bei ihr laufenden Session notwendigen Attribute ab (z.B. Name, Vorname, Alter = Credentials) ab (Schritte #7-#10).
Sobald sie diese Angaben erhalten hat, setzt sie auf ihrem Server eigenständig die Session fort. Diese Session ist aus ihrer Sicht natürlich ebenfalls ein Login-Vorgang. Ich bezeichne den Vorgang auf dem Server der Relying Party nach Möglichkeit als Anmeldevorgang, um zum Ausdruck zu bringen, dass es nicht dieser Vorgang ist, den ich auf diesem Blog als Login bezeichne. Dieser läuft aber vollständig auf den Servern der Relying Party ab.
Relevant ist Folgendes: Für den IdP ist dieser Servervorgang fremd. Dass der IdP in die ab Teilschritt #10 anknüpfenden Vorgänge involviert wäre, ist auf jeden Fall kein Automatismus. Ich möchte dies in einem anknüpfenden Beitrag weiter vertiefen.
Was im Anschluss an den Schritt #10 geschieht, ist nicht mehr standardisiert. Ab hier kommt es auf das Design des Login-Vorgangs bei der Relying Party an. Dieser Ablauf wird von der Relying Party definiert. Der IdP ist ab hier aus dem Spiel; er ist ja auch nicht Teil der zwischen der von der Relying Party für die Nutzerin eröffneten Session.
Es wird im Folgenden darum gehen, Folgendes besser zu verstehen:
- regelt das BGEID, wie die Relying Party im Anschluss an den oben dargestellten Schritt #10 vorgeht? (siehe den Gastbeitrag von Kaspar Etter, Punkt 1: Er kritisiert, dass das BGEID nichts regelt hierzu)
- kann der IdP über den Anschlussvertrag auf die Relying Party Einfluss nehmen (z.B. wie die Relying Party die an den Teilschritt #10 anknüpfenden Schritte abzuwickeln hat)?
- muss der IdP im Anschlussvertrag Regeln aufstellen, welche die Relying Parties einschränken?
Der Titel dieses Artikels müsste eher lauten «Was meine ich mit “Login”?». Wenn die Befürworter des BGEID sagen, dass die E-ID ein einfaches Login sei, dann meinen sie, dass man sich mit der E-ID bei Relying Parties anmelden kann, ohne bei denen nochmals zusätzliche Authentifizierungsfaktoren zu haben. Sonst ist ein Identity Provider ja auch kein Identity Provider sondern lediglich ein (Verified) Attribute Provider.
Ein paar fachliche Inputs.
1. Nach dem Schritt 5 findet üblicherweise kein Schritt 6 und 7 statt bei den gängigen Protokollen, sondern direkt der Schritt 8. Die Consent Erteilung findet also gleich nach dem “Login” (Authentifizierung) statt. Je nach Protokoll werden dann die Attribute gleich im Token geliefert oder diese werden von einer API durch den RP ausgelesen (mit dem Token).
2. “Der IdP ist ab hier aus dem Spiel; er ist ja auch nicht Teil der zwischen der von der Relying Party für die Nutzerin eröffneten Session.”
Das stimmt nur bedingt, nämlich dann wenn der RP Identity Brokering mit eigenem Session Management macht, was sicherlich nicht jede RP machen wird. Im weiteren werden im Hintergrund häufig Session Checks und/oder Single Logout Prozesse definiert. Ohne diese Prozesse kann der RP nicht erfahren wenn eine Identität gesperrt o.ä wird.
3. “Was im Anschluss an den Schritt #10 geschieht, ist nicht mehr standardisiert”
Dazu gibt es Standard Prozesse und Architekturen. Hierbei handelt es sich ja schlicht um A: Federated Identity oder B: Identity Brokering (Was A inkludiert)