Single Sign On (SSO)

Bilaterale Identitätsföderation für den nahtlosen Übergang zwischen Applikationen

Eine bilaterale Identitätsföderation eignet sich, wenn keine umfassende SSO-Domäne benötigt wird, sondern ein gezielter und nahtloser Übergang von einer bereits authentifizierten Applikation A zu einer Applikation B ermöglicht werden soll.

Dabei wird AGOV weder erweitert noch speziell konfiguriert. Es werden insbesondere keine SSO-Domänen in AGOV aufgebaut und keine AGOV-Sessions zwischen den beteiligten Applikationen vermittelt.

Grundprinzip

AGOV authentifiziert die natürliche Person gegenüber Applikation A beziehungsweise deren IAM. Die bereits erfolgte Authentifizierung kann anschliessend von Applikation A beziehungsweise ihrem IAM als Grundlage verwendet werden, um gegenüber Applikation B eine neue, speziell für B bestimmte Identitätsaussage abzugeben.

Die Vertrauenskette lautet somit:

AGOV
  |
  | authentifiziert die natürliche Person
  v
IAM / Applikation A
  |
  | gibt gegenüber Applikation B eine eigene,
  | für B bestimmte Identitätsaussage ab
  v
Applikation B
  |
  | eröffnet eine eigene Session
  v
Zielanwendung

Es entstehen zwei getrennte Vertrauensbeziehungen:

• AGOV -> Applikation A
• Applikation A / IAM A -> Applikation B

Die zweite Vertrauensbeziehung wird vollständig ausserhalb von AGOV betrieben.

Keine Übernahme von AGOV-Tokens

Applikation B vertraut nicht einem ursprünglich für Applikation A ausgestellten AGOV-Token. Ein für eine bestimmte Relying Party ausgestellter Token ist nicht automatisch für eine andere Relying Party bestimmt. Insbesondere darf die Audience-Prüfung nicht abgeschwächt werden, um einen solchen Token trotzdem akzeptieren zu können.

Nicht vorgesehen ist deshalb:

AGOV
  |
  | Token für Applikation A
  v
Applikation A
  |
  +-> Applikation B

Stattdessen entsteht eine neue Aussage von A beziehungsweise ihrem IAM speziell für B:

AGOV
  |
  v
IAM A
  |
  | neue signierte Aussage
  | Audience = Applikation B
  v
Applikation B

Die ursprüngliche AGOV-Authentifizierung ist dabei lediglich die Grundlage, auf welcher der Issuer von Applikation A seine eigene Aussage abgibt.

Beteiligte Rollen

AGOV
AGOV authentifiziert die natürliche Person im bestehenden Login-Prozess von Applikation A. AGOV muss nicht wissen, dass die Person anschliessend Applikation B aufruft, welche Applikationen untereinander föderiert sind, welche Session bei Applikation B entsteht oder welche Identitätsaussage Applikation A später gegenüber B abgibt.

Issuer von Applikation A
Der Issuer ist der technische und organisatorische Vertrauensanker auf Seiten von Applikation A. Idealerweise handelt es sich um ein IAM oder einen Security Token Service und nicht um beliebigen Anwendungscode.

Der Issuer darf Identitätsaussagen für Applikation B nur aufgrund einer gültigen authentifizierten Session ausstellen.

Applikation B
Applikation B führt eine Liste der ausdrücklich zugelassenen Issuer.

Sie prüft jede eingehende Identitätsaussage vollständig und eröffnet daraus eine eigene Anwendungssession. Eine vorgängige Kenntnis der betreffenden Person bei Applikation B ist nicht zwingend erforderlich.

Beispielhafter Ablauf

1. Die Person ist bereits bei Applikation A angemeldet. Die zugrunde liegende Authentifizierung kann beispielsweise mit AGOV erfolgt sein. Nach erfolgreicher Authentifizierung besitzt IAM A eine eigene Session.


2. Die Person wählt innerhalb von Applikation A eine Funktion, welche zu Applikation B führt. Applikation A erkennt die bestehende Session und fordert beim eigenen Issuer eine speziell für Applikation B bestimmte Identitätsaussage an.


3. Der Issuer erzeugt eine kryptografisch signierte Assertion. Sie enthält nur die für B vereinbarten Angaben und ist ausdrücklich für B bestimmt. Schematisch können beispielsweise Issuer, Audience, Subject, Ausstellungs- und Ablaufzeitpunkt, eine eindeutige Transaktions-ID, der Zeitpunkt der zugrunde liegenden Authentifizierung sowie die vereinbarten Identitäts- und Qualitätsangaben enthalten sein.


