WS-Federation im Netze der BVerw
Dieses Dokument richtet sich an Projektleiter, Applikationsverantwortliche, Entwickler, Architekten und Integrationsmanager, welche Applikationen mit dem Service eIAM innerhalb des Bundes Verwaltungsnetzes auf Basis des WS-Federation Identitätsprotokolls integrieren.
WS-FED Integration
Die nachstehende Abbildung zeigt vereinfacht den Ablauf und die involvierten Komponenten des Zugriffs eines noch nicht authentifizierten Benutzers auf eine Webapplikation in den Netzen der Bundesverwaltung, die über die eIAM-Web Komponente geschützt ist. Die einzelnen Schritte sind im Folgenden beschrieben.-
- eIAM Benutzerzugriff auf eine geschützte Ressource mit WS-Federation
| Nr. | Aktion | Beschreibung |
|---|---|---|
| 1 | Benutzer versucht auf die geschützte Ressource einer Webapplikation 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 Webbrowser 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 Webbrowser 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 Webbrowser 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 es IdP aus und schickt diesen als selbst übermittelndes Formular an den Webbrowser 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 Webbrowser des Benutzers | Der IdP schickt die SAML Response als selbst übermittelndes Formular an den Webbrowser 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 Webbrowser des Benutzers | Der eIAM Trustbroker schickt die SAML Response als selbst übermittelndes Formular an den Webbrowser 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 | Webbrowser des Benutzers versucht erneut auf die geschützte Ressource der Webapplikation 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 leitet den Webbrowser des Benutzers auf die WS-Federation Schnittstelle des eIAM-Web PEP um. |
| 14 | wsignin Request an PEP | Der Webbrowser des Benutzers ruft die WS-Federation Schnittstelle des eIAM-Web PEP mit den nötigen Parametern auf. |
| 15 | WS RequestSecurityToken-Response für Applikation | Der eIAM-Web PEP prüft den eingehenden wsignin Request und verbindet diesen über das Session Cookie mit der bestehenden Session des Benutzers. Der eIAM-Web PEP stellt eine RequestSecurityToken-Response mit einer SAML Assertion aus und schickt diese Response als selbst übermittelndes Formular an den Webbrowser des Benutzers. |
| 16 | WS RequestSecurityToken-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 Security Token Response und die enthaltene SAML Assertion. Im Erfolgsfall erstellt die Applikation eine Session mit dem Benutzer. Die Applikation leitet den Webbrowser des Benutzers auf eine URL ihrer Wahl um. Mit dieser Response wird ein Session Cookie ausgestellt, mit welchem die Session zwischen Client und Applikation verfolgt wird. |
| 18 | Webbrowser des Benutzers versucht erneut auf die geschützte Ressource der Webapplikation 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 ihrerseits 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 Webbrowser des Benutzers | Die Applikation sendet die Antwort an den Webbrowser des Benutzers. |