Session Aufbau SAML 2.0 mit RP-PEP

1. Die Session zwischen dem Web Browser des Benutzers mit dem RP-PEP.
2. Die Session zwischen dem RP-PEP und der Applikation.

Session Aufbau zwischen Web Browser und RP-PEP

Service Provider initiated Web SSO – Einleitung
Aus Sicht des Benutzers bildet der RP-PEP zusammen mit der Applikation hinter dem RP-PEP einen SAML Service Provider (SP). Der initiale Request des Benutzers wird an diesen Service Provider gesendet, ohne dass der Benutzer sich vorgängig authentifiziert hat. Der RP-PEP entscheidet über die definierte Policy, ob für die Verarbeitung und Weiterleitung des Requests eine vorgängige Authentifizierung des Benutzers notwendig ist. Der RP-PEP als SAML SP initiiert bei Bedarf die Authentifizierung. Wir sprechen auch von einem sogenannten Service Provider initiated Szenario oder kurz „SP First“.

Service Provider initiated Web SSO - Ablauf
Die nachstehende Abbildung zeigt den Ablauf des Security Kontext (SSO-Session) auf dem RP-PEP in der offenen Architektur mit den dabei involvierten Akteuren. Der RP-PEP führt selbst keine Informationen über den Benutzer. Er delegiert die Authentifizierung des Benutzers an den eIAM Trustbroker als Federation Provider (FP), welcher seinerseits die Authentifizierung des Benutzers an einen für die aufgerufene Applikation definierten Identity Provider (IdP) delegiert. Der eIAM Trustbroker hat Zugriff auf den Attribut Provider (AP) eIAM-AM, welcher die für das Access Management nötigen Rollen und weitere Attribute des Benutzers hält.

Der Aufbau der Session zwischen Applikation und RP-PEP wird nachfolgend unter "Session Aufbau zwischen Applikation und RP-PEP" beschrieben.

Session Aufbau Webbrowser-PEP

1. Der unauthentifizierte Benutzer ruft die URL der Webapplikation auf dem RP-PEP auf. Request wird vom RP-PEP „abgefangen“.
2. Der RP-PEP stellt fest, dass für den Request ein Security Kontext nötig ist, aber kein solcher besteht. Der RP-PEP stellt über die hinterlegte Policy fest, dass der Benutzer der den Request stellt authentifiziert werden muss und dass für den Zugriff eine bestimmte Autorisierung notwendig ist.
3. Der RP-PEP stellt einen SAML 2.0 AuthnRequest aus, welcher in einem selfsubmitting HTML Form mit der Destination eIAM Trustbroker an den Webbrowser des Benutzers geschickt wird. Mit dieser Form wird in einem weiteren Parameter RelayState die URL mitgegeben, welche der Benutzer ursprünglich aufgerufen hat, damit dieser nach erfolgreicher Authentifizierung vom PEP auf diese URL redirektet werden kann. Des Weiteren wird ein temporäres Cookie gesetzt, um Requests dieses Clients zu tracken.
4. Der Webbrowser des Benutzers sendet das HTML Form mit dem AuthnRequest per Java Script automatisch an den eIAM Trustbroker.
5. Der eIAM Trustbroker prüft, ob der AuthnRequest von einem Aussteller stammt, mit dem ein Vertrauensverhältnis besteht.
6. Der eIAM Trustbroker sendet dem Benutzer, falls die Prüfung des AuthnRequest erfolgreich war, ein HTML Form mit der Auswahl der für die Authentifizierung verfügbaren IdP.
7. Der Benutzer sendet die IdP Auswahl an den eIAM Trustbroker.
8. Der Trustbroker stellt einen SAML 2.0 AuthnRequest aus welcher in einem selfsubmitting HTML Form mit der Destination IdP an den Webbrowser des Benutzers geschickt wird.
9. Der Webbrowser des Benutzers sendet das HTML Form mit dem AuthnRequest per Java Script automatisch an den Identity Provider (IdP).
10. Der Identity Provider prüft den AuthnRequest darauf, ob dieser von einem Aussteller stammt, mit dem ein Vertrauensverhältnis besteht.
11. Falls die Prüfung des AuthnRequest erfolgreich war, führt der IdP die Authentifizierung des Benutzers durch.
12. Der Benutzer wird vom Identity Provider authentifiziert - Der Ablauf der Authentifizierung ist abhängig vom gewählten IdP unterschiedlich und nicht im Scope dieses Beschreibung.
13. Überprüfen des/der Authentifizierungsmittel auf dem IdP - Der detaillierte Ablauf der Authentifizierung ist abhängig vom gewählten IdP unterschiedlich und nicht im Scope dieses Guide.
14. Nach erfolgreicher Authentifizierung des Benutzers stellt der IdP eine SAML 2.0 Response mit einer Assertion aus. Die SAML Response wird in einem selfsubmitting HTML Form an den Webbrowser des Benutzers geschickt.
15. Der Webbrowser des Benutzers sendet das HTML Form mit der SAML Response per Java Script automatisch an den eIAM Trustbroker.
16. Der eIAM Trustbroker prüft die eingehende SAML Response und konsumiert die darin enthaltenen Attribute.
17. Der Trustbroker sucht den durch den Identity Provider authentifizierten Benutzer im eIAM-AM und fragt von diesem zusätzliche Attribute ab, welche über den Benutzer im eIAM-AM geführt werden wie Benutzer ID, Abteilungszugehörigkeit, Berechtigungsrollen etc.
18. Der Trustbroker stellt eine SAML 2.0 Response mit einer Assertion aus, welche Attribute enthält, die einerseits vom Identity Provider stammen und andererseits vom aus dem eIAM-AM.
19. Die SAML Response wird in einem selfsubmitting HTML Form an den Webbrowser des Benutzers geschickt.
20. Der Webbrowser des Benutzers sendet das HTML Form mit der SAML Response per Java Script automatisch an den PEP.
21. Der RP-PEP prüft die erhaltende SAML Response und die enthaltene Assertion. Ist die Prüfung erfolgreich, so werden die Attribute aus der Assertion vom PEP konsumiert und ein Security Kontext (Session) erstellt.
22. Der RP-PEP senden an den Webbrowser des Benutzers einen HTTP Redirect auf die vom Benutzer ursprünglich aufgerufene URL (URL aus dem RelayState). Mit dieser HTTP Response wird ein permanentes (für die Laufzeit der Browser Session) Session Cookie des RP-PEP auf dem Browser des Benutzers gesetzt.
23. Der Webbrowser des Benutzers ruft die URL auf welche er redirektet wurde.
24. Der RP-PEP prüft, ob die definierte Policy eingehalten ist. Dafür muss der Request von einem authentifizierten Benutzer stammen, die Authentifizierung muss mit der für den Zugriff auf diese Ressource nötigen Stärke durchgeführt worden sein und der Benutzer muss die für den Zugriff auf die Ressource nötige grobgranulare Rolle besitzen. War die Prüfung erfolgreich, sendet der RP-PEP den Request weiter an die Applikation.