4. Die Identitätsaussage wird vorzugsweise serverseitig an Applikation B übertragen. Die Verbindung kann zusätzlich mit gegenseitiger TLS-Authentifizierung (mTLS) abgesichert werden.

Damit können zwei unabhängige Sicherheitsmechanismen kombiniert werden:

Transportebene:
Ist die aufrufende Gegenstelle tatsächlich der registrierte technische Client?

und

Nachrichtenebene:
Ist die Identitätsaussage tatsächlich vom registrierten Issuer signiert worden?

Validierung durch Applikation B

Applikation B akzeptiert die Identitätsaussage nur, wenn sämtliche vorgesehenen Prüfungen erfolgreich sind. Dazu gehören insbesondere:

• technischer Client ist zugelassen;
• Issuer ist registriert;
• Signatur ist gültig;
• Signaturschlüssel ist diesem Issuer zugeordnet;
• Token- beziehungsweise Assertion-Typ ist der erwartete Typ;
• Audience entspricht exakt Applikation B;
• Ausstellungs- und Ablaufzeitpunkt sind plausibel;
• die maximale zulässige Lebensdauer ist eingehalten;
• eine eindeutige Transaktions-ID wurde noch nicht verwendet;
• der Zeitpunkt der zugrunde liegenden Authentifizierung genügt der Policy;
• die behauptete Authentifizierungs- und Identitätsqualität genügt dem Anwendungsfall;
• Schema und Pflichtangaben sind gültig.

Es genügt ausdrücklich nicht, lediglich zu prüfen, ob eine Signatur mathematisch gültig ist. Geprüft werden muss die gesamte registrierte Vertrauensbeziehung aus technischem Client, Issuer, zugeordnetem Schlüssel, korrektem Assertion-Typ, korrekter Audience, gültiger Signatur und gültigem Zeitfenster.

Einmaliger Handover-Code

Nach erfolgreicher Validierung kann Applikation B einen kryptografisch zufälligen, nicht erratbaren und sehr kurzlebigen Handover-Code erzeugen. Dieser enthält selbst keine Personendaten und wird genau einmal verwendet.

Applikation B verknüpft serverseitig den Hash dieses Codes mit der bereits validierten Identitätsaussage, dem Issuer, dem Subject, den Authentifizierungsinformationen, dem Erstellungs- und Ablaufzeitpunkt sowie dem Status UNUSED.

Der Code soll hohe Entropie besitzen, nur sehr kurz gültig sein und genau einmal eingelöst werden können. Für einen unmittelbaren Browserübergang liegt eine Gültigkeit von wenigen Sekunden bis höchstens ungefähr einer Minute nahe.

Übergabe im Browser

Der Browser erhält ausschliesslich diesen einmal verwendbaren Code.

Bevorzugt erfolgt die Übergabe über einen HTTPS-POST an einen dafür vorgesehenen Endpunkt von Applikation B.

Der Browser transportiert insbesondere nicht:

• AGOV-Token;
• Access Token von Applikation A;
• Session Cookie von Applikation A;
• AGOV Session Cookie;
• vollständige Identitätsaussage;
• unnötige Personendaten.

Damit werden die eigentlichen Vertrauens- und Identitätsinformationen nicht über den Browser zwischen den Anwendungen transportiert.

Einlösen des Codes

Applikation B prüft beim Empfang des Handover-Codes, ob der Code vorhanden, noch gültig, unbenutzt und einer erfolgreich validierten Transaktion zugeordnet ist. Danach wird er atomar auf USED gesetzt und eine eigene Session für Applikation B eröffnet.

Die Einlösung muss atomar erfolgen. Auch zwei gleichzeitig eintreffende Requests dürfen denselben Code nicht zweimal verwenden können.

Eigene Session bei Applikation B

Applikation B eröffnet eine eigene Session. Diese ist unabhängig von der AGOV-Session, der Session von Applikation A und gegebenenfalls der Session des IAM von Applikation A.

Es entsteht deshalb nicht automatisch ein organisationsübergreifendes Single Logout. Ein Logout bei Applikation A beendet nicht zwingend die Session bei Applikation B und umgekehrt.

Vertrauensmodell

Applikation B führt für jeden zugelassenen Issuer eine explizite Registrierung. Darin werden mindestens festgelegt:

• eindeutige Issuer-ID;
• zugelassene technische Client-Identität, gegebenenfalls mTLS;
• zugelassene öffentliche Signaturschlüssel beziehungsweise eine kontrollierte Schlüsselquelle;
• erwartete Audience;
• erwarteter Assertion-Typ;
• zugelassene kryptografische Algorithmen;
• zulässige und erforderliche Claims;
• maximale Gültigkeitsdauer.

