SAML 2.0 Integrationmuster RP-PEP
Dieses Integrationsmuster (RP-PEP) kann nur für Dienste innerhalb von BV-Net gewählt werden. Es bietet eine höhere Sicherheit und wird benötigt, wenn Ihr Schutzstufe hoch ist (Si00
SAML 2.0 Integration
Die nachstehende Abbildung zeigt vereinfacht den Ablauf und die involvierten Komponenten des Zugriffs eines noch nicht authentifizierten Benutzers auf eine Web Applikation, die über die eIAM-Web Komponente (RP-PEP) geschützt ist. Die einzelnen Schritte sind nachfolgend beschrieben.-
- Benutzerzugriff auf eine geschützte Ressource
| Nr. | Aktion | Beschreibung |
|---|---|---|
| 1 | Benutzer versucht auf die geschützte Ressource einer Web Applikation zuzugreifen | Der eIAM-Web PEP erkennt, dass die Ressource auf die zugegriffen werden soll geschützt ist und dass der Zugriff von einem noch nicht authentifizierten Benutzer erfolgt |
| 2 | SAML AuthnRequest an Web Browser des Benutzers | Der eIAM-Web PEP stellt einen signierten SAML 2.0 AuthnRequest zuhanden des eIAM Trustbroker aus und schickt diesen als selbst übermittelndes Formular an den Web Browser des Benutzers. |
| 3 | SAML AuthnRequest an eIAM Trustbroker | Der Browser des Benutzers schickt das Formular per Browser POST automatisch mittels Java Script an den eIAM Trustbroker. |
| 4 | Home Realm Discovery und SAML AuthnRequest an Web Browser des Benutzers | Der eIAM Trustbroker führt ein Home Realm Discovery aus (Ermitteln des zu verwendenden IdP) und ermittelt den für die Authentifizierung zu verwendenden IdP. Der eIAM Trustbroker stellt einen signierten SAML 2.0 AuthnRequest zuhanden des IdP aus und schickt diesen als selbst übermittelndes Formular an den Web Browser des Benutzers. |
| 5 | SAML AuthnRequest an IdP | Der Browser des Benutzers schickt das Formular per Browser POST automatisch mittels Java Script an den IdP. |
| 6 | Authentifizierung des Benutzers | Der IdP führt eine je nach Ausprägung unterschiedliche Authentifizierung des Benutzers durch. Ist die Authentifizierung erfolgreich, so erstellt der IdP eine SAML Response aus welche eine signierte Assertion mit Angaben über das Subject sowie Attribute des Subjects (auch Claims genannt) enthält. |
| 7 | SAML Response an Web Browser des Benutzers | Der IdP schickt die SAML Response als selbst übermittelndes Formular an den Web Browser des Benutzers. |
| 8 | SAML Response an eIAM Trustbroker | Der Browser des Benutzers schickt das Formular per Browser POST automatisch mittels Java Script an den eIAM Trustbroker. Der eIAM Trustbroker sucht das Subjekt aus der SAML Assertion im eIAM-AM. Der eIAM Trustbroker reichert die SAML Assertion des IdP mit weiteren Attributen (z.B. BenutzerId und Berechtigungsrollen) aus dem eIAM-AM an und erstellt eine SAML Response mit einer SAML Assertion zuhanden des eIAM-Web PEP. |
| 9 | SAML Response an Web Browser des Benutzers | Der eIAM Trustbroker schickt die SAML Response als selbst übermittelndes Formular an den Web Browser des Benutzers. |
| 10 | SAML Response an eIAM-Web PEP | Der Browser des Benutzers schickt das Formular per Browser POST automatisch mittels Java Script an den eIAM-Web PEP. |
| 11 | Prüfung SAML Assertion und Redirect auf RelayState | Der eIAM-Web PEP prüft die SAML Response und die Assertion. Im Erfolgsfall erstellt der eIAM-Web PEP eine Session mit dem Benutzer. Der eIAM-Web PEP leitet den Benutzer auf die URL aus dem RelayState um. Dies ist die URL welche der Benutzer ursprünglich (vor der Authentifizierung) aufgerufen hatte. Mit dieser Response wird ein Session Cookie ausgestellt, mit welchem die Session zwischen Client und PEP verfolgt wird. |
| 12 | Web Browser des Benutzers versucht erneut auf die geschützte Ressource der Web Applikation zuzugreifen | Bei diesem Request besteht nun eine Session mit dem Benutzer. Der PEP prüft ob der Benutzer autorisiert ist auf diese Ressource zuzugreifen und leitet im Erfolgsfall den Request des Benutzers an die Applikation weiter. |
| 13 | Applikation prüft Berechtigung des Benutzers | Die Applikation erkennt, dass der Benutzer auf einen geschützten Bereich zugreifen will, der Benutzer aus ihrer Sicht jedoch noch nicht authentifiziert ist. Die Applikation stellt einen signierten SAML 2.0 AuthnRequest zuhanden es PEP aus und schickt diesen als selbst übermittelndes Formular an den Web Browser des Benutzers. |
| 14 | SAML AuthnRequest an PEP | Der Browser des Benutzers schickt das Formular per Browser POST automatisch mittels Java Script an den eIAM-Web PEP. |
| 15 | SAML Assertion für Applikation | Der eIAM-Web PEP prüft den eingehenden SAML AuthnRequest und verbindet diesen über das Session Cookie mit der bestehenden Session des Benutzers. Der eIAM-Web PEP stellt eine SAML Response mit einer Assertion aus, die zuhanden der Applikation ausgestellt ist und schickt diese als selbst übermittelndes Formular an den Web Browser des Benutzers. |
| 16 | SAML Response an Applikation | Der Browser des Benutzers schickt das Formular per Browser POST automatisch mittels Java Script an die Applikation |
| 17 | Prüfung SAML Assertion und Redirect auf RelayState | Die Applikation prüft die SAML Response und die Assertion. Im Erfolgsfall erstellt die Applikation eine Session mit dem Benutzer. Die Applikation leitet den Benutzer auf die URL aus dem RelayState um. Dies ist die URL welche der Benutzer ursprünglich (vor der Authentifizierung) aufgerufen hatte. Mit dieser Response wird ein Session Cookie ausgestellt, mit welchem die Session zwischen Client und Applikation verfolgt wird. |
| 18 | Web Browser des Benutzers versucht erneut auf die geschützte Ressource der Web Applikation zuzugreifen | Der eIAM-Web PEP lässt den Request auf die Applikation durch, da eine gültige Session besteht und der Benutzer die nötige grobgranulare Berechtigungsrolle besitzt. Die Applikation lässt den Request zu, da eine gültige Session besteht und der Benutzer die nötige feingranulare Rolle besitzt um auf der Applikation die gewünschte Operation durchzuführen. |
| 19 | Response an den Web Browser des Benutzers | Die Applikation sendet die Antwort an den Web Browser des Benutzers. |