add configuration parameter to disable 'targetFriendlyName' validation in signed AuthBlock

1 files changed, 8 insertions, 1 deletions

diff --git a/id/server/doc/handbook/config/config.html b/id/server/doc/handbook/config/config.html
index 8b2f6a632..9e70c073d 100644
--- a/id/server/doc/handbook/config/config.html
+++ b/id/server/doc/handbook/config/config.html
@@ -423,6 +423,13 @@ UNIX: moa.id.configuration=file:C:/Programme/apache/tomcat-8.x.x/conf/moa-id/moa
       <p><strong>Hinweis: </strong>Workaround, da der httpClient der openSAML2 Implementierung kein SNI (Server Name Indication) unterst&uuml;tzt.</p></td>
     </tr>
     <tr>
+      <td>configuration.validate.authblock.targetfriendlyname</td>
+      <td>true / false</td>
+      <td>Hiermit kann die &Uuml;berpr&uuml;fung des 'TargetFriendlyName', welcher Teil des vom Benutzer signierten Authblock ist, deaktiviert werden.  Eine Deaktivierung hat keinen Einfluss auf die Sicherheit des Authentifizierungsvorgangs mittels qualifizierter Signatur, jedoch kann der 'TargetFriendlyName im Authblock nicht als gesichert betrachtet werden.' Die Validierung ist deaktiviert wenn der Parameter auf <code>false</code> gesetzt wird.<br>
+        <strong>Hinweis:</strong> Hierbei handelt es sich um einen Workaround f&uuml;r Systeme auf denen die Validierung des 'TargetFriendlyName' wegen Problemen mit der Zeichencodierung fehlschl&auml;gt, die Signatur des AuthBlocks jedoch g&uuml;ltig ist.<br>
+        <strong>Defaultwert:</strong> true</td>
+    </tr>
+    <tr>
       <td>configuration.monitoring.active</td>
       <td>true / false</td>
       <td>Aktiviert das Modul f&uuml;r internes Monitoring / Testing.</td>
@@ -2190,7 +2197,7 @@ Alle in diesem Abschnitt angegebenen Parameter sind Optional und werden bei Beda
 <p><strong>Hinweis:</strong> Bei Verwendung einer online-applikationsspezifischen B&uuml;rgerkartenauswahl stehen alle Parameter die die B&uuml;rgerkartenauswahl betreffen nicht zur Verf&uuml;gung.</p>
 <p><strong>Hinweis:</strong> Bei Verwendung eines online-applikationsspezifischen Security-Layer-Request Templates stehen alle Parameter die das SL-Template betreffen nicht zur Verf&uuml;gung.</p>
 <h5><a name="service_revisionslogging" id="uebersicht_zentraledatei_aktualisierung11"></a>3.2.10 Revisionslogging</h5>
-<p>Ab MOA-ID 3.x steht ein erweitertes speziell f&uuml;r Revisionsaufgaben abgestimmtest Logging zur Verf&uuml;gung. &Uuml;ber dieses Feld k&ouml;nnen die zu loggenden Events als CSV codierte Eventcodes konfiguriert werden. Werden keine Eventcodes konfiguriert wird eine in MOA-ID hinterlegte Defaultkonfiguration verwendet. Eine Liste aller m&ouml;glichen Eventcodes finden Sie <a href="../additional/additional.html#revisionslog">hier</a>.</p>
+<p>Ab MOA-ID 3.x steht ein erweitertes speziell f&uuml;r Revisionsaufgaben abgestimmtest Logging zur Verf&uuml;gung. &Uuml;ber dieses Feld k&ouml;nnen die zu loggenden Events spezifisch nach Online Applikationen als CSV codierte Eventcodes konfiguriert werden. Hierf&uuml;r muss die online-applikationsspezifische Konfiguration des Loggings mittels Checkbox aktiviert und zumindesdt ein Eventcode definiert werden. Werden keine Eventcodes konfiguriert oder wird das OA spezifische Verhalten nicht aktiviertwird eine in MOA-ID hinterlegte Defaultkonfiguration verwendet. Eine Liste aller m&ouml;glichen Eventcodes finden Sie <a href="../additional/additional.html#revisionslog">hier</a>.</p>
 <h3><a name="import_export" id="uebersicht_zentraledatei_aktualisierung4"></a>3.3 Import / Export</h3>
 <p>&Uuml;er diese Funktionalit&auml;t besteht die M&ouml;glichkeit eine bestehende MOA-ID 2.x.x
 Konfiguration in MOA-ID 3.x zu importieren. Zus&auml;tzlich besteht die M&ouml;glichkeit eine MOA-ID-Auth 3.0