Eine Identitätsaussage eines nicht registrierten Issuers wird abgelehnt. Auch eine gültige Signatur eines anderen bekannten Issuers genügt nicht, wenn Issuer, Schlüssel, technischer Client und Audience nicht zur gleichen registrierten Vertrauensbeziehung gehören.

Schlüsselmanagement

Private Signaturschlüssel verbleiben beim jeweiligen Issuer.

Applikation B benötigt ausschliesslich die öffentlichen Schlüssel zur Prüfung.

Bei einem Schlüsselwechsel kann eine kontrollierte Überlappungsphase vorgesehen werden, in der alter und neuer öffentlicher Schlüssel akzeptiert werden. Danach wird der alte Schlüssel entfernt. Ein kompromittierter Issuer oder Schlüssel muss kurzfristig gesperrt werden können.

Änderungen an Issuern, Schlüsseln und technischen Clients erfolgen über einen kontrollierten administrativen Prozess. Eine eingehende Identitätsaussage darf nicht selbst bestimmen können, welcher beliebige externe Schlüssel oder welche beliebige externe Schlüsselquelle für ihre Prüfung verwendet wird.

Replay-Schutz

Die Architektur kombiniert mehrere Schutzschichten. Die Identitätsaussage ist nur für Applikation B bestimmt, kurzlebig, signiert und besitzt eine eindeutige Transaktions-ID. Der Handover-Code besitzt hohe Entropie, ist kurzlebig, enthält keine Personendaten und kann nur einmal atomar eingelöst werden.

Applikation B führt für bereits verwendete Transaktions-IDs einen Replay-Schutz. Ein bereits verwendeter Handover-Code wird ebenfalls abgelehnt.

Bedeutung einer Angabe wie auth_source = AGOV

Falls Applikation B wissen muss, dass die ursprüngliche Authentifizierung über AGOV erfolgte, kann das vereinbarte Föderationsprofil eine entsprechende Angabe enthalten.

Beispielsweise:

Issuer = IAM von Applikation A
auth_source = AGOV

Dies bedeutet: Der Issuer von Applikation A bestätigt, dass die dieser Identitätsaussage zugrunde liegende Session mittels AGOV authentifiziert wurde.

Es bedeutet nicht: Diese Identitätsaussage wurde von AGOV ausgestellt.

Der Issuer bleibt das IAM von Applikation A. Applikation B vertraut hinsichtlich dieser Aussage dem Issuer von Applikation A und nicht AGOV unmittelbar.

Authentifizierungs- und Identitätsqualität

Der Issuer darf gegenüber Applikation B keine höhere Qualität behaupten, als aus der tatsächlich zugrunde liegenden Authentifizierung und Identitätsprüfung zuverlässig abgeleitet werden kann.

Die Abbildung von Authentifizierungsqualität, Identitätsprüfungsqualität, Authentifizierungszeitpunkt, verwendeten Authentifizierungsmitteln und weiteren relevanten Qualitätsmerkmalen muss deshalb Teil des vereinbarten Föderationsprofils sein. Frei interpretierbare Qualitätsangaben sind zu vermeiden.

Datenschutz und Datenminimierung

Die Identitätsaussage enthält ausschliesslich die Angaben, welche Applikation B für den konkreten Vorgang benötigt. Eine bilaterale Identitätsföderation ist keine allgemeine Schnittstelle zum Austausch sämtlicher über eine Person vorhandener Informationen.

Technisch und organisatorisch ist festzulegen, welche Attribute übertragen werden dürfen, für welchen Zweck sie verwendet werden, wie lange sie benötigt werden und welche Stelle dafür verantwortlich ist.

Logging

Nicht geloggt werden sollen vollständige Identitätsaussagen, Handover-Codes im Klartext, Session Cookies, private Schlüssel oder unnötige Personendaten.

Für Security Audit und Nachvollziehbarkeit können insbesondere Zeitpunkt, Issuer, pseudonymisierte Transaktions-ID, Ergebnis der Validierung, verwendete Schlüssel-ID, Handover-Ergebnis und technische Fehlerklasse protokolliert werden.

Fehlerverhalten

Ein fehlerhafter Handover darf niemals zu einer Abschwächung der Sicherheitsprüfungen führen. Unbekannter Issuer, falsche Audience, ungültige Signatur, abgelaufene Assertion, bereits verwendete Transaktions-ID, abgelaufener oder bereits verwendeter Handover-Code, ungenügende Qualität oder ein nicht zugelassener technischer Client führen zur Ablehnung.

