diff options
Diffstat (limited to 'id/server/doc/handbook')
| -rw-r--r-- | id/server/doc/handbook/config/config.html | 36 | ||||
| -rw-r--r-- | id/server/doc/handbook/index.html | 2 | ||||
| -rw-r--r-- | id/server/doc/handbook/interfederation/interfederation.html | 8 |
3 files changed, 40 insertions, 6 deletions
diff --git a/id/server/doc/handbook/config/config.html b/id/server/doc/handbook/config/config.html index e21aaf421..2d2709bcc 100644 --- a/id/server/doc/handbook/config/config.html +++ b/id/server/doc/handbook/config/config.html @@ -129,6 +129,7 @@ <li><a href="#konfigurationsparameter_oa_additional">Zusätzliche allgemeine Einstellungen</a> <ol> <li><a href="#konfigurationsparameter_oa_additional_formular">Login-Fenster Konfiguration</a></li> + <li><a href="#konfigurationsparameter_oa_additional_encbpk">Fremd-bPK Konfiguration</a></li> </ol> </li> </ol> @@ -1049,6 +1050,7 @@ https://<host>:<port>/moa-id-auth/MonitoringServlet</pre> <h3><a name="konfigurationsparameter_allgemein_sl-templates" id="konfigurationsparameter_allgemein_bku2"></a>3.1.3 Security-Layer Request Templates</h3> <p>Security-Layer (SL) Templates dienen der Kommunikation mit der gewählten Bürgerkartenumgebung. Die hier hinterlegen SL-Templates werden für die Kommunikation mit der jeweiligen BKU verwendet. Nähere Details zum Aufbau dieser SL-Templates finden Sie im <a href="#import_template_sltemplate">Kapitel 4.3</a>. </p> <p>Die Lage der Templates wird in Form einer URL beschrieben, wobei sowohl lokale Referenzen als der Bezug über http(s) möglich sind. Relative Pfadangaben werden dabei relativ zum Verzeichnis, in dem sich die MOA-ID-Auth Basiskonfigurationsdatei befindet, interpretiert. Bei Templates die über das Protokoll https referenziert werden, muss vor dem Start des Tomcat ein Truststore angegeben werden, das die notwendigen vertrauenswürdigen Zertifikate enthält.</p> +<p><strong>Hinweis:</strong> 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 ein bei der <a href="#konfigurationsparameter_oa_bku">Online Applikation konfiguriertes Tempalte</a> oder als Backup das erste Template in dieser Liste verwendet. Detailinformationen zum <a href="./../protocol/protocol.html#allgemeines_legacy">Legacy Request</a> finden Sie im Kapitel Protokolle.</p> <table width="1247" border="1"> <tr> <th width="89" scope="col">Name</th> @@ -1058,7 +1060,7 @@ https://<host>:<port>/moa-id-auth/MonitoringServlet</pre> <tr> <td>Online BKU</td> <td><p>SLTemplates/template_onlineBKU.html</p></td> - <td>SL Template zur Kommunikation mit der Online-BKU</td> + <td><p>SL Template zur Kommunikation mit der Online-BKU.</p></td> </tr> <tr> <td>Handy BKU</td> @@ -2062,8 +2064,38 @@ Alle in diesem Abschnitt angegebenen Parameter sind Optional und werden bei Beda </table> <p> </p> <p><strong>Hinweis:</strong> Bei Verwendung einer online-applikationsspezifischen Bürgerkartenauswahl stehen alle Parameter die die Bürgerkartenauswahl betreffen nicht zur Verfü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ü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ügung.</p> +<h4><a name="konfigurationsparameter_oa_additional_encbpk" id="uebersicht_zentraledatei_aktualisierung31"></a>3.2.8.2 Fremd-bPK Konfiguration</h4> +<p>Dieser Konfigurationsparameter ermöglicht die Konfiguration eines Key Stores, welcher im Falle einer<a href="../interfederation/interfederation.html"> Anmeldung mittels Single Sign-On Interfederation</a> zur Entschlüsselung einer verschlüsselten Fremd-bPK verwendet werden soll. Hierfür sind folgende Konfigurationsparameter notwenig.</p> +<table width="1247" border="1"> + <tr> + <th width="272" scope="col">Name</th> + <th width="147" scope="col">Beispielwert</th> + <th width="806" scope="col">Beschreibung</th> + </tr> + <tr> + <td>KeyStore hochladen</td> + <td> </td> + <td>Dateiname des Java Keystore oder PKCS12 Keystore welcher den privaten Schlüssel zur Entschlüsselung von Fremd-bPKs beinhaltet.</td> + </tr> + <tr> + <td><span id="wwlbl_loadOA_BPKEncDecr_keyStorePassword">KeyStore Password</span></td> + <td>password</td> + <td>Passwort zum Keystore</td> + </tr> + <tr> + <td><span id="wwlbl_loadOA_BPKEncDecr_keyAlias">Schlüsselname</span></td> + <td>pvp_metadata</td> + <td>Name des Schlüssels der zum Entschlüsseln der Fremd-bPK verwendet werden soll</td> + </tr> + <tr> + <td><span id="wwlbl_loadOA_BPKEncDecr_keyPassword">Schlüsselpassword</span></td> + <td>password</td> + <td>Passwort des Schlüssels der zum Entschlüsseln der Fremd-bPK verwendet werden soll</td> + </tr> +</table> <p> </p> +<p><strong>Hinweis:</strong> Diese Konfiguration ist jedoch nur nötig wenn die für das Modul MOA-ID-Auth Interfederation verwendet und von weiteren Identity Providern in der Federation Fremd-bPKs übermittelt werden welche bereits im Modul MOA-ID-Auth entschlüsselt werden sollen (z.B. bei Verwendung von SAML 1 als Authentifizierungsprotokoll). Bei Verwendung von PVP 2.1 und OpenID Connect kann die Fremd-bPK auch direkt an die Online Applikation weitergeben werden wodurch eine Entschlüsselung auf Seiten des Modules MOA-ID-Auth nicht zwingend notwendig ist.</p> <h2><a name="import_export" id="uebersicht_zentraledatei_aktualisierung4"></a>3.3 Import / Export</h2> <p>Über diese Funktionalität besteht die Möglichkeit eine bestehende MOA-ID 1.5.1 Konfiguration in MOA-ID 2.0 zu importieren. Zusätzlich besteht die Möglichkeit eine MOA-ID-Auth 2.0 diff --git a/id/server/doc/handbook/index.html b/id/server/doc/handbook/index.html index acab7517a..892a82484 100644 --- a/id/server/doc/handbook/index.html +++ b/id/server/doc/handbook/index.html @@ -15,7 +15,7 @@ </table> <hr/> <p class="title">MOA-ID (Identifikation) </p> - <p class="subtitle">Übersicht zur Dokumentation der Version 2.1.0 </p> + <p class="subtitle">Übersicht zur Dokumentation der Version 2.1.1 </p> <hr/> <dl> <dt><a href="./intro/intro.html">Einführung</a></dt> diff --git a/id/server/doc/handbook/interfederation/interfederation.html b/id/server/doc/handbook/interfederation/interfederation.html index d30c93008..bd97061ab 100644 --- a/id/server/doc/handbook/interfederation/interfederation.html +++ b/id/server/doc/handbook/interfederation/interfederation.html @@ -73,7 +73,8 @@ <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 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> + <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.<br> + <strong>Hinweis:</strong> Sollte die Assertion bereits alle notwenigen Anmeldeinformationen beinhalten wird Schritt 13 und 14 übersprungen. </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> <li>MOA-ID 2 generiert eine Assertion für Online Applikation 2</li> @@ -154,8 +155,9 @@ <tr> <td><span id="wwlbl_loadIDP_moaIDP_queryURL">AttributQuery Service URL</span></td> <td>https://demo.egiz.gv.at/moa-id-auth/pvp2/attributequery</td> - <td align="center"> </td> - <td><p>URL auf das Attribute-Query Service des konfigurierten IDP. Über dieses WebService werden die Authentifizierungsdaten vom IDP abgeholt.</p></td> + <td align="center">X</td> + <td><p>URL auf das Attribute-Query Service des konfigurierten IDP. Über dieses WebService werden die Authentifizierungsdaten vom IDP abgeholt.</p> + <p><strong>Hinweis:</strong> Wenn kein Service konfiguriert ist müssen alle für den Anmeldevorgang benötigten Informationen bereits in der Assertion im Schritt 11 (siehe <a href="#sequenzediagramm">Sequenzdiagramm</a>) übermittelt werden.</p></td> </tr> </table> <p> </p> |