Session Aufbau zwischen Applikation und RP-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.

Bemerkung:
Die Applikation kann über den RP-PEP keine Reauthentifizierung des Benutzers einer laufenden PEP Session forcieren (durch das Setzen des ‚ForceAuthn‘ Attributs im AuthnRequest).

SP initiated Web SSO - Ablauf
Im Folgenden ist der Aufbau des Security Kontext (Session) zwischen der SAML 2.0 fähigen Applikation innerhalb der Netze der Bundesverwaltung und dem RP-PEP beschrieben. Ausgangslage ist eine bereits bestehende Session des Benutzers auf dem RP-PEP. Aus Sicht der Applikation ist der PEP in der Rolle eines SAML 2.0 Identity Provider (IdP). Aus Sicht des RP-PEP ist die Applikation ein SAML 2.0 Service Provider (SP). Sind hinter dem RP-PEP mehrere Applikationen integriert, so muss jede der Applikationen für sich einen Security Kontext mit dem beschriebenen Ablauf aufbauen, wenn ein solcher von der Applikation benötigt wird.

Session Aufbau Applikation-PEP

1. Request des Benutzers innerhalb einer bereits etablierten Session auf dem RP-PEP.
   
2. Request wird an die Applikation weitergeleitet.
3. Die Applikation prüft den Request und stellt fest, dass ein Security Kontext (Session) benötigt wird aber noch keiner existiert.
4. Die Applikation erstellt einen SAML 2.0 AuthnRequest und übermittelt diesen in einem selfsubmitting HTML Form an den RP-PEP.
5. Der RP-PEP leitet den SAML 2.0 AuthnRequest an den Webbrowser des Benutzers weiter.
6. Der Webbrowser des Benutzers sendet das HTML Form per Java Script automatisch an die im Form definierte URL auf dem eIAM-Web PEP.
7. Der RP-PEP prüft den AuthnRequest und erstellt wenn die Prüfung erfolgreich war eine SAML 2.0 Response welche eine Assertion mit Angaben den Benutzer (Subjekt) und Attribute enthält. Die Quelle dieser Angaben ist die bestehende Session des Benutzers auf dem RP-PEP.
8. Die SAML Response wird in ein selfsubmitting HTML Form gepackt und an den Webbrowser des Benutzers geschickt.
9. Der Webbrowser des Benutzers sendet das HTML Form per Java Script automatisch an die im Form definierte Destination auf dem eIAM-Web PEP. Die URL an welche dieses Formular gepostet werden muss, ist die URL des Assertion Consumer Service der Applikation wie diese über den RP-PEP erreicht werden kann.
10. Der RP-PEP sendet das HTML Form weiter an die URL des Assertion Consumer Service der Applikation.
11. Die Applikation prüft die SAML 2.0 Response sowie die Assertion und erstellt im Erfolgsfall einen Security Kontext (Session).
12. Die Applikation redirektet den Web Browser des Benutzers auf die URL aus dem RelayState oder auf einen anderen von ihr definierten URI. Mit dieser Response setzt die Applikation ein Session Cookie welches auf dem RP-PEP gecached wird (Cookies der Applikation werden per Default auf dem RP-PEP gecached und nur zwischen RP-PEP und Applikation ausgetauscht).
13. Der RP-PEP schickt die Response mit dem Redirect der Applikation weiter an den Webbrowser.
14. Der Webbrowser ruft die URL auf welche er redirektet wurde.
15. Der RP-PEP leitet den Request des Webbrowsers an die Applikation weiter. Dabei werden Cookies welche die Applikation in früheren Schritten gesetzt hat mitgeschickt.
16. Die Response HTTP Response der Applikation wird an den RP-PEP geschickt.
17. Die HTTP Response wird vom RP-PEP an den Web Browser geschickt.
18. Und folgende – Folge Requests laufen nun wie unter Punkt 14 – 17 beschrieben.

• 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 RP-PEP (nur authentifizierte und autorisierte Requests auf die Applikation lassen) verletzt werden muss. Diese Logik muss somit nicht statisch auf dem RP-PEP implementiert werden. Somit sind bei Änderungen in der Applikation keine Änderungen auf dem RP-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 RP-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.