aboutsummaryrefslogtreecommitdiff
path: root/id/server/doc/handbook
diff options
context:
space:
mode:
Diffstat (limited to 'id/server/doc/handbook')
-rw-r--r--id/server/doc/handbook/config/config.html36
-rw-r--r--id/server/doc/handbook/index.html2
-rw-r--r--id/server/doc/handbook/interfederation/interfederation.html8
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&auml;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://&lt;host&gt;:&lt;port&gt;/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&auml;hlten B&uuml;rgerkartenumgebung. Die hier hinterlegen SL-Templates werden f&uuml;r die Kommunikation mit der jeweiligen BKU verwendet. N&auml;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 &uuml;ber http(s) m&ouml;glich sind. Relative Pfadangaben werden dabei relativ zum Verzeichnis, in dem sich die MOA-ID-Auth Basiskonfigurationsdatei befindet, interpretiert. Bei Templates die &uuml;ber das Protokoll https referenziert werden, muss vor dem Start des Tomcat ein Truststore angegeben werden, das die notwendigen vertrauensw&uuml;rdigen Zertifikate enth&auml;lt.</p>
+<p><strong>Hinweis:</strong> Diese hier definierten Templates dienen als zus&auml;tzliche WhiteList f&uuml;r Templates welche im &bdquo;StartAuthentication&ldquo; Request mit dem Parameter &bdquo;template&ldquo; &uuml;bergeben werden. Sollte im &bdquo;StartAuthentication&ldquo; Request der Parameter &bdquo;template&ldquo; fehlen, es wurde jedoch eine &bdquo;bkuURL&ldquo; &uuml;bergeben, dann wird f&uuml;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://&lt;host&gt;:&lt;port&gt;/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>&nbsp;</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&ouml;glicht die Konfiguration eines Key Stores, welcher im Falle einer<a href="../interfederation/interfederation.html"> Anmeldung mittels Single Sign-On Interfederation</a> zur Entschl&uuml;sselung einer verschl&uuml;sselten Fremd-bPK verwendet werden soll. Hierf&uuml;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>&nbsp;</td>
+ <td>Dateiname des Java Keystore oder PKCS12 Keystore welcher den privaten Schl&uuml;ssel zur Entschl&uuml;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&uuml;sselname</span></td>
+ <td>pvp_metadata</td>
+ <td>Name des Schl&uuml;ssels der zum Entschl&uuml;sseln der Fremd-bPK verwendet werden soll</td>
+ </tr>
+ <tr>
+ <td><span id="wwlbl_loadOA_BPKEncDecr_keyPassword">Schl&uuml;sselpassword</span></td>
+ <td>password</td>
+ <td>Passwort des Schl&uuml;ssels der zum Entschl&uuml;sseln der Fremd-bPK verwendet werden soll</td>
+ </tr>
+</table>
<p>&nbsp;</p>
+<p><strong>Hinweis:</strong> Diese Konfiguration ist jedoch nur n&ouml;tig wenn die f&uuml;r das Modul MOA-ID-Auth Interfederation verwendet und von weiteren Identity Providern in der Federation Fremd-bPKs &uuml;bermittelt werden welche bereits im Modul MOA-ID-Auth entschl&uuml;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&uuml;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">&Uuml;bersicht zur Dokumentation der Version 2.1.0 </p>
+ <p class="subtitle">&Uuml;bersicht zur Dokumentation der Version 2.1.1 </p>
<hr/>
<dl>
<dt><a href="./intro/intro.html">Einf&uuml;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&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 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>
+ <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.<br>
+ <strong>Hinweis:</strong> Sollte die Assertion bereits alle notwenigen Anmeldeinformationen beinhalten wird Schritt 13 und 14 &uuml;bersprungen. </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>
<li>MOA-ID 2 generiert eine Assertion f&uuml;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">&nbsp;</td>
- <td><p>URL auf das Attribute-Query Service des konfigurierten IDP. &Uuml;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. &Uuml;ber dieses WebService werden die Authentifizierungsdaten vom IDP abgeholt.</p>
+ <p><strong>Hinweis:</strong> Wenn kein Service konfiguriert ist m&uuml;ssen alle f&uuml;r den Anmeldevorgang ben&ouml;tigten Informationen bereits in der Assertion im Schritt 11 (siehe <a href="#sequenzediagramm">Sequenzdiagramm</a>) &uuml;bermittelt werden.</p></td>
</tr>
</table>
<p>&nbsp;</p>