diff options
Diffstat (limited to 'id/server/doc')
| -rw-r--r-- | id/server/doc/handbook/config/config.html | 44 | ||||
| -rw-r--r-- | id/server/doc/handbook/install/install.html | 9 |
2 files changed, 36 insertions, 17 deletions
diff --git a/id/server/doc/handbook/config/config.html b/id/server/doc/handbook/config/config.html index 0361442ac..84590aaee 100644 --- a/id/server/doc/handbook/config/config.html +++ b/id/server/doc/handbook/config/config.html @@ -1724,20 +1724,6 @@ Soll die Bürgerkartenauswahl weiterhin, wie in MOA-ID 1.5.1 im Kontext der <td align="center">X</td> <td>Über diese Funktion können drei zusätzliche SecurtityLayer-Request Templates für diese Online-Applikation definiert werden. Diese hier definierten Templates dienen als zusätzliche WhiteList für Templates welche im „StartAuthentication“ Request mit dem Parameter „template“ übergeben werden. Sollte im „StartAuthentication“ Request der Parameter „template“ fehlen, es wurde jedoch eine „bkuURL“ übergeben, dann wird für den Authentifizierungsvorgang das erste Template in dieser Liste verwendet. Detailinformationen zum <a href="./../protocol/protocol.html#allgemeines_legacy">Legacy Request</a> finden Sie im Kapitel Protokolle.</td> </tr> - <tr> - <td>BKU-Selection Template</td> - <td> </td> - <td align="center">X</td> - <td align="center">X</td> - <td>Dieses Feld erlaubt die Konfiguration eines online-applikationsspezifischen Templates für die Bürgerkartenauswahl. Dieses Template muss in die Konfiguration hochgeladen werden und muss die Mindestanforderungen aus <a href="#import_template_bku">Kapitel 4.1</a> umsetzen. Da diese Templates direkt in den Authentifizierungsprozess eingreifen und diese somit eine potentielle Angriffsstelle für Cross-Site Scripting (XSS) bieten wird die Verwendung von online-applikationsspezifischen Templates nicht empfohlen. </td> - </tr> - <tr> - <td>Send-Assertion Template</td> - <td> </td> - <td align="center">X</td> - <td align="center">X</td> - <td>Dieses Feld erlaubt die Konfiguration eines online-applikationsspezifischen Templates für die zusätzliche Anmeldeabfrage im Falle einer Single Sign-On Anmeldung. Dieses Template muss in die Konfiguration hochgeladen werden und muss die Mindestanforderungen aus <a href="#import_template_sso">Kapitel 4.2</a> umsetzen. Da diese Templates direkt in den Authentifizierungsprozess eingreifen und diese somit eine potentielle Angriffsstelle für Cross-Site Scripting (XSS) bieten wird die Verwendung von online-applikationsspezifischen Templates nicht empfohlen.</td> - </tr> </table> <h4><a name="konfigurationsparameter_oa_testcredentials" id="uebersicht_zentraledatei_aktualisierung10"></a> 3.2.3 Test Identitäten</h4> <p>In diesem Abschnitt können für diese Online-Applikation Testidentitäten erlaubt werden. Diese Testidentitäten können auch bei produktiven Instanzen freigeschalten werden, da die Unterschiedung zwischen Produkt- und Testidentität anhand einer speziellen OID im Signaturzertifikat der Testidentität getroffen wird. Folgende Konfigurationsparameter stehen hierfür zur Verfügung.</p> @@ -2007,6 +1993,13 @@ Soll die Bürgerkartenauswahl weiterhin, wie in MOA-ID 1.5.1 im Kontext der <td align="center"> </td> <td>Zertifikat mit dem die Metadaten der Online-Applikation signiert sind. Dieses wird benötigt um die Metadaten zu verifizieren.</td> </tr> + <tr> + <td>SAML2 Post-Binding Template</td> + <td> </td> + <td align="center">X</td> + <td align="center">X</td> + <td>Pfad zum online-applikationsspezifischen Template für SAML2 (PVP2 S-Profil) http POST-Binding. Relative Pfadangaben werden dabei relativ zum Verzeichnis, in dem sich die MOA-ID-Auth Basiskonfigurationsdatei befindet, interpretiert. Das Template kann ausschließlich aus dem Dateisystem geladen werden.</td> + </tr> </table> <h5><a name="konfigurationsparameter_oa_protocol_openIDConnect" id="uebersicht_zentraledatei_aktualisierung27"></a>3.2.8.3 OpenID Connect</h5> <p>In diesem Bereich erfolgt die applikationsspezifische Konfiguration für OpenID Connect (OAuth 2.0). </p> @@ -2074,7 +2067,30 @@ wenn die individuelle Security-Layer Transformation den Formvorschriften der Sp <td align="center">X</td> <td>Wird diese Option gewählt wird im AuthBlock, welcher im Anmeldevorgang signiert wird, keine bPK oder wbPK dargestellt.</td> </tr> + <tr> + <td>BKU-Selection Template</td> + <td> </td> + <td align="center">X</td> + <td align="center">X</td> + <td>Dieses Feld erlaubt die Konfiguration eines online-applikationsspezifischen Templates für die Bürgerkartenauswahl. Dieses Template muss in die Konfiguration hochgeladen werden und muss die Mindestanforderungen aus <a href="#import_template_bku">Kapitel 4.1</a> umsetzen. Da diese Templates direkt in den Authentifizierungsprozess eingreifen und diese somit eine potentielle Angriffsstelle für Cross-Site Scripting (XSS) bieten wird die Verwendung von online-applikationsspezifischen Templates nicht empfohlen. </td> + </tr> + <tr> + <td>Send-Assertion Template</td> + <td> </td> + <td align="center">X</td> + <td align="center">X</td> + <td>Dieses Feld erlaubt die Konfiguration eines online-applikationsspezifischen Templates für die zusätzliche Anmeldeabfrage im Falle einer Single Sign-On Anmeldung. Dieses Template muss in die Konfiguration hochgeladen werden und muss die Mindestanforderungen aus <a href="#import_template_sso">Kapitel 4.2</a> umsetzen. Da diese Templates direkt in den Authentifizierungsprozess eingreifen und diese somit eine potentielle Angriffsstelle für Cross-Site Scripting (XSS) bieten wird die Verwendung von online-applikationsspezifischen Templates nicht empfohlen.</td> + </tr> + <tr> + <td>Vollmachtenservice Auswahlseite Template</td> + <td> </td> + <td align="center">X</td> + <td align="center">X</td> + <td>Pfad zum online-applikationsspezifischen Template zur Auswahl des gewünschten Vollmachtenservices. Relative Pfadangaben werden dabei relativ zum Verzeichnis, in dem sich die MOA-ID-Auth Basiskonfigurationsdatei befindet, interpretiert. Das Template kann ausschließlich aus dem Dateisystem geladen werden.</td> + </tr> </table> +<h5> </h5> +<h5> </h5> <h5><a name="konfigurationsparameter_oa_additional_formular" id="uebersicht_zentraledatei_aktualisierung29"></a>3.2.9.1 Login-Fenster Konfiguration</h5> <p>Diese Konfigurationsparameter bieten zusätzliche Einstellungen für eine Anpassung der Bürgerkartenauswahl welche von MOA-ID-Auth generiert wird. Zur besseren Handhabung werden die angegebenen Parameter direkt in einer Vorschau dargestellt. diff --git a/id/server/doc/handbook/install/install.html b/id/server/doc/handbook/install/install.html index aa4114539..db96cda3c 100644 --- a/id/server/doc/handbook/install/install.html +++ b/id/server/doc/handbook/install/install.html @@ -235,8 +235,8 @@ https://<host>:<port>/egiz-configuration-webapp/</pre> <h5><a name="webservice_basisinstallation_logging_format" id="webservice_basisinstallation_logging_format"></a>2.1.3.1 Format der Log-Meldungen</h5> <p> Anhand einer konkreten Log-Meldung wird das Format der MOA SP/SS Log-Meldungen erläutert: </p> <pre> -INFO | 01 21:25:26,540 | Thread-3 | TID=1049225059594-100 NID=node1 - MSG=Starte neue Transaktion: TID=1049225059594-100, Service=SignatureVerification + INFO | 2017-09-18 10:29:22,904 | SID-7947921060553739539 | TID-4708232418268334030 | https://sso.demosp.at/handysignatur + | ajp-nio-28109-exec-7 | No SSO Session cookie found </pre> <p> Der Wert <code>INFO</code> besagt, dass die Log-Meldung im Log-Level <code>INFO</code> entstanden ist. Folgende Log-Levels existieren:</p> <ul> @@ -257,7 +257,10 @@ INFO | 01 21:25:26,540 | Thread-3 | TID=1049225059594-100 NID=node1 </li> </ul> <p>Der nächste Wert <code>01 21:25:26,540</code> gibt den Zeitpunkt an, zu dem die Log-Meldung generiert wurde (in diesem Fall den 1. Tag im aktuellen Monat, sowie die genaue Uhrzeit). </p> - <p> Der Wert <code>Thread-3</code> bezeichnet den Thread, von dem die Anfrage bearbeitet wird.</p> + <p>Der Wert <code>SID-7947921060553739539</code> bezeichnet die SessionID, welche diesem Request zugeordnet wurde. Eine SessionID ist innerhalb einer SSO auch über mehrere Authentifizierungsrequests eindeutig. Das Loggen der SessionID kann mittels <code>%X{sessionId}</code> in der log4j Konfiguration gesetzt werden</p> + <p>Der Wert <code>TID-4708232418268334030</code> bezeichnet die TransactionsID, welche diesem Request zugeordnet wurde. Eine TransactionsID ist innerhalb eines Authentifizierungsrequests eindeutig. Das Loggen der TransactionsID kann mittels <code>%X{transactionId}</code> in der log4j Konfiguration gesetzt werden</p> + <p>Der Wert <code>https://sso.demosp.at/handysignatur</code> bezeichnet die Online Applikation (eindeutiger Identifier dieses Service Providers) für welchen dieser Authentifizierungsrequest durchgeführt wird. Das Loggen des OA Identifiers kann mittels <code>%X{oaId}</code> in der log4j Konfiguration gesetzt werden</p> + <p>Der Wert <code>ajp-nio-28109-exec-7</code> bezeichnet den Thread, von dem die Anfrage bearbeitet wird.</p> <p> Der Rest der Zeile einer Log-Meldung ist der eigentliche Text, mit dem das System bestimmte Informationen anzeigt. Im Fehlerfall ist häufig ein Java Stack-Trace angefügt, der eine genauere Ursachen-Forschung ermöglicht.</p> <h5> <a name="webservice_basisinstallation_logging_messages" id="webservice_basisinstallation_logging_messages"></a>2.1.3.2 Wichtige Log-Meldungen</h5> <p> Neben den im Abschnitt <a href="#webservice_basisinstallation_installation_tomcatstartstop_verify">2.1.2.4.3</a> beschriebenen Log-Meldungen, die anzeigen, ob das Service ordnungsgemäß gestartet wurde, geben nachfolgenden Log-Meldungen Aufschluss über die Abarbeitung von Anfragen. </p> |