Session Aufbau SAML 2.0 mit STS-PEP

Session Aufbau zwischen Webbrowser und STS-PEP

SP initiated Web SSO - Einleitung
Beim Verarbeiten des ersten Requests in der Applikation, weiss die Applikation noch nicht um welchen Benutzer es sich handelt, da noch kein Security Kontext aufgebaut ist. Es obliegt somit der Applikation zu entscheiden, ob ein Security Kontext für den gewählten Zugriff aufgebaut werden muss.

Entscheidet die Applikation, dass für den Request eine Authentifizierung und eine Autorisierung erfolgen muss, so kann sie diese mittels des „SP initiated Web SSO“ Szenarios einleiten. Dieses Szenario wird SAML umgangssprachlich auch als "SP-First" bezeichnet.

SP initiated Web SSO - Vorteile
Das SP initiated Web SSO Szenario wurde für die Anbindung von Applikationen an eIAM gewählt, da es einige gewichtige Vorteile gegenüber anderen Verfahren (z.B. IdP initiated Web SSO) bietet.

• Das Verfahren wird von allen gängigen SAML 2.0 Implementierungen unterstützt und ist bei diesen Produkten gut dokumentiert.
• Das Verfahren lässt es zu, dass die Applikation selbst entscheiden kann, ob für den Zugriff auf die Ressource ein Security Kontext benötig wird, ohne dass das Enforcen der Policy auf dem STS-PEP (nur authentifizierte und autorisierte Requests auf die Applikation lassen) verletzt werden muss. Diese Logik muss somit nicht statisch auf dem PEP implementiert werden. Somit sind bei Änderungen in der Applikation keine Änderungen auf dem STS-PEP notwendig.
• Beim Verlust des Security Kontext auf der Applikation z.B. durch einen Session Time-out in der Applikation oder durch einen Restart der Applikation, kann die Applikation bei Bedarf jederzeit eine neue SAML Assertion beim STS-PEP anfordern.
• Setzt keine Backchannel Verbindungen zwischen Service Provider und Identity Provider voraus, da die komplette Kommunikation über den Browser des Benutzers erfolgt. Dies ist vor allem wichtig bei Applikationen welche ausserhalb der Netze der Bundesverwaltung gehostet werden.

Session Aufbau zwischen Applikationen und STS-PEP

Ablauf
Im Folgenden wird der Ablauf des Aufbaus der Sessions zwischen dem Webbrowser des Benutzers, dem STS-PEP und den ausserhalb der Netze der Bundesverwaltung gehosteten Applikationen beschrieben.

Session Aufbau Applikationen ausserhalb der Netze der Bundesverwaltung

