diff options
Diffstat (limited to 'id/server/doc/handbook/interfederation')
| -rw-r--r-- | id/server/doc/handbook/interfederation/interfederation.html | 12 |
1 files changed, 6 insertions, 6 deletions
diff --git a/id/server/doc/handbook/interfederation/interfederation.html b/id/server/doc/handbook/interfederation/interfederation.html index 4e4f35c54..d30c93008 100644 --- a/id/server/doc/handbook/interfederation/interfederation.html +++ b/id/server/doc/handbook/interfederation/interfederation.html @@ -33,7 +33,7 @@ <li><a href="#useage">Integration in bestehende Systeme</a> <ol> <li><a href="#usage_direct">Direkte Übermittlung im Authentifizierungsrequest</a></li> - <li><a href="#usage_redirect">Verwendung des Redirekt Servlets</a></li> + <li><a href="#usage_redirect">Verwendung des Redirect Servlets</a></li> </ol> </li> <li><a href="#vidp">STORK VIDP Konfiguration</a></li> @@ -57,12 +57,12 @@ <p> </p> <ol> <li>Die Benutzerin oder der Benutzer ist bereits an einer Online Applikation (Application 1) angemeldet und möchte sich nun an einer zweiten Online Applikation (Application 2) mittels Single Sign On anmelden. Nach dem Click auf die entsprechende Login Schaltfläche wird der Anmeldevorgang gestartet.</li> - <li>Es erfolgt ein SSO Login Request auf ein Redirekt Servelt von MOA-ID 2. Dieser Request beinhaltet einen eindeutigen Identifier für den IDP welcher eine aktive SSO Session besitzt und einen Redirect URL auf ein Service von Online Applikation 2 welches den eigentlichen online-applikationsspezifischenAuthentifizierungsrequest erzeugt. Hierbei werden folgende zwei http GET Parameter ausgewertet: </li> + <li>Es erfolgt ein SSO Login Request auf ein Redirect Servlet von MOA-ID 2. Dieser Request beinhaltet einen eindeutigen Identifier für den IDP welcher eine aktive SSO Session besitzt und einen Redirect URL auf ein Service von Online Applikation 2 welches den eigentlichen online-applikationsspezifischen Authentifizierungsrequest erzeugt. Hierbei werden folgende zwei http GET Parameter ausgewertet: </li> <ul> <li><em>interIDP</em>: eindeutiger Identifier des interfederation IDP welcher für die Benutzerin oder den Benutzer eine aktive SSO Session hält.</li> <li><em>redirecturl</em>: URL an welche der Benutzer anschließend weitergeleitet wird.</li> </ul> - <li>Das Redirect Servlet validiert den Request. Hierbei wird geprüft ob die Redirekt URL zu einer bei MOA-ID 2 registrierten Online Applikation passt. Wenn ja, wird der eindeutige Identifier des IDP gespeichert. </li> + <li>Das Redirect Servlet validiert den Request. Hierbei wird geprüft ob die Redirect URL zu einer bei MOA-ID 2 registrierten Online Applikation passt. Wenn ja, wird der eindeutige Identifier des IDP gespeichert. </li> <li>Die Benutzerin oder der Benutzer wird an die im Request angegebene URL, welche den eigentlichen Authentifizierungsrequest erzeugt, weitergeleitet.</li> <li>Online Applikation zwei erzeugt den Authentifizierungsrequest.</li> <li>Der Authentifizierungsrequest wird über den Browser an MOA-ID 2 gesendet. <br> @@ -70,9 +70,9 @@ <li>Validierung des Authentifizierungsrequests von Online Applikation zwei.</li> <li>Wurde der Parameter <em>interIDP</em> gesetzt erfolgt keine lokale Authentifizierung. In diesem Fall wird ein interfederation Authentifizierungsrequest generiert welcher als IDP MOA-ID 1 verwendet.</li> <li>Der interfederation Authentifizierungsrequest wird an MOA-ID 1 gesendet.</li> - <li>MOA-ID 1 validiert den Authentifizierungsrequest und generiert eine Assertion für MOA-ID 2 welche SessionTokken für die Benutzerin oder den Benutzer enthält. In diesem Schritt werden jedoch noch keine personenbezogenen Daten ausgetauscht.</li> + <li>MOA-ID 1 validiert den Authentifizierungsrequest und generiert eine Assertion für MOA-ID 2 welche Session-Token für die Benutzerin oder den Benutzer enthält. In diesem Schritt werden jedoch noch keine personenbezogenen Daten ausgetauscht.</li> <li>Die Assertion wird an MOA-ID 2 zurückgesendet.</li> - <li>MOA-ID 2 validiert die Assertion und extrahiert das SessionTokken. <br> + <li>MOA-ID 2 validiert die Assertion und extrahiert das Session-Token. <br> <strong>Hinweis:</strong> Sollte die Validierung der Assertion fehlschlagen oder keine aktive SSO Session bei MOA-ID 1 existieren wird eine lokale Authentifizierung der Benutzerin oder des Benutzers mittels Bürgerkarte oder Handy-Signatur durchgeführt.</li> <li>MOA-ID 2 generiert einen Attribut Request mit den von Online Applikation 2 angeforderten Attributen und sendet diesen über SOAP Binding an MOA-ID 1.</li> <li>MOA-ID 1 generiert eine Assertion mit den angeforderten Attributen für Online Applikation 2 und sendet diese an MOA-ID 2.</li> @@ -195,7 +195,7 @@ &bkuURI=<bku-url> &interIDP=<IDP EntityID> ></pre> -<h2><a name="usage_redirect" id="konfigurationsparameter_allgemein_bku9"></a>3.2 Verwendung des Redirekt Servlets</h2> +<h2><a name="usage_redirect" id="konfigurationsparameter_allgemein_bku9"></a>3.2 Verwendung des Redirect Servlets</h2> <p>Bei dieser Variante wird der zusätzliche Parameter <em>interIDP</em> und eine Redirect-URL <em>redirecturl</em> an ein Service der MOA-ID-Auth Instanz übermittelt. Dieses Service validiert alle Parameter und hinterlegt den Parameter <em>interIDP</em> in einem http Cookie im Browser der Benutzerin oder des Benutzers. Anschließend erfolgt ein Redirect an die im Parameter redirecturl angegebene Service welches den eigentlichen Authentifizierungsrequest erzeugt und an die MOA-ID-Auth Instanz sendet. In diesem Fall ist es nicht erforderlich dass der Authentifizierungsrequest den zusätzlichen Parameter <em>interIDP</em> enthält, da dieser über das zuvor gesetzte http Cookie vom Modul MOA-ID-Auth ausgewertet wird. </p> <table width="1247" border="1"> <tr> |