SLO mit SAML 2.0

Single Log-Out (SLO) ermöglicht Benutzern, alle ihre Sessions in einer SAML-Landschaft sauber zu beenden, selbst über Domänen hinweg. Das spart nicht nur Systemressourcen, die andernfalls bis zur Zeitüberschreitung der Session reserviert wären, sondern SLO verringert auch das Risiko, dass unbeaufsichtigte Sessions gekapert werden.

SAML bietet eine Anzahl an Bindungsmöglichkeiten, um SAML-Nachrichten zwischen dem Identity-Provider und dem Service-Provider hin und her zu schicken.

• Frontkanal

  Bei der Frontkanalkommunikation werden SAML-Nachrichten über den Useragent mit HTTP-Redirect- oder HTTP-POST-Methoden hin und her geschickt.

• Direkte Serverkommunikation

  Bei der direkten Serverkommunikation können der Identity- und der Service-Provider entweder SAML-Artefakte verwenden oder direkt über SOAP kommunizieren. Bei SAML-Artefakten tauschen der Identity- und der Service-Provider SAML-Artefakte über den Useragent aus. Wenn ein Provider ein Artefakt erhält, fordert er den anderen Provider direkt über SOAP zur Auflösung des Artefakts auf. Bei der SOAP-Bindung übertragen die Provider keine Artefakte. Sie tauschen SAML-Nachrichten direkt über SOAP aus.

Direkte Serverkommunikation bietet zusätzliche Sicherheit, da sie sicherstellt, dass potenzielle Spione am Useragent nicht auf die SAML-Nachrichten zugreifen können. Allerdings erfordert die Artefaktbindung zusätzliche Roundtrips, um eine Authentifizierungsanfrage zu beantworten. Sie können Frontkanalkommunikation mit Verschlüsselung und digitalen Signaturen schützen. Sie können die Kommunikationsoptionen mischen.

Die Abbildung unten zeigt SLO, das beim Service-Provider über eine Frontkanalbindung wie HTTP-Redirect und zwischen dem Identity-Provider und den anderen Service-Providern über eine direkte Serverkanalbindung wie SOAP über HTTP initiiert wird.

Abbildung 1: Prozessfluss für SLO mit SAML 2.0

1. Der Benutzer initiiert eine Abmeldeanfrage bei einem Service-Provider.

2. Der Service-Provider leitete diese Anfrage an einen Identity-Provider weiter.

3. Nachdem der Identity-Provider die Anfrage validiert hat, sendet er neue Abmeldeanfragen an alle anderen Service-Provider, bei denen der Benutzer eine Sicherheitssession hat, die dem Identity-Provider bekannt ist.

4. Die Service-Provider validieren die Anfrage, bauen alle Session-Informationen über den Benutzer ab und senden eine Abmeldeantwort an den Identity-Provider.

5. Der Identity-Provider baut die Sessions des Benutzers ab und sendet eine Antwort an den ursprünglichen Service-Provider.

6. Der ursprüngliche Service-Provider informiert den Benutzer darüber, dass er abgemeldet wurde.