Update MOA-ID handbook (Typos, etc.)

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 &Uuml;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>&nbsp;</p>
 <ol>
   <li>Die Benutzerin oder der Benutzer ist bereits an einer Online Applikation (Application 1) angemeldet und m&ouml;chte sich nun an einer zweiten Online Applikation (Application 2) mittels Single Sign On anmelden. Nach dem Click auf die entsprechende Login Schaltfl&auml;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&uuml;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&uuml;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&uuml;r die Benutzerin oder den Benutzer eine aktive SSO Session h&auml;lt.</li>
     <li><em>redirecturl</em>: URL an welche der Benutzer anschlie&szlig;end weitergeleitet wird.</li>
   </ul>
-  <li>Das Redirect Servlet validiert den Request. Hierbei wird gepr&uuml;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&uuml;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 &uuml;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&uuml;r MOA-ID 2 welche SessionTokken f&uuml;r die Benutzerin oder den Benutzer enth&auml;lt. In diesem Schritt werden jedoch noch keine personenbezogenen Daten ausgetauscht.</li>
+  <li>MOA-ID 1 validiert den Authentifizierungsrequest und generiert eine Assertion f&uuml;r MOA-ID 2 welche Session-Token f&uuml;r die Benutzerin oder den Benutzer enth&auml;lt. In diesem Schritt werden jedoch noch keine personenbezogenen Daten ausgetauscht.</li>
   <li>Die Assertion wird an MOA-ID 2 zur&uuml;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&uuml;rgerkarte oder Handy-Signatur durchgef&uuml;hrt.</li>
   <li>MOA-ID 2 generiert einen Attribut Request mit den von Online Applikation 2 angeforderten Attributen und sendet diesen &uuml;ber SOAP Binding an MOA-ID 1.</li>
   <li>MOA-ID 1 generiert eine Assertion mit den angeforderten Attributen f&uuml;r Online Applikation 2 und sendet diese an MOA-ID 2.</li>
@@ -195,7 +195,7 @@
 	&amp;bkuURI=&lt;bku-url&gt;
   &amp;interIDP=&lt;IDP EntityID&gt;
 &gt;</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&auml;tzliche Parameter <em>interIDP</em> und eine Redirect-URL <em>redirecturl</em> an ein Service der MOA-ID-Auth Instanz &uuml;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&szlig;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&auml;tzlichen Parameter <em>interIDP</em> enth&auml;lt, da dieser &uuml;ber das zuvor gesetzte http Cookie vom Modul MOA-ID-Auth ausgewertet wird. </p>
 <table width="1247" border="1">
   <tr>