1. Der Webbrowser des Benutzers ruft die Applikation auf.
2. Die Applikation stellt fest, dass für den Zugriff auf die Ressource eine Autorisierung nötig ist und prüft, ob bereits eine Session mit dem Benutzer existiert.
3. Da noch keine Session besteht, stellt die Applikation einen von ihr signierten SAML AuthnRequest zuhanden des STS-PEP aus und bettet diesen in ein selbstübermittelndes HTML Formular ein. Zusätzlich wird im Parameter „RelayState“ die vom Benutzer im ursprünglichen Request im Schritt 1 verlangte URL mitgegeben, damit der Browser des Benutzers nach Abschluss der Authentifizierung wieder auf diese URL geleitet werden kann.
4. Der Webbrowser sendet den AuthnRequest per HTTP POST an die SSO URL des STS-PEP.
5. Der STS-PEP prüft den SAML AuthnRequest auf Gültigkeit und ob der Request von einer ihr vertrauten Applikation stammt. Ist dies der Fall, so prüft der STS-PEP, ob bereits eine Session mit dem Webbrowser des Benutzers besteht.
6. Besteht auf dem STS-PEP noch keine Session mit dem Webbrowser des Benutzers, so stellt der STS-PEP seinerseits einen von ihm signierten SAML AuthnRequest zuhanden des eIAM Trustbrokers aus. Dieser wird in ein selbstübermittelndes HTML Formular eingebettet und als HTTP Response an den Webbrowser des Benutzers übermittelt.
7. Der Browser des Benutzers sendet den SAML AuthnRequest des STS-PEP per HTTP POST an den eIAM-Trust Broker.
8. Der eIAM Trustbroker prüft den SAML AuthnRequest auf Gültigkeit und darauf, ob dieser von einem vertrauten STS-PEP stammt. Ist dies der Fall, so startet der eIAM Trustbroker das sogenannte Home Realm Discovery. Er generiert eine Liste mit den für die Authentifizierung des Benutzers zur Verfügung stehenden Identity Provider. Diese Liste kann für Benutzer aus dem Netz der Bundesverwaltung und für Benutzer ausserhalb der Netze der Bundesverwaltung unterschiedlich definiert sein.
9. Stehen mehrere Möglichkeiten für die Authentifizierung in der gleichen Netzwerkzone zur Verfügung, so wird dem Benutzer eine Auswahl angezeigt.
10. Der Benutzer sendet die Wahl des zu verwendeten Identity Provider per HTTP POST an den eIAM-Trust Broker.
11. Der eIAM Trustbroker erstellt zuhanden des vom Benutzer gewählten IdP einen von ihm signierten SAML AuthnRequest. Dieser wird in ein selbstübermittelndes HTML Formular eingebettet und als HTTP Response an den Webbrowser des Benutzers übermittelt.
12. Der Webbrowser des Benutzers sendet den SAML AuthnRequest des eIAM Trustbrokers per HTTP POST an den Identity Provider.
13. Der Identity Provider prüft den SAML AuthnRequest auf Gültigkeit und darauf, ob dieser von einem ihm vertrauten eIAM Trustbroker stammt. Ist dies der Fall, so führt der IdP mit dem Benutzer die Authentifizierung durch.
14. Authentifizierung auf dem IdP. Der Ablauf der eigentlichen Authentifizierung variiert von IdP zu IdP und ist nicht Bestandteil dieser Beschreibung.
15. Nach erfolgreicher Authentifizierung des Benutzers, stellt der IdP eine SAML Response zuhanden des eIAM Trustbrokers aus. Diese SAML Response enthält eine Assertion mit Angaben über den Benutzer und Attribute. Die Menge und die Art der Attribute können dabei von IdP zu IdP variieren. Die Assertion in der SAML Response wird vom IdP signiert. Die SAML Response wird in ein selbstübermittelndes HTML Formular eingebettet und als HTTP Response an den Webbrowser des Benutzers übermittelt.
16. Der Webbrowser des Benutzers sendet die SAML Response per HTTP POST an den eIAM-Trust Broker.
17. Der eIAM Trustbroker prüft die SAML Response und validiert die Assertion darauf, dass diese von einem vertrauten IdP signiert wurde und nicht nachträglich verändert wurde.
18. Der eIAM Trustbroker sucht das vom IdP in der SAML Assertion gemeldete Subjekt (Benutzer) im eIAM-AM Supermandanten anhand der Identitätsreferenz.
19. Wurde ein Benutzer mit entsprechender Identitätsreferenz im eIAM-AM Supermandant gefunden, so wird der Account des Benutzers im eIAM-AM Access Mandant des Fachamtes gesucht, das die Berechtigungen für die Fachapplikation administriert.
20. Der eIAM Trustbroker reichert die SAML Assertion vom IdP mit weiteren Attributen (z.B. Berechtigungsrollen) aus der Abfrage im eIAM-AM an. Der eIAM Trustbroker erstellt eine SAML Response zuhanden des STS-PEP. Die Response enthält eine vom eIAM Trustbroker signierte SAML Assertion.
21. Die SAML Response wird in ein selbstübermittelndes HTML Formular eingebettet und dem Webbrowser des Benutzers als HTTP Response zugestellt.
22. Der Webbrowser sendet die SAML Response per HTTP POST an den STS-PEP.
23. Der STS-PEP prüft die SAML Response auf Gültigkeit und validiert die Assertion darauf, dass diese von einem eIAM Trustbroker stammt, welchem er vertraut. Ferner wird überprüft, dass die nach deren Signierung nicht mehr verändert wurde. Ist die Prüfung erfolgreich, so erstellt der STS-PEP eine Session mit dem Webbrowser des Benutzers. In der Session auf dem STS-PEP werden die Attribute des Benutzers für eine spätere Wiederverwendung gespeichert. Um diese Session zu Tracken, wird ein Session Cookie ausgestellt. Der STS-PEP erstellt eine SAML Response mit einer von ihm signierten Assertion. Diese Assertion enthält Attribute des Benutzers, welche er vom IdP und aus eIAM-AM.
24. Die SAML Response wird in ein selbstübermittelndes HTML Formular eingebettet und dem Webbrowser des Benutzers als HTTP Response zugestellt.
25. Der Webbrowser sendet die SAML Response mittels HTTP POST an die Applikation. Dabei wird auch der Parameter „RelayState“ wieder mitgegeben.
26. Die Applikation prüft die SAML Response auf Gültigkeit und validiert die darin enthaltene Assertion darauf, dass diese von einem ihr vertrauten STS-PEP ausgestellt wurde und nach dem Signieren nachträglich nicht mehr verändert wurde. Die Applikation erstellt eine Session mit dem Webbrowser des Benutzers. In der Session führt sie die Attribute des Benutzers (Claims) aus der SAML Assertion.
27. Die Applikation schickt mit der HTTP Response an den Webbrowser einen Redirekt auf die im „RelayState“ hinterlegte Adresse. Der Webbrowser wird damit wieder auf die in Schritt 1 verlangte URL geschickt. Die Applikation setzt mit dieser HTTP Response ein Session Cookie um die Session des Webbrowser zu tracken.
28. Der Webbrowser ruft die Adresse auf der Applikation, auf welche er umgeleitet wurde auf.
29. Da nun zwischen Webbrowser und Applikation eine Session besteht, und die Prüfung der Autorisierung des Benutzers positiv ausfällt, wird dem Benutzer die angeforderte Ressource als HTTP Response zurückgeschickt.
30. bis 40. Diese Sequenz zeigt den Zugriff des gleichen Benutzers mit dem gleichen Webbrowser auf eine zweite Applikation in der gleichen SSO Domäne (beide Applikationen verwenden den gleichen STS-PEP). Dabei entfallen die Schritte auf dem eIAM Trustbroker und dem IdP. Da bereits eine SSO Session auf dem STS-PEP besteht, kann dieser direkt eine SAML Assertion zuhanden der Applikation ausstellen.