Nach einem fehlgeschlagenen Handover kann Applikation B gegebenenfalls ihren regulären Login-Prozess anbieten.

Onboarding einer neuen Vertrauensbeziehung

Vor einer produktiven Freischaltung müssen die beteiligten Stellen mindestens Issuer, technischen Client, Schlüssel und Schlüsselrotation, Audience, Assertion-Typ, Pflicht- und optionale Claims, akzeptierte Authentifizierungs- und Identitätsqualität, maximale Lebensdauer, Replay-Schutz, zulässige Personendaten, betriebliche Kontaktstellen, Notfallsperrung sowie positive und negative Konformitätstests verbindlich festlegen.

Sicherheitsrelevante Tests

Vor der Freigabe sollten mindestens folgende Negativfälle geprüft werden:

• gefälschte Signatur;
• nicht zugelassener Signaturalgorithmus;
• falscher Issuer;
• richtiger Issuer mit falschem Schlüssel;
• richtiger Schlüssel mit falscher Audience;
• abgelaufene Assertion;
• Assertion mit unplausiblem Zeitstempel;
• wiederverwendete Transaktions-ID;
• wiederverwendeter Handover-Code;
• abgelaufener Handover-Code;
• falscher technischer Client;
• Assertion eines anderen Issuers;
• Assertion eines anderen Dienstes desselben Issuers;
• manipulierte Claims;
• unbekannter Schlüssel;
• gleichzeitige Doppeleinlösung.

Entkopplung von AGOV

Eine bilaterale Identitätsföderation erzeugt keine zusätzliche Laufzeitabhängigkeit von Applikation B zu AGOV. Beim eigentlichen Übergang kommunizieren die beteiligten Systeme direkt miteinander:

Applikation A <-> Applikation B

und nicht:

Applikation A <-> AGOV <-> Applikation B

AGOV bleibt auf seine ursprüngliche Rolle als Authentifizierungssystem beschränkt.

Abgrenzung zu einer SSO-Domäne

Aus Sicht der Benutzerin oder des Benutzers kann das Resultat wie SSO erscheinen: Die Person ist bei Applikation A angemeldet, wählt Applikation B und gelangt ohne erneuten interaktiven Login direkt in B.

Architektonisch entsteht jedoch keine gemeinsame SSO-Domäne in AGOV.

Die Verantwortungsgrenzen bleiben klar:

• AGOV: Authentifizierung der natürlichen Person.
  
• Applikation A / IAM A: eigene Session und zielgerichtete Identitätsaussage.
  
• Applikation B: Validierung, eigene Identität, eigene Session und eigene Berechtigungen.
  

Eine bilaterale Identitätsföderation eignet sich deshalb insbesondere für einzelne, klar definierte Übergänge zwischen Anwendungen. Sollen hingegen zahlreiche Anwendungen innerhalb einer Organisation gegenseitig SSO nutzen können, ist in der Regel ein intermediäres IAM-System beziehungsweise eine eigentliche organisatorische SSO-Domäne die passendere Architektur.

Verwendung bestehender Standards

Kann das IAM von Applikation A bereits als standardkonformer Identity Provider gegenüber Applikation B auftreten, soll nach Möglichkeit ein etablierter Standard wie OpenID Connect oder SAML verwendet werden, anstatt einen eigenen Übergabemechanismus zu definieren.

Auch in diesem Fall bleibt das Architekturprinzip unverändert:

Applikation B <-> IAM A <-> AGOV

und nicht:

Applikation B <-> neue AGOV-SSO-Funktion

Entscheidend ist nicht das konkret verwendete Protokoll, sondern die klare Trennung der Vertrauensbeziehungen.

Architekturgrundsatz

Eine bereits mit AGOV authentifizierte Session kann von einem nachgelagerten IAM als Grundlage für eine bilaterale Identitätsföderation zu einer anderen Applikation verwendet werden.

Dafür wird AGOV weder erweitert noch speziell konfiguriert. Es werden insbesondere keine SSO-Domänen in AGOV eingerichtet, keine AGOV-Sessions zwischen Applikationen vermittelt, keine für andere Relying Parties ausgestellten AGOV-Tokens weitergereicht und keine applikationsspezifischen Föderationsfunktionen in AGOV eingebaut.

Die beteiligten Applikationen beziehungsweise deren IAM-Systeme errichten stattdessen eine eigene, ausdrücklich definierte und abgesicherte Vertrauensbeziehung. Damit lässt sich ein nahtloser Übergang zwischen einzelnen Anwendungen ermöglichen, ohne AGOV zur zentralen SSO-Drehscheibe zwischen diesen Anwendungen zu machen.