<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" >
  <title>MOA-ID - Protokolle</title>
  <link rel="stylesheet" href="../common/MOA.css" type="text/css">
</head>
<body link="#990000"> 
  <table class="logoTable" width="100%" border="0" cellspacing="0" cellpadding="10">
    <tr>
      <td align="center" class="logoTitle" width="267"><img src="../common/LogoBKA.png" alt="Logo BKA" width="267" height="37" align="left"></td>
      <td align="center" class="logoTitle">Dokumentation</td>
      <td align="center" class="logoTitle" width="123"><img src="../common/LogoEGIZ.png" alt="Logo EGIZ" width="230" height="81" align="right"></td>
    </tr>
  </table>
  <hr/> 
  <p class="title"><a href="../index.html">MOA-ID (Identifikation) </a></p> 
<p class="subtitle">Interfederation</p> 
  <hr/>
<h1>Inhalt</h1>
  <ol>
    <li><a href="#general">Allgemeines</a>    
      <ol>
        <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 Redirect 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 Redirect Servlet 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-applikationsspezifischen Authentifizierungsrequest 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 Redirect 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 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>
  <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>
<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 Redirect 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>
    <tr>
      <th>Spezifikation</th>
      <th>Link</th>
    </tr>
    <tr id="sl">
      <td><p>Security Layer Spezifikation V1.2.0</p></td>
      <td><a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20140114/">http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20140114/</a></td>
    </tr>
    <tr>
      <td>PVP 2.1 S-Profil Spezifikation</td>
      <td><a href="http://reference.e-government.gv.at/uploads/media/PVP2-S-Profil_2_0_0_a-2011-08-31.pdf">http://reference.e-government.gv.at/uploads/media/PVP2-S-Profil_2_0_0_a-2011-08-31.pdf</a></td>
    </tr>
    <tr>
      <td>OpenID Connect</td>
      <td><a href="http://openid.net/connect/">http://openid.net/connect/</a></td>
    </tr>
    <tr>
      <td>STORK 2</td>
      <td>@TODO Link</td>
    </tr>
    <tr>
      <td>Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0</td>
      <td><a href="#http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf">http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf</a></td>
    </tr>
    <tr>
      <td>Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0</td>
      <td><a href="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf</a></td>
    </tr>
    <tr>
      <td>Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V1.1</td>
      <td><a href="https://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf">https://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf</a></td>
    </tr>
  </tbody>
</table>
</body>
</html>