aboutsummaryrefslogtreecommitdiff
path: root/id/server/doc/handbook/interfederation/interfederation.html
diff options
context:
space:
mode:
Diffstat (limited to 'id/server/doc/handbook/interfederation/interfederation.html')
-rw-r--r--id/server/doc/handbook/interfederation/interfederation.html270
1 files changed, 261 insertions, 9 deletions
diff --git a/id/server/doc/handbook/interfederation/interfederation.html b/id/server/doc/handbook/interfederation/interfederation.html
index b67124806..4e4f35c54 100644
--- a/id/server/doc/handbook/interfederation/interfederation.html
+++ b/id/server/doc/handbook/interfederation/interfederation.html
@@ -19,19 +19,271 @@
<hr/>
<h1>Inhalt</h1>
<ol>
- <li><a href="#allgemeines">Allgemeines</a>
+ <li><a href="#general">Allgemeines</a>
<ol>
- <li>. </li>
+ <li><a href="#sequenzediagramm">Sequenzdiagramm</a></li>
</ol>
</li>
+ <li><a href="#config">Konfiguration</a>
+<ol>
+ <li><a href="#config_basic">Basiskonfiguration</a></li>
+ <li><a href="#config_idps">Konfiguration einzelner IDPs</a></li>
+ </ol>
+ </li>
+ <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>
+ </ol>
+ </li>
+ <li><a href="#vidp">STORK VIDP Konfiguration</a></li>
+</ol>
+<p>&nbsp;</p>
+ <h1><a name="general" id="konfigurationsparameter_allgemein_bku7"></a>1 Allgemeines</h1>
+ <p>Ab der Version 2.1.0 des Modulpakets MOA-ID unterst&uuml;tzt das Modul MOA-ID-Auth Single Sign-On Interfederation zwischen Instanzen des Modules MOA-ID-Auth, welche bei unterschiedlichen Service Providern betrieben werden. Die nachfolgende Abbildung zeigt das Blockdiagramm einer solchen Systemkonfiguration und beschreibt die Funktionalit&auml;t auf einer abstrakten Ebene.</p>
+ <p><img src="blockdiagramm.png" width="1010" height="618" alt="Blockdiagramm MOA-ID Inderfederation"></p>
+<ol>
+ <li>Eine Benutzerin oder ein Benutzer m&ouml;chte sich an einer Online Applikation (Applikation 1) oder einem Service Portal anmelden.</li>
+ <li>F&uuml;r den Anmeldevorgang wird die Benutzerin oder der Benutzer an den IdentityProvider (MOA-ID IDP 1) welcher die Identifizierung und Authentifizierung durchf&uuml;hrt und eine Single Sign-On (SSO) Session anlegt.</li>
+ <li>Anschlie&szlig;end wir die Benutzerin oder der Benutzer an die Online Applikation zur&uuml;ckgeleitet und befindet sich im angemeldeten Bereich der Applikation 1.</li>
+ <li>Applikation 1 bieten die M&ouml;glichkeit sich an einer weiteren Online Applikation (Applikation 2) anzumelden. Die Benutzerin oder der Benutzer meldet sich an Online Applikation 2 an, wobei der Anmeldevorgang aus dem sicheren Bereich von Applikation 1 erfolgt.</li>
+ <li>Da die Benutzerin oder der Benutzer an Applikation zwei noch nicht authentifiziert ist wird ein Anmeldevorgang &uuml;ber den IDP 2 gestartet, welcher die Information enth&auml;lt dass es eine aktive SSO Session an IDP 1 gibt.</li>
+ <li>IDP 2 holt von IDP 1 die Authentifizierungsinformationen f&uuml;r Applikation 2 ab. F&uuml;r die Kommunikation zwischen den beiden IDPs wird PVP 2.1 als Protokoll verwendet. Sollte am IDP 1 keine aktive SSO Session f&uuml;r diesen Benutzer existieren wird eine lokale Authentifizierung der Benutzerin oder des Benutzer an IDP 2 gestartet.</li>
+ <li>Anschlie&szlig;end wird die Benutzerin oder der Benutzer an Applikation 2 zur&uuml;ckgeleitet und befindet sich im angemeldeten Bereich der Applikation 2.</li>
+</ol>
+<h2><a name="sequenzediagramm" id="konfigurationsparameter_allgemein_bku"></a>1.1 Sequenzdiagramm</h2>
+<p>Das nachfolgende Sequenzdiagramm beschreibt den Ablauf eines Anmeldevorgangs an einer Online Applikation mit Hilfe von Interfederation im Detail wobei in diesem Beispiel als Authentifizierungsprotokoll an der Online Applikation 2 PVP 2.1 und die <a href="#usage_redirect">Variante mit Redirect Servlet</a> verwendet werden. Eine Verwendung aller anderen, durch das Modul MOA-ID-Auth bereitgestellten Authentifizierungsprotokolle ist jedoch ebenfalls m&ouml;glich. Aus Gr&uuml;nden der &Uuml;bersichtlichkeit sind die Schritte 1 - 3 aus dem oben dargestellten Blockdiagramm im Sequenzdiagramm nicht ber&uuml;cksichtigt, da diese Schritte bereits im Kapitel <a href="./../protocol/protocol.html">Protokolle</a> im Detail beschrieben wurden. </p>
+<p><img src="interfederation_sequenz.png" width="1082" height="994" alt="SSO Interfederation Sequenze"></p>
+<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>
+ <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>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>
+ <strong>Hinweis:</strong> Der eindeutige Identifier des interfederation IDPs (http GET Parameter <em>interIDP</em>=xxxxxxx), welcher eine aktive SSO Session f&uuml;r die Benutzerin oder den Benutzer besitzt, kann auch direkt in diesem Schritt an MOA-ID 2 &uuml;bergeben werden. In diesem Fall k&ouml;nnen die Schritte 2 bis 5 entfallen.</li>
+ <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>Die Assertion wird an MOA-ID 2 zur&uuml;ckgesendet.</li>
+ <li>MOA-ID 2 validiert die Assertion und extrahiert das SessionTokken. <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>
+ <li>MOA-ID 2 generiert eine Assertion f&uuml;r Online Applikation 2</li>
+ <li>MOA-ID 2 speichert Sessioninformationen zum verwendeten interfederation IDP. Mit diesen Informationen ist je nach Konfiguration eine weitere Authentifizierung ohne Bekanntgabe eines speziellen interfederation IDP oder eine Single LogOut m&ouml;glich.</li>
+ <li>Die Assertion wird an die Online Applikation 2 gesendet</li>
+ <li>Online Applikation 2 validiert die Assertion</li>
+ <li>Wurde die Validierung der Assertion positiv abgeschlossen wird der Benutzer im sicheren Bereich von Online Applikation zwei angemeldet.</li>
</ol>
- <p>&nbsp;</p>
- <h1>Allgemeines</h1>
- <p>Ab der Version 2.0.2 des Modulepackets MOA-ID unterst&uuml;tzt das Modul MOA-ID-Auth Single Sign-On Interfederation zwischen Instanzen des Modules MOA-ID-Auth, welche bei unterschiedlichen Service Providern betrieben werden. Die nachfolgende Abbildung zeigt das Blockdiagramm einer solchen Systemkonfiguration und beschreibt die Funktionalit&auml;t auf einer abstrakten Ebene.</p>
- <p>&nbsp;</p>
- <p>&nbsp;</p>
- <p>&nbsp; </p>
- <p>&nbsp;</p>
+<h1> <a name="config" id="konfigurationsparameter_allgemein_bku2"></a>2 Konfiguration</h1>
+<p>Die Konfiguration des Modules MOA-ID-Auth in einer IDP Interfederation ist in zwei Abschnitte unterteilt. Der erste Teil behandelt die Basiskonfiguration des Modules MOA-ID-Auth. Im zweiten Abschnitt erfolgt die Konfiguration der einzelnen IDP Instanzen welche von dieser MOA-ID-Auth verwendet werden k&ouml;nnen oder in einem IDP interfederation Verbund stehen.</p>
+<p>Bei IDP Interfederation handelt es sich um eine Erweiterung der Funktionalit&auml;t des Modules MOA-ID-Auth. Die in diesem Abschnitt beschriebene Konfiguration bezieht sich speziell auf den Bereich Interfederation, ersetzt jedoch nicht die Konfiguration des Modules MOA-ID-Auth laut Kapitel <a href="./../config/config.html">Konfiguration</a>.</p>
+<h2><a name="config_basic" id="konfigurationsparameter_allgemein_bku3"></a>2.1 Basiskonfiguration</h2>
+<p>Wird das Modul MOA-ID-Auth in einer IDP Interfederation betrieben muss das PVP 2.1 Protokoll, in der Basiskonfiguration von MOA-ID-Auth konfiguriert werden. Eine Beschreibung der entsprechenden Konfigurationsparameter finden Sie im Kapitel <a href="./../config/config.html#basisconfig_moa_id_auth_param_protocol_pvp21">Protokolle -&gt; PVP 2.1</a>. </p>
+<h2><a name="config_idps" id="konfigurationsparameter_allgemein_bku4"></a>2.2 Konfiguration einzelner IDPs </h2>
+<p>Zus&auml;tzlich zu Basiskonfiguration m&uuml;ssen alle f&uuml;r diese IDP Interfederation registrierten IDPs konfiguriert werden. Diese Konfiguration erfolgt &uuml;ber das Modul MOA-ID-Configuration wobei f&uuml;r Interfederation ein eigener Men&uuml;punkt im Hauptmen&uuml; zur Verf&uuml;gung steht. &Uuml;ber diesen Konfigurationspunkt k&ouml;nnen neue IDPs hinzugef&uuml;gt (MOA-ID IDP hinzuf&uuml;gen) oder bestehende IDPs bearbeitet werden wobei alle aktuell hinterlegten IDPs in einer Liste dargestellt werden.</p>
+<p>Die Konfiguration der einzelnen IDP Instanzen erfolgt &auml;hnlich zur Konfiguration von Online-Applikationen (siehe <a href="./../config/config.html#konfigurationsparameter_oa">Online-Applikationskonfiguration</a>), jedoch sind f&uuml;r eine IDP Konfiguration nicht alle Konfigurationsparameter aus der Online-Applikationskonfiguration erforderlich.</p>
+<p>Im ersten Abschnitt werden allgemeine Informationen zum IDP konfiguriert.</p>
+<table width="1199" border="1">
+ <tr>
+ <th width="153" scope="col">Name</th>
+ <th width="204" scope="col">Beispielwert</th>
+ <th width="57" scope="col">Optional</th>
+ <th width="757" scope="col">Beschreibung</th>
+ </tr>
+ <tr>
+ <td>Online-Applikation ist aktiviert</td>
+ <td>&nbsp;</td>
+ <td align="center">&nbsp;</td>
+ <td>Aktiviert oder deaktiviert den IDP. Es k&ouml;nnen nur aktive IdentityProvider f&uuml;r IDP Interfederation verwendet werden.</td>
+ </tr>
+ <tr>
+ <td><p>Eindeutiger Identifikatior</p></td>
+ <td>https://demo.egiz.gv.at/demologin/</td>
+ <td align="center">&nbsp;</td>
+ <td>Dieser Parameter dient als Schl&uuml;ssel zum Auffinden der Konfigurationsparameter des IDP. Hierf&uuml;r ist ein eindeutiger Identifikator f&uuml;r den IDP erforderlich. Dieser eindeutige Identifikator muss mindestens dem URL-Pr&auml;fix der nach au&szlig;en sichtbaren Dom&auml;ne des IDP und der PVP 2.1 EntityID des IDP entsprechen</td>
+ </tr>
+ <tr>
+ <td><p>Name der <br>
+ Online-Applikation</p></td>
+ <td>Demo Applikation A</td>
+ <td align="center">&nbsp;</td>
+ <td>Hier muss ein benutzerfreundlicher Name f&uuml;r den IDP angegeben werden. </td>
+ </tr>
+ <tr>
+ <td>Privatwirtschaftliche Applikation</td>
+ <td>&nbsp;</td>
+ <td align="center">&nbsp;</td>
+ <td><p>Definiert ob der IDP dem &ouml;ffentlichen Bereich oder dem privatwirtschaftlichen Bereich (Business Service) zugeordnet ist.</p></td>
+ </tr>
+</table>
+<p>&nbsp;</p>
+<p>Der zweite Abschnitt behandelt spezielle Konfigurationsparameter f&uuml;r IDP Interfederation.</p>
+<table width="1199" border="1">
+ <tr>
+ <th width="153" scope="col">Name</th>
+ <th width="204" scope="col">Beispielwert</th>
+ <th width="57" scope="col">Optional</th>
+ <th width="757" scope="col">Beschreibung</th>
+ </tr>
+ <tr>
+ <td><span id="wwlbl_loadIDP_moaIDP_inboundSSO">Eingehendes SSO erlauben</span></td>
+ <td>&nbsp;</td>
+ <td align="center">&nbsp;</td>
+ <td>&Uuml;ber diesen Parameter kann eingehende SSO Interfederation von diesem IDP erlaubt werden. Ist eingehende SSO Interfederation erlaubt kann eine aktive SSO Session, wenn diese auf diesem IDP existiert, verwendet werden.</td>
+ </tr>
+ <tr>
+ <td><p><span id="wwlbl_loadIDP_moaIDP_outboundSSO">Ausgehendes SSO erlauben</span></p></td>
+ <td>&nbsp;</td>
+ <td align="center">&nbsp;</td>
+ <td>&Uuml;ber diesen Parameter kann ausgehende SSO Interfederation zu diesem IDP erlaubt werden. Ist ausgehende SSO Interfederation erlaubt darf dieser IDP SSO Sessioninformation anfordern.</td>
+ </tr>
+ <tr>
+ <td><p><span id="wwlbl_loadIDP_moaIDP_storeSSOSession">SSO Session speichern</span></p></td>
+ <td>&nbsp;</td>
+ <td align="center">&nbsp;</td>
+ <td>Wenn eingehende SSO Intefederation erlaubt ist besteht zus&auml;tzlich die M&ouml;glichkeit diesen einmal verwendeten IDP an die Benutzersession zu binden. In diesem Fall k&ouml;nnen weitere SSO Authentifizierungen &uuml;ber diesen interfederation IDP auch ohne Angabe des IDP Identifiers (siehe <a href="#sequenzediagramm">Sequenzdiagramm</a> oder <a href="#usage">Integration in bestehende Systeme</a>) durchgef&uuml;hrt werden.</td>
+ </tr>
+ <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>
+ </tr>
+</table>
+<p>&nbsp;</p>
+<p>Der dritte Abschnitt behandelt die PVP 2.1 Konfiguration des IDP. Da diese Konfiguration identisch zur <a href="./../config/config.html#konfigurationsparameter_oa_protocol_pvp21">PVP 2.1 Konfiguration f&uuml;r Online-Applikationen</a> ist wird auf entsprechende Kapitel in der Online-Applikationskonfiguration verwiesen.</p>
+<p><strong>Hinweis:</strong> Bei der Speicherung der Konfiguration und bei jedem Ladevorgang der Konfiguration im Modul MOA-ID-Auth wird &uuml;berpr&uuml;ft ob der IDP die Anforderungen an einen &ouml;ffentlichen IDP erf&uuml;llt. Die &Uuml;berpr&uuml;fung erfolgt auf Basis der PVP 2.1 Metadaten URL des IDP und diese muss mindestens eine der folgenden Anforderungen erf&uuml;llt sein. Schl&auml;gt die &Uuml;berpr&uuml;fung fehl, kann der IDP nicht gespeichert werden oder wird durch das Modul MOA-ID-Auth aus der aktuell geladenen Konfiguration entfernt.</p>
+<ul>
+ <li>Die URL unter der die Metadaten erreichbar sind muss einen <em>*.gv.at</em> Domain aufweisen. (Beispiel: https://demo.egiz.gv.at/moa-id-auth/pvp2/metadata)</li>
+ <li>Der SSL Serverzertifikat des IDP weist eine der folgenden Eigenschaften auf.
+ <ul>
+ <li>Veraltungseigenschaft (OID=1.2.40.0.10.1.1.1)</li>
+ <li>Dienstleistereigenschaft (OID=1.2.40.0.10.1.1.2)</li>
+ </ul>
+ </li>
+</ul>
+<h1><a name="usage" id="konfigurationsparameter_allgemein_bku6"></a>3 Integration in bestehende Systeme</h1>
+<p>Um den Interfederation Mechanismus in ein bestehendes System zu integrieren muss dem protokollspezifischen Authentifizierungsrequest, welcher da das Modul MOA-ID-Auth gesendet wird, ein zus&auml;tzlicher Parameter angef&uuml;gt werden. Dieser Parameter identifiziert den interfederation IDP von welchem eine aktive SSO Session verwendet werden soll. Dieser zus&auml;tzliche Parameter kann als http GET oder als http POST Parameter an MOA-ID-Auth &uuml;bertragen werden. </p>
+<table width="1247" border="1">
+ <tr>
+ <th width="115" scope="col">Name</th>
+ <th width="262" scope="col">Beispielwert</th>
+ <th width="848" scope="col">Beschreibung</th>
+ </tr>
+ <tr>
+ <td>interIDP</td>
+ <td>https://demo.egiz.gv.at/moa-id-auth</td>
+ <td><p>Ist der eindeutige Identifikator f&uuml;r den interfederation IDP von welchem die aktive SSO Session verwendet werden soll.</p>
+ <p><strong>Hinweis:</strong> Ist dieser IDP nicht konfiguriert oder die Konfiguration des IDP nicht aktiv wird eine lokale Authentifizierung mittels B&uuml;rgerkarte oder Handy-Signatur durchgef&uuml;hrt.</p></td>
+ </tr>
+</table>
+<p>&nbsp;</p>
+<p>Wie bereits im <a href="#sequenzediagramm">Abschnitt Sequenzdiagramm</a> erw&auml;hnt stehen f&uuml;r die &Uuml;bertragung des zus&auml;tzlichen Parameters zwei Varianten zur Verf&uuml;gung.</p>
+<h2><a name="usage_direct" id="konfigurationsparameter_allgemein_bku8"></a>3.1 Direkte &Uuml;bermittlung im Authentifizierungsrequest</h2>
+<p>Bei dieser Variante wird der zus&auml;tzliche Parameter <em>interIDP</em> direkt im protokollspezifischen Authentifizierungsrequest, welcher den Authentifizierungsvorgang startet, angef&uuml;gt. In diesem Fall muss der Service Provider, welcher den Authentifizierungsrequest erzeugt, den zus&auml;tzlichen Parameter <em>interIDP</em> einf&uuml;gen. Diese Variante steht f&uuml;r alle verf&uuml;gbaren Authentifizierungsvarianten des Modules MOA-ID-Auth zur Verf&uuml;gung und es existieren keine besonderen Einschr&auml;nkungen. Das nachfolgende Beispiel zeigt die Verwendung in Kombination mit SAML 1 wobei der <em>interIDP</em> Parameter als http GET Parameter &uuml;bermittelt wird.</p>
+<pre>&lt;a href="https://&lt;moa-id-server-und-pfad&gt;/StartAuthentication
+ ?Target=&lt;gesch&auml;ftsbereich&gt;
+ &amp;OA=&lt;oa-url&gt;
+ &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>
+<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>
+ <th width="115" scope="col">Name</th>
+ <th width="262" scope="col">Beispielwert</th>
+ <th width="848" scope="col">Beschreibung</th>
+ </tr>
+ <tr>
+ <td>interIDP</td>
+ <td>https://demo.egiz.gv.at/moa-id-auth</td>
+ <td><p>Ist der eindeutige Identifikator f&uuml;r den interfederation IDP von welchem die aktive SSO Session verwendet werden soll.</p>
+ <p><strong>Hinweis:</strong> Ist dieser IDP nicht konfiguriert oder die Konfiguration des IDP nicht aktiv wird eine lokale Authentifizierung mittels B&uuml;rgerkarte oder Handy-Signatur durchgef&uuml;hrt.</p></td>
+ </tr>
+ <tr>
+ <td>redirecturl</td>
+ <td>https://demo.egiz.gv.at/moa-id-oa/servlet/pvp2login</td>
+ <td><p>URL auf die nach erfolgreicher Validierung aller Parameter weitergeleitet wird. Das hier angegebene Service erzeugt den eigentlichen applikationsspezifischen Authentifizierungsrequest.</p>
+ <p><strong>Hinweis:</strong> Die angegebene URL muss als Prefix identisch mit dem <a href="./../config/config.html#konfigurationsparameter_oa_general">eindeutigen Identifier der jeweiligen Online-Applikation</a> sein.</p></td>
+ </tr>
+</table>
+<p>&nbsp;</p>
+<h1><a name="vidp" id="konfigurationsparameter_allgemein_bku5"></a>4 STORK VIDP Konfiguration</h1>
+<p>Das Modul MOA-ID-Auth kann auch als STORK2 VIDP betrieben werden. Diese VIDP Konfiguration erfolgt ebenfalls &uuml;ber den Men&uuml;punkt Interfederation, wobei neues VIDPs mit Hilfe der Schaltfl&auml;che VIDP hinzuf&uuml;gen konfiguriert werden k&ouml;nnen. </p>
+<p>Die Konfiguration eines VIDPs erfolgt weitgehend identisch zur Konfiguration einer <a href="./../config/config.html#konfigurationsparameter_oa">Online-Applikation</a>, wobei im Falle eines VIDPs noch folgende zus&auml;tzliche Konfigurationsparameter zur Verf&uuml;gung stehen.</p>
+<table width="1250" border="1">
+ <tr>
+ <th width="185" scope="col">Name</th>
+ <th width="85" scope="col">Beispielwert</th>
+ <th width="66" scope="col">Optional</th>
+ <th width="886" scope="col">Beschreibung</th>
+ </tr>
+ <tr>
+ <td><p>VIDP Interface aktiv</p></td>
+ <td>&nbsp;</td>
+ <td align="center">X</td>
+ <td><p>Stellt fest, ob das VIDP Interface aktiviert wird.</p></td>
+ </tr>
+ <tr>
+ <td><p>Zustimmung f&uuml;r das Ausliefern der Attribute</p></td>
+ <td>&nbsp;</td>
+ <td align="center">X</td>
+ <td><p>Stellt fest, ob die Zustimmung f&uuml;r das Ausliefern der Attribute vom Benutzer erforderlich ist. Diese Zustimmung ist f&uuml;r grenz&uuml;bergreifenden Datenverkehr aufgrund Datenschutzbestimmungen oft notwendig. </p></td>
+ </tr>
+</table>
+<p>&nbsp;</p>
+<p>Au&szlig;erdem k&ouml;nnen zus&auml;tzliche Attributproviders eingetragen werden.
+ Diese Attributprovider werden f&uuml;r die Abholung einiger Attribute von &ouml;sterreichischen B&uuml;rgern ben&ouml;tigt (Anmeldung in Ausland). Die Eintragung und Auswahl von Attributprovidern ist <span class="term">optional</span>. </p>
+<p>W&auml;hrend des Anmeldevorgangs wird der Benutzer an den entsprechenden Attributprovider weitergeleitet. Am Attributprovider werden die erforderlichen Attribute ausgew&auml;hlt und zur&uuml;ck an VIDP (am Service Provider) geliefert. </p>
+<br/>
+<table width="1250" border="1">
+ <tr>
+ <th width="167" scope="col">Name des Plugins</th>
+ <th width="781" scope="col">Beschreibung</th>
+ </tr>
+ <tr>
+ <td>EHvdAttributeProvider</td>
+ <td>F&uuml;r Gesundheitsbereich spezifisches Attributprovider. </td>
+ </tr>
+ <tr>
+ <td>SignedDocAttributeRequestProvider</td>
+ <td>Attributprovider verwendet f&uuml;r die Signatur von Dokumenten (<span class="term">Signatur Service</span>).</td>
+ </tr>
+ <tr>
+ <tr>
+ <td>MISAttributeRequestProvider</td>
+ <td>Attributprovider verwendet f&uuml;r die Vertretungsf&auml;lle.</td>
+ </tr>
+ <tr>
+ <td>StorkAttributeRequestProvider</td>
+ <td>Allgemeines Plugin, wird verwendet f&uuml;r die Restf&auml;lle.</td>
+ </tr>
+</table>
+<p>&nbsp;</p>
+<p>Beispiel eines Eintrages f&uuml;r Attributprovider:</p>
+<pre><table width="1220" border="1">
+ <tr>
+ <th width="167" scope="col">AP Plugin</th>
+ <th width="681" scope="col">URL</th>
+ <th width="281" scope="col">Attribute</th>
+ </tr>
+ <tr>
+ <td>MISAttributeRequestProvider</td>
+ <td>http://mis.testvidp.at/moa-id-auth/stork2/MISProvider</td>
+ <td>mandateContent,<span class="term">attribut1</span>,<span class="term">attribut2</span></td>
+ </tr>
+</table>
+</pre>
+<p>&nbsp;</p>
<h1><a name="referenzierte_spezifikation" id="uebersicht_zentraledatei_aktualisierung30"></a>A Referenzierte Spezifikation</h1>
<table class="fixedWidth" border="1" cellpadding="2">
<tbody>