Ab der Version 2.1.0 des Modulpakets MOA-ID unterstü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ät auf einer abstrakten Ebene.
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 Variante mit Redirect Servlet verwendet werden. Eine Verwendung aller anderen, durch das Modul MOA-ID-Auth bereitgestellten Authentifizierungsprotokolle ist jedoch ebenfalls möglich. Aus Gründen der Übersichtlichkeit sind die Schritte 1 - 3 aus dem oben dargestellten Blockdiagramm im Sequenzdiagramm nicht berücksichtigt, da diese Schritte bereits im Kapitel Protokolle im Detail beschrieben wurden.
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önnen oder in einem IDP interfederation Verbund stehen.
Bei IDP Interfederation handelt es sich um eine Erweiterung der Funktionalitä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 Konfiguration.
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 Protokolle -> PVP 2.1.
Zusätzlich zu Basiskonfiguration müssen alle für diese IDP Interfederation registrierten IDPs konfiguriert werden. Diese Konfiguration erfolgt über das Modul MOA-ID-Configuration wobei für Interfederation ein eigener Menüpunkt im Hauptmenü zur Verfügung steht. Über diesen Konfigurationspunkt können neue IDPs hinzugefügt (MOA-ID IDP hinzufügen) oder bestehende IDPs bearbeitet werden wobei alle aktuell hinterlegten IDPs in einer Liste dargestellt werden.
Die Konfiguration der einzelnen IDP Instanzen erfolgt ähnlich zur Konfiguration von Online-Applikationen (siehe Online-Applikationskonfiguration), jedoch sind für eine IDP Konfiguration nicht alle Konfigurationsparameter aus der Online-Applikationskonfiguration erforderlich.
Im ersten Abschnitt werden allgemeine Informationen zum IDP konfiguriert.
| Name | Beispielwert | Optional | Beschreibung |
|---|---|---|---|
| Online-Applikation ist aktiviert | Aktiviert oder deaktiviert den IDP. Es können nur aktive IdentityProvider für IDP Interfederation verwendet werden. | ||
Eindeutiger Identifikatior |
https://demo.egiz.gv.at/demologin/ | Dieser Parameter dient als Schlüssel zum Auffinden der Konfigurationsparameter des IDP. Hierfür ist ein eindeutiger Identifikator für den IDP erforderlich. Dieser eindeutige Identifikator muss mindestens dem URL-Präfix der nach außen sichtbaren Domäne des IDP und der PVP 2.1 EntityID des IDP entsprechen | |
Name der |
Demo Applikation A | Hier muss ein benutzerfreundlicher Name für den IDP angegeben werden. | |
| Privatwirtschaftliche Applikation | Definiert ob der IDP dem öffentlichen Bereich oder dem privatwirtschaftlichen Bereich (Business Service) zugeordnet ist. |
Der zweite Abschnitt behandelt spezielle Konfigurationsparameter für IDP Interfederation.
| Name | Beispielwert | Optional | Beschreibung |
|---|---|---|---|
| Eingehendes SSO erlauben | Ü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. | ||
Ausgehendes SSO erlauben |
Über diesen Parameter kann ausgehende SSO Interfederation zu diesem IDP erlaubt werden. Ist ausgehende SSO Interfederation erlaubt darf dieser IDP SSO Sessioninformation anfordern. | ||
SSO Session speichern |
Wenn eingehende SSO Intefederation erlaubt ist besteht zusätzlich die Möglichkeit diesen einmal verwendeten IDP an die Benutzersession zu binden. In diesem Fall können weitere SSO Authentifizierungen über diesen interfederation IDP auch ohne Angabe des IDP Identifiers (siehe Sequenzdiagramm oder Integration in bestehende Systeme) durchgeführt werden. | ||
| Verwende SAML2 isPassive Attribut | Wird dieser Parameter aktiviert erfolgt der Authentifizierungsrequest im Schritt 9 (siehe Sequenzdiagramm) unter Verwendung des SAML 2 isPassiv 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ührt. | ||
| Im Fehlerfall Authentifizierung lokal durchführen | Wird dieser Parameter aktiviert erfolgt im Falle eines returnierten Fehlers im Schritt 11 (siehe Sequenzdiagramm) keine lokale Authentifizierung und dem Service Provider wird eine Fehlermeldung returniert. |
||
| AttributQuery Service URL | https://demo.egiz.gv.at/moa-id-auth/pvp2/attributequery | X | URL auf das Attribute-Query Service des konfigurierten IDP. Über dieses WebService werden die Authentifizierungsdaten vom IDP abgeholt. Hinweis: Wenn kein Service konfiguriert ist müssen alle für den Anmeldevorgang benötigten Informationen bereits in der Assertion im Schritt 11 (siehe Sequenzdiagramm) übermittelt werden. |
Der dritte Abschnitt behandelt die PVP 2.1 Konfiguration des IDP. Da diese Konfiguration identisch zur PVP 2.1 Konfiguration für Online-Applikationen ist wird auf entsprechende Kapitel in der Online-Applikationskonfiguration verwiesen.
Hinweis: Bei der Speicherung der Konfiguration und bei jedem Ladevorgang der Konfiguration im Modul MOA-ID-Auth wird überprüft ob der IDP die Anforderungen an einen öffentlichen IDP erfüllt. Die Überprüfung erfolgt auf Basis der PVP 2.1 Metadaten URL des IDP und diese muss mindestens eine der folgenden Anforderungen erfüllt sein. Schlägt die Überprüfung fehl, kann der IDP nicht gespeichert werden oder wird durch das Modul MOA-ID-Auth aus der aktuell geladenen Konfiguration entfernt.
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ätzlicher Parameter angefügt werden. Dieser Parameter identifiziert den interfederation IDP von welchem eine aktive SSO Session verwendet werden soll. Dieser zusätzliche Parameter kann als http GET oder als http POST Parameter an MOA-ID-Auth übertragen werden.
| Name | Beispielwert | Beschreibung |
|---|---|---|
| interIDP | https://demo.egiz.gv.at/moa-id-auth | Ist der eindeutige Identifikator für den interfederation IDP von welchem die aktive SSO Session verwendet werden soll. Hinweis: Ist dieser IDP nicht konfiguriert oder die Konfiguration des IDP nicht aktiv wird eine lokale Authentifizierung mittels Bürgerkarte oder Handy-Signatur durchgeführt. |
Wie bereits im Abschnitt Sequenzdiagramm erwähnt stehen für die Übertragung des zusätzlichen Parameters zwei Varianten zur Verfügung.
Bei dieser Variante wird der zusätzliche Parameter interIDP direkt im protokollspezifischen Authentifizierungsrequest, welcher den Authentifizierungsvorgang startet, angefügt. In diesem Fall muss der Service Provider, welcher den Authentifizierungsrequest erzeugt, den zusätzlichen Parameter interIDP einfügen. Diese Variante steht für alle verfügbaren Authentifizierungsvarianten des Modules MOA-ID-Auth zur Verfügung und es existieren keine besonderen Einschränkungen. Das nachfolgende Beispiel zeigt die Verwendung in Kombination mit SAML 1 wobei der interIDP Parameter als http GET Parameter übermittelt wird.
<a href="https://<moa-id-server-und-pfad>/StartAuthentication ?Target=<geschäftsbereich> &OA=<oa-url> &bkuURI=<bku-url> &interIDP=<IDP EntityID> >
Bei dieser Variante wird der zusätzliche Parameter interIDP und eine Redirect-URL redirecturl an ein Service der MOA-ID-Auth Instanz übermittelt. Dieses Service validiert alle Parameter und hinterlegt den Parameter interIDP in einem http Cookie im Browser der Benutzerin oder des Benutzers. Anschließ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ätzlichen Parameter interIDP enthält, da dieser über das zuvor gesetzte http Cookie vom Modul MOA-ID-Auth ausgewertet wird.
| Name | Beispielwert | Beschreibung |
|---|---|---|
| interIDP | https://demo.egiz.gv.at/moa-id-auth | Ist der eindeutige Identifikator für den interfederation IDP von welchem die aktive SSO Session verwendet werden soll. Hinweis: Ist dieser IDP nicht konfiguriert oder die Konfiguration des IDP nicht aktiv wird eine lokale Authentifizierung mittels Bürgerkarte oder Handy-Signatur durchgeführt. |
| redirecturl | https://demo.egiz.gv.at/moa-id-oa/servlet/pvp2login | URL auf die nach erfolgreicher Validierung aller Parameter weitergeleitet wird. Das hier angegebene Service erzeugt den eigentlichen applikationsspezifischen Authentifizierungsrequest. Hinweis: Die angegebene URL muss als Prefix identisch mit dem eindeutigen Identifier der jeweiligen Online-Applikation sein. |
Das Modul MOA-ID-Auth kann auch als STORK2 VIDP betrieben werden. Diese VIDP Konfiguration erfolgt ebenfalls über den Menüpunkt Interfederation, wobei neues VIDPs mit Hilfe der Schaltfläche VIDP hinzufügen konfiguriert werden können.
Die Konfiguration eines VIDPs erfolgt weitgehend identisch zur Konfiguration einer Online-Applikation, wobei im Falle eines VIDPs noch folgende zusätzliche Konfigurationsparameter zur Verfügung stehen.
| Name | Beispielwert | Optional | Beschreibung |
|---|---|---|---|
VIDP Interface aktiv |
X | Stellt fest, ob das VIDP Interface aktiviert wird. |
|
Zustimmung für das Ausliefern der Attribute |
X | Stellt fest, ob die Zustimmung für das Ausliefern der Attribute vom Benutzer erforderlich ist. Diese Zustimmung ist für grenzübergreifenden Datenverkehr aufgrund Datenschutzbestimmungen oft notwendig. |
Außerdem können zusätzliche Attributproviders eingetragen werden. Diese Attributprovider werden für die Abholung einiger Attribute von österreichischen Bürgern benötigt (Anmeldung in Ausland). Die Eintragung und Auswahl von Attributprovidern ist optional.
Während des Anmeldevorgangs wird der Benutzer an den entsprechenden Attributprovider weitergeleitet. Am Attributprovider werden die erforderlichen Attribute ausgewählt und zurück an VIDP (am Service Provider) geliefert.
| Name des Plugins | Beschreibung |
|---|---|
| EHvdAttributeProvider | Für Gesundheitsbereich spezifisches Attributprovider. |
| SignedDocAttributeRequestProvider | Attributprovider verwendet für die Signatur von Dokumenten (Signatur Service). |
| MISAttributeRequestProvider | Attributprovider verwendet für die Vertretungsfälle. |
| StorkAttributeRequestProvider | Allgemeines Plugin, wird verwendet für die Restfälle. |
| PVPAuthenticationProvider | Dieser Provider dient zur Authentifizierung des Benutzers über den Portalverbund der österreichischen Behö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 über den VIDP an den Service Provider weitergereicht werden. Als URL ist der Link auf den nationalen STORK<->PVP Gateway zu hinterlegen. Hinweis: Aktuell fordert folgende Attribute eine nationale Authentifizierung:
|
Beispiel eines Eintrages für Attributprovider:
| AP Plugin | URL | Attribute |
|---|---|---|
| MISAttributeRequestProvider | http://mis.testvidp.at/moa-id-auth/stork2/MISProvider | mandateContent,attribut1,attribut2 |
Das Modul MOA-ID-Auth kann auch als Gateway zwischen dem Portalverbund der österreichischen Behörden und der STORK Infrastruktur betrieben werden. Diese Konfiguration konfiguriert einen Gateway welcher zur Authentifizierung österreichischer Benutzerinnen oder Benutzer im Falle einer STORK Anmeldung mit Hilfe der österreichischen PVP Infrastruktur dient. Der Einsprung zum Gateway erfolgt über den PVPAuthenticationProvider in der VIDP Konfiguration.
Die nachstehende Grafik skizziert den Prozessfluss eines solchen Anmeldevorgangs.
Die Konfiguration eines STORK-PVP Gateways besteht aus folgenden Elementen.
| Name | Beispielwert | Optional | Beschreibung |
|---|---|---|---|
| Online-Applikation ist aktiviert | Aktiviert oder deaktiviert den Gatewy. Es können nur aktive Gatewaykonfigurationen verwendet werden. | ||
Eindeutiger Identifikator |
https://vidp.egiz.gv.at/moa-id-auth/ | Dieser Parameter dient als Schlüssel zum Auffinden der Gateway Konfigurationsparameter. Hierfür ist ein eindeutiger Identifikator für die VIDP Instanz erforderlich, welcher diesen Gateway nutzen möchte. Dieser eindeutige Identifikator muss mindestens dem URL-Präfix der nach außen sichtbaren Domäne des VIDP entsprechen |
|
Name der |
IT STORK-PVP Gateway | Hier muss ein benutzerfreundlicher Name für den Gateway angegeben werden. | |
| Privatwirtschaftliche Applikation | Definiert ob der VIDP, welcher den Gateway verwendet dem öffentlichen Bereich oder dem privatwirtschaftlichen Bereich (Business Service) zugeordnet ist. Hinweis: im STORK Kontext immer privatwirtschaftlich. |
| Name | Beispielwert | Optional | Beschreibung |
|---|---|---|---|
| EntityID des PVP Portals: | Dieser Parameter definiert die EntityID des Stamm- oder Anwendungsportals an welches die Benutzerin oder der Benutzer zur Authentifizierung weitergeleitet werden soll. Hinweis: In der Interfederation Konfiguration muss ein MOA-ID IDP mit der entsprechenden EntityID konfiguriert sein. |
| Spezifikation | Link |
|---|---|
Security Layer Spezifikation V1.2.0 |
http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20140114/ |
| PVP 2.1 S-Profil Spezifikation | http://reference.e-government.gv.at/uploads/media/PVP2-S-Profil_2_0_0_a-2011-08-31.pdf |
| OpenID Connect | http://openid.net/connect/ |
| STORK 2 | @TODO Link |
| Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0 | http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf |
| Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 | http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf |
| Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V1.1 | https://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf |
