<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" >
  <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
  <title>MOA-ID - Protokolle</title>
  <link rel="stylesheet" href="../common/MOA.css" type="text/css">
  <link href='https://fonts.googleapis.com/css?family=Roboto:300,400' rel='stylesheet' type='text/css'>
</head>
<body link="#990000"> 
    <div id="headline">
      <div class="container">
          <a href="http://www.digitales.oesterreich.gv.at/"><img src="../common/logo_digAT.png"/></a>
          <a href="../index.html"><h1>MOA-ID-AUTH </h1></a>
          <br/>
      </div>
  </div>
<div class="container">
<h1  align="center">Interfederation</h1> 
  <h2>Inhalt</h2>
  <ol class="index">
    <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>
    <li><a href="#storkpvpgateway">STORK &lt;-&gt; PVP Gateway</a></li>
</ol>
<p>&nbsp;</p>
  <h2><a name="general" id="konfigurationsparameter_allgemein_bku7"></a>1 Allgemeines</h2>
  <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>
  <div class="smallImgDiv"><img src="blockdiagramm.png" alt="Blockdiagramm MOA-ID Inderfederation"></div>
<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>
<h3><a name="sequenzediagramm" id="konfigurationsparameter_allgemein_bku"></a>1.1 Sequenzdiagramm</h3>
<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>
    <div class="largeImgDiv"><img src="interfederation_sequenz.png" alt="SSO Interfederation Sequenze"></div>
<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.<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>
  <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>
<h2> <a name="config" id="konfigurationsparameter_allgemein_bku2"></a>2 Konfiguration</h2>
<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>
<h3><a name="config_basic" id="konfigurationsparameter_allgemein_bku3"></a>2.1 Basiskonfiguration</h3>
<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>
<h3><a name="config_idps" id="konfigurationsparameter_allgemein_bku4"></a>2.2 Konfiguration einzelner IDPs </h3>
<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 class="configtable">
  <tr>
    <th>Name</th>
    <th>Beispielwert</th>
    <th>Optional</th>
    <th>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 class="configtable">
  <tr>
    <th>Name</th>
    <th>Beispielwert</th>
    <th>Optional</th>
    <th>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_passiveRequest">Verwende SAML2 isPassive Attribut</span></td>
    <td>&nbsp;</td>
    <td align="center">&nbsp;</td>
    <td>Wird dieser Parameter aktiviert erfolgt der Authentifizierungsrequest im Schritt 9 (siehe <a href="#sequenzediagramm">Sequenzdiagramm</a>) unter Verwendung des SAML 2 <em>isPassiv</em> Flags. Wenn die Benutzerin oder der Benutzer keine aktive SSO Session an diesem IDP besitzt wird ein Fehler returniert und KEINE Authentifizierung an diesem IDP durchgef&uuml;hrt. </td>
  </tr>
  <tr>
    <td><span id="wwlbl_loadIDP_moaIDP_localAuthOnError">Im Fehlerfall Authentifizierung lokal durchf&uuml;hren</span></td>
    <td>&nbsp;</td>
    <td align="center">&nbsp;</td>
    <td><p>Wird dieser Parameter aktiviert erfolgt im Falle eines returnierten Fehlers im Schritt 11 (siehe <a href="#sequenzediagramm">Sequenzdiagramm</a>) keine lokale Authentifizierung und dem Service Provider wird eine Fehlermeldung returniert. </p></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">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>
<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>
<h2><a name="usage" id="konfigurationsparameter_allgemein_bku6"></a>3 Integration in bestehende Systeme</h2>
<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 class="configtable">
  <tr>
    <th>Name</th>
    <th>Beispielwert</th>
    <th>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>
<h3><a name="usage_direct" id="konfigurationsparameter_allgemein_bku8"></a>3.1 Direkte &Uuml;bermittlung im Authentifizierungsrequest</h3>
<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>
<h3><a name="usage_redirect" id="konfigurationsparameter_allgemein_bku9"></a>3.2 Verwendung des Redirect Servlets</h3>
<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 class="configtable">
  <tr>
    <th>Name</th>
    <th>Beispielwert</th>
    <th>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>
<h2><a name="vidp" id="konfigurationsparameter_allgemein_bku5"></a>4 STORK VIDP Konfiguration</h2>
<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 class="configtable">
  <tr>
    <th>Name</th>
    <th>Beispielwert</th>
    <th>Optional</th>
    <th>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 class="configtable">
  <tr>
    <th>Name des Plugins</th>
    <th>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>
  <tr>
    <td>PVPAuthenticationProvider</td>
    <td><p>Dieser Provider dient zur Authentifizierung des Benutzers &uuml;ber den Portalverbund der &ouml;sterreichischen Beh&ouml;rden. Wird ein zu diesem Provider konfiguriertes Attribut angefragt erfolgt die Authentifizerung des Benutzers NICHT am VIDP sondern in der nationalen Infrastruktur, wobei die Anmeldedaten &uuml;ber den VIDP an den Service Provider weitergereicht werden. Als URL ist der Link auf den nationalen <a href="#storkpvpgateway">STORK&lt;-&gt;PVP Gateway</a> zu hinterlegen.</p>
    <p><strong>Hinweis:</strong> Aktuell fordert folgende Attribute eine nationale Authentifizierung: </p>
    <ul>
      <li><em>ECApplicationRole</em></li>
    </ul></td>
  </tr>
</table>
<p>&nbsp;</p>
<p>Beispiel eines Eintrages f&uuml;r Attributprovider:</p>
<pre><table class="configtable">
  <tr>
    <th>AP Plugin</th>
    <th>URL</th>
    <th>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>
<h2><a name="storkpvpgateway" id="konfigurationsparameter_allgemein_bku10"></a>5 STORK &lt;-&gt; PVP Gateway</h2>
<p>Das Modul MOA-ID-Auth kann auch als Gateway zwischen dem Portalverbund der &ouml;sterreichischen Beh&ouml;rden und der STORK Infrastruktur betrieben werden. Diese Konfiguration konfiguriert einen Gateway welcher zur Authentifizierung &ouml;sterreichischer Benutzerinnen oder Benutzer im Falle einer STORK Anmeldung mit Hilfe der &ouml;sterreichischen PVP Infrastruktur dient. Der Einsprung zum Gateway erfolgt &uuml;ber den <em>PVPAuthenticationProvider</em> in der <a href="#vidp">VIDP Konfiguration</a>.</p>
<p>Die nachstehende Grafik skizziert den Prozessfluss eines solchen Anmeldevorgangs.</p>
<div class="smallImgDiv"><img src="blockdiagramm_storkpvpgateway.png" alt="Blockdiagramm STORK-PVP Gateway"></div>
<ol>
  <li>Eine &ouml;sterreichische Benutzerin oder ein &ouml;sterreichischer Benutzer m&ouml;chte sich an einer europ&auml;ischen Online Applikation (Applikation 1) anmelden.</li>
  <li>Die Benutzerin oder der Benutzer wird an den entsprechenden VIDP unter Verwendung des STORK Protokolls zur Authentifizierung weitergeleitet. F&uuml;r den Fall das spezielle Attribute durch die Applikation angefordert wurden (z.B. <em>ECApplicationRole</em>) kann die Authentifizierung nicht am VIDP vorgenommen werden. In diesem Fall erfolgt eine Weiterleitung an den nationalen STORK-PVP Gateway (siehe <a href="#vidp">VIDP Konfiguration</a>).</li>
  <li>Die Benutzerin oder der Benutzer wird an den zentralen STORK-PVP Gateway weitergeleitet. Der STORK-PVP Gateway generiert einen PVP Authentifizierungsrequest und sendet diesen an das im Gateway konfigurierte Stamm- oder Anwendungsportal. Hierf&uuml;r muss das Stamm- oder Anwendungsportal als <a href="#config">MOA-ID IDP</a> konfiguriert sein.</li>
  <li>Die Benutzerin oder der Benutzer wird an das jeweilige Stamm- oder Anwendungsportal weitergeleitet wo die eigentliche Authentifizierung erfolgt. Nach erfolgreicher Authentifizierung werden PVP spezifische Authentifizierungsdaten generiert.</li>
  <li>Diese PVP spezifischen Authentifizierungsdaten werden an den STORK-PVP Gateway &uuml;bertragen (PVP Assertion). Der Gateway validiert die Assertion und generiert eine STORK protokollspezifsche Assertion inkl. Signatur aus den PVP Authentifizierungsdaten (Mapping aller Attribute und Benutzerrollen). Sollte eine direkte Generierung der STORK eID nicht m&ouml;glich sein wird diese an Stammzahlenregister (SZR) abgefragt.</li>
  <li>Optional: Abfrage der STORK eID am Stammzahlenregister.</li>
  <li>Die STORK Assertion wird vom Gateway an den VIDP &uuml;bertragen und am VIDP validiert. Anschlie&szlig;end wird STORK Assertion f&uuml;r die Applikation 1 generiert   und durch den VIDP signiert.</li>
  <li>Die STORK Assertion wird an die Applikation 1 &uuml;bermittelt. Nach g&uuml;ltiger Validierung ist die Benutzerin oder der Benutzer an Applikation 1 authentifiziert.</li>
</ol>
<p>&nbsp;</p>
<p>Die Konfiguration eines STORK-PVP Gateways besteht aus folgenden Elementen.</p>
<table class="configtable">
  <tr>
    <th>Name</th>
    <th>Beispielwert</th>
    <th>Optional</th>
    <th>Beschreibung</th>
  </tr>
  <tr>
    <td>Online-Applikation ist  aktiviert</td>
    <td>&nbsp;</td>
    <td align="center">&nbsp;</td>
    <td>Aktiviert oder deaktiviert den Gatewy. Es k&ouml;nnen nur aktive Gatewaykonfigurationen verwendet werden.</td>
  </tr>
  <tr>
    <td><p>Eindeutiger Identifikator</p></td>
    <td>https://vidp.egiz.gv.at/moa-id-auth/</td>
    <td align="center">&nbsp;</td>
    <td><p>Dieser Parameter dient als Schl&uuml;ssel zum Auffinden der Gateway Konfigurationsparameter. Hierf&uuml;r ist ein eindeutiger Identifikator f&uuml;r die VIDP Instanz erforderlich, welcher diesen Gateway nutzen m&ouml;chte. Dieser eindeutige Identifikator                             muss mindestens dem URL-Pr&auml;fix der nach au&szlig;en                              sichtbaren Dom&auml;ne des VIDP entsprechen</p></td>
  </tr>
  <tr>
    <td><p>Name der <br>
      Online-Applikation</p></td>
    <td>IT STORK-PVP Gateway</td>
    <td align="center">&nbsp;</td>
    <td>Hier muss ein   benutzerfreundlicher Name f&uuml;r den Gateway angegeben werden. </td>
  </tr>
  <tr>
    <td>Privatwirtschaftliche  Applikation</td>
    <td>&nbsp;</td>
    <td align="center">&nbsp;</td>
    <td><p>Definiert ob der VIDP, welcher den Gateway verwendet dem &ouml;ffentlichen Bereich oder dem privatwirtschaftlichen Bereich (Business Service) zugeordnet ist.</p>
    <p><strong>Hinweis</strong>: im STORK Kontext immer privatwirtschaftlich. </p></td>
  </tr>
</table>
<p>&nbsp;</p>
<table class="configtable">
<table class="configtable">
  <tr>
    <th>Name</th>
    <th>Beispielwert</th>
    <th>Optional</th>
    <th>Beschreibung</th>
  </tr>
  <tr>
    <td><span id="wwlbl_loadIDP_pVPGateway_entityID">EntityID des PVP Portals:</span></td>
    <td>&nbsp;</td>
    <td align="center">&nbsp;</td>
    <td><p>Dieser Parameter definiert die EntityID des Stamm- oder Anwendungsportals an welches die Benutzerin oder der Benutzer zur Authentifizierung weitergeleitet werden soll. </p>
    <p><strong>Hinweis:</strong> In der Interfederation Konfiguration muss ein MOA-ID IDP mit der entsprechenden EntityID konfiguriert sein.</p></td>
  </tr>
</table>
<p>&nbsp;</p>
<p>&nbsp;</p>
<h2><a name="referenzierte_spezifikation" id="uebersicht_zentraledatei_aktualisierung30"></a>A Referenzierte Spezifikation</h2>
<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>
    </div>
</body>
</html>