From 8d8682e6f269d05d282b722d8dda08b075e71bf4 Mon Sep 17 00:00:00 2001 From: Thomas Lenz Date: Fri, 23 May 2014 11:09:30 +0200 Subject: Finalize IDP interfederation handbook --- id/server/doc/handbook/config/config.html | 72 +----- .../doc/handbook/interfederation/blockdiagramm.png | Bin 0 -> 31933 bytes .../handbook/interfederation/interfederation.html | 270 ++++++++++++++++++++- .../interfederation/interfederation_sequenz.png | Bin 0 -> 60391 bytes id/server/doc/handbook/protocol/protocol.html | 5 + 5 files changed, 269 insertions(+), 78 deletions(-) create mode 100644 id/server/doc/handbook/interfederation/blockdiagramm.png create mode 100644 id/server/doc/handbook/interfederation/interfederation_sequenz.png (limited to 'id') diff --git a/id/server/doc/handbook/config/config.html b/id/server/doc/handbook/config/config.html index cda71f616..a2de0539e 100644 --- a/id/server/doc/handbook/config/config.html +++ b/id/server/doc/handbook/config/config.html @@ -124,7 +124,6 @@
  • SAML 1
  • PVP 2.1
  • OpenID Connect
    • -
  • VIDP Konfiguration
  • Zusätzliche allgemeine Einstellungen @@ -1604,7 +1603,7 @@ Soll die Bürgerkartenauswahl weiterhin, wie in MOA-ID 1.5.1 im Kontext der

        - Stammzahl eines privatwirtschaftlichen Unternehmens oder Ländercode des STORK Service-Providers bei Verwendung des Modules MOA-ID als STORK VIDP. Die Angabe erfolgt durch den Prefix des Bereichs aus dem die Stammzahl stammt und der eigentlichen Stammzahl oder des Ländercodes im Falle von STORK. + Stammzahl eines privatwirtschaftlichen Unternehmens oder Ländercode des STORK Service-Providers bei Verwendung des Modules MOA-ID als STORK VIDP. Die Angabe erfolgt durch den Prefix des Bereichs aus dem die Stammzahl stammt und der eigentlichen Stammzahl oder des Ländercodes im Falle von STORK. @@ -1900,74 +1899,9 @@ Soll die Bürgerkartenauswahl weiterhin, wie in MOA-ID 1.5.1 im Kontext der OpenID Connect Redirect URL. Nach erfolgreicher Authentifizierung wird die BenutzerIn oder der Benutzer an diese URL zurückgeleitet. -

    3.2.6.4 VIDP Konfiguration

    -

    Dieser Abschnitt dient zur Konfiguration des VIDP Modus des Modules MOA-ID-Auth. Die Konfiguration der nachfolgenden Parameter ist somit nur nötig wenn die MOA-ID-Auth Instanz als STORK2 VIDP betrieben werden soll.

    - - - - - - - - - - - - - - - - - - - -
    NameBeispielwertOptionalBeschreibung

    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 Datenschützbestimmungen oft notwendig.

    -

     

    -

    Außerdem können zusätzliche Attributsproviders eingetragen werden. -Diese Attributprovider werden für die Abholung einiger Attributen von österreichischen Bürger benötigt (Anmeldung in Ausland). Die Eintragung und Auswahl von Attributprovidern ist optional.

    -

    Während des Anmeldevorgangs wird der Benutzer an den entsprechenden Attributtprovider weitergeleitet. Am Attributprovider werden die erforderlichen Attribute ausgewählt und zurück an VIDP (am ServiceProvider) geliefert.

    -
    - - - - - - - - - - - - - - - - - - - - - - -
    Name des PluginsBeschreibung
    EHvdAttributeProviderFür Gesundheitsbereich spezifisches Attributprovider.
    SignedDocAttributeRequestProviderAttributprovider verwendet für die Signatur von Dokumenten (Signature Service).
    MISAttributeRequestProviderAttributprovider verwendet für die Vertretungsfälle.
    StorkAttributeRequestProviderAllgemeines Plugin, wird verwendet für die Restfälle.
    -

     

    -

    Beispiel eines Eintrages für Attributprovider:

    -
    
-  
-    
-    
-    
-  
-  
-    
-    
-    
-  
-
    AP PluginURLAttribute
    MISAttributeRequestProviderhttp://mis.testvidp.at/moa-id-auth/stork2/MISProvidermandateContent,attribut1,attribut2
    -

     

    -

    3.2.7 Zusätzliche allgemeine Einstellungen

    +

    3.2.7 Zusätzliche allgemeine Einstellungen

    In Abschnitt ermöglicht eine erweiterte online-applikationsspezifische Individualisierung des AuthBlocks und der Bürgerkartenauswahl. -Die Individualisierung des AuthBlocks steht jedoch dann zur Verfügung wenn die dem Module MOA-ID-Auth beigelegte Security-Layer Transformation verwendet wird oder + Die Individualisierung des AuthBlocks steht jedoch dann zur Verfügung wenn die dem Module MOA-ID-Auth beigelegte Security-Layer Transformation verwendet wird oder wenn die individuelle Security-Layer Transformation den Formvorschriften der Spezifikation entspricht.

    diff --git a/id/server/doc/handbook/interfederation/blockdiagramm.png b/id/server/doc/handbook/interfederation/blockdiagramm.png new file mode 100644 index 000000000..8a1f6a49a Binary files /dev/null and b/id/server/doc/handbook/interfederation/blockdiagramm.png differ 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 @@

    Inhalt

      -
    1. Allgemeines +
    2. Allgemeines
        -
      1. .
        2. +
      2. Sequenzdiagramm
      3. +
    3. Konfiguration +
        +
      1. Basiskonfiguration
        2. +
      2. Konfiguration einzelner IDPs
        3. +
      +
      4. +
    4. Integration in bestehende Systeme +
        +
      1. Direkte Übermittlung im Authentifizierungsrequest
        2. +
      2. Verwendung des Redirekt Servlets
        3. +
      +
      5. +
    5. STORK VIDP Konfiguration
      6. +
    +

     

    +

    1 Allgemeines

    +

    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.

    +

    Blockdiagramm MOA-ID Inderfederation

    +
      +
    1. Eine Benutzerin oder ein Benutzer möchte sich an einer Online Applikation (Applikation 1) oder einem Service Portal anmelden.
      2. +
    2. Für den Anmeldevorgang wird die Benutzerin oder der Benutzer an den IdentityProvider (MOA-ID IDP 1) welcher die Identifizierung und Authentifizierung durchführt und eine Single Sign-On (SSO) Session anlegt.
      3. +
    3. Anschließend wir die Benutzerin oder der Benutzer an die Online Applikation zurückgeleitet und befindet sich im angemeldeten Bereich der Applikation 1.
      4. +
    4. Applikation 1 bieten die Mö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.
      5. +
    5. Da die Benutzerin oder der Benutzer an Applikation zwei noch nicht authentifiziert ist wird ein Anmeldevorgang über den IDP 2 gestartet, welcher die Information enthält dass es eine aktive SSO Session an IDP 1 gibt.
      6. +
    6. IDP 2 holt von IDP 1 die Authentifizierungsinformationen für Applikation 2 ab. Für die Kommunikation zwischen den beiden IDPs wird PVP 2.1 als Protokoll verwendet. Sollte am IDP 1 keine aktive SSO Session für diesen Benutzer existieren wird eine lokale Authentifizierung der Benutzerin oder des Benutzer an IDP 2 gestartet.
      7. +
    7. Anschließend wird die Benutzerin oder der Benutzer an Applikation 2 zurückgeleitet und befindet sich im angemeldeten Bereich der Applikation 2.
      8. +
    +

    1.1 Sequenzdiagramm

    +

    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.

    +

    SSO Interfederation Sequenze

    +

     

    +
      +
    1. Die Benutzerin oder der Benutzer ist bereits an einer Online Applikation (Application 1) angemeldet und möchte sich nun an einer zweiten Online Applikation (Application 2) mittels Single Sign On anmelden. Nach dem Click auf die entsprechende Login Schaltfläche wird der Anmeldevorgang gestartet.
      2. +
    2. Es erfolgt ein SSO Login Request auf ein Redirekt Servelt von MOA-ID 2. Dieser Request beinhaltet einen eindeutigen Identifier fü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:
      3. +
        +
      • interIDP: eindeutiger Identifier des interfederation IDP welcher für die Benutzerin oder den Benutzer eine aktive SSO Session hält.
        • +
      • redirecturl: URL an welche der Benutzer anschließend weitergeleitet wird.
        • +
      +
    3. Das Redirect Servlet validiert den Request. Hierbei wird geprüft ob die Redirekt URL zu einer bei MOA-ID 2 registrierten Online Applikation passt. Wenn ja, wird der eindeutige Identifier des IDP gespeichert.
      4. +
    4. Die Benutzerin oder der Benutzer wird an die im Request angegebene URL, welche den eigentlichen Authentifizierungsrequest erzeugt, weitergeleitet.
      5. +
    5. Online Applikation zwei erzeugt den Authentifizierungsrequest.
      6. +
    6. Der Authentifizierungsrequest wird über den Browser an MOA-ID 2 gesendet.
      + Hinweis: Der eindeutige Identifier des interfederation IDPs (http GET Parameter interIDP=xxxxxxx), welcher eine aktive SSO Session für die Benutzerin oder den Benutzer besitzt, kann auch direkt in diesem Schritt an MOA-ID 2 übergeben werden. In diesem Fall können die Schritte 2 bis 5 entfallen.
      7. +
    7. Validierung des Authentifizierungsrequests von Online Applikation zwei.
      8. +
    8. Wurde der Parameter interIDP gesetzt erfolgt keine lokale Authentifizierung. In diesem Fall wird ein interfederation Authentifizierungsrequest generiert welcher als IDP MOA-ID 1 verwendet.
      9. +
    9. Der interfederation Authentifizierungsrequest wird an MOA-ID 1 gesendet.
      10. +
    10. MOA-ID 1 validiert den Authentifizierungsrequest und generiert eine Assertion für MOA-ID 2 welche SessionTokken für die Benutzerin oder den Benutzer enthält. In diesem Schritt werden jedoch noch keine personenbezogenen Daten ausgetauscht.
      11. +
    11. Die Assertion wird an MOA-ID 2 zurückgesendet.
      12. +
    12. MOA-ID 2 validiert die Assertion und extrahiert das SessionTokken.
      + Hinweis: 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ürgerkarte oder Handy-Signatur durchgeführt.
      13. +
    13. MOA-ID 2 generiert einen Attribut Request mit den von Online Applikation 2 angeforderten Attributen und sendet diesen über SOAP Binding an MOA-ID 1.
      14. +
    14. MOA-ID 1 generiert eine Assertion mit den angeforderten Attributen für Online Applikation 2 und sendet diese an MOA-ID 2.
      15. +
    15. MOA-ID 2 generiert eine Assertion für Online Applikation 2
      16. +
    16. 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öglich.
      17. +
    17. Die Assertion wird an die Online Applikation 2 gesendet
      18. +
    18. Online Applikation 2 validiert die Assertion
      19. +
    19. Wurde die Validierung der Assertion positiv abgeschlossen wird der Benutzer im sicheren Bereich von Online Applikation zwei angemeldet.
    -

     

    -

    Allgemeines

    -

    Ab der Version 2.0.2 des Modulepackets 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.

    -

     

    -

     

    -

     

    -

     

    +

    2 Konfiguration

    +

    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.

    +

    2.1 Basiskonfiguration

    +

    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.

    +

    2.2 Konfiguration einzelner IDPs

    +

    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.

    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    NameBeispielwertOptionalBeschreibung
    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
    + Online-Applikation

    		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.

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    NameBeispielwertOptionalBeschreibung
    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.
    AttributQuery Service URLhttps://demo.egiz.gv.at/moa-id-auth/pvp2/attributequery 

    URL auf das Attribute-Query Service des konfigurierten IDP. Über dieses WebService werden die Authentifizierungsdaten vom IDP abgeholt.

    +

     

    +

    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.

    + +

    3 Integration in bestehende Systeme

    +

    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.

    + + + + + + + + + + + +
    NameBeispielwertBeschreibung
    interIDPhttps://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.

    +

    3.1 Direkte Übermittlung im Authentifizierungsrequest

    +

    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>
+>
    +

    3.2 Verwendung des Redirekt Servlets

    +

    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.

    + + + + + + + + + + + + + + + + +
    NameBeispielwertBeschreibung
    interIDPhttps://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.

    redirecturlhttps://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.

    +

     

    +

    4 STORK VIDP Konfiguration

    +

    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.

    + + + + + + + + + + + + + + + + + + + +
    NameBeispielwertOptionalBeschreibung

    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 PluginsBeschreibung
    EHvdAttributeProviderFür Gesundheitsbereich spezifisches Attributprovider.
    SignedDocAttributeRequestProviderAttributprovider verwendet für die Signatur von Dokumenten (Signatur Service).
    MISAttributeRequestProviderAttributprovider verwendet für die Vertretungsfälle.
    StorkAttributeRequestProviderAllgemeines Plugin, wird verwendet für die Restfälle.
    +

     

    +

    Beispiel eines Eintrages für Attributprovider:

    +
    
+  
+    
+    
+    
+  
+  
+    
+    
+    
+  
+
    AP PluginURLAttribute
    MISAttributeRequestProviderhttp://mis.testvidp.at/moa-id-auth/stork2/MISProvidermandateContent,attribut1,attribut2
    
+
    +

     

    A Referenzierte Spezifikation

    diff --git a/id/server/doc/handbook/interfederation/interfederation_sequenz.png b/id/server/doc/handbook/interfederation/interfederation_sequenz.png new file mode 100644 index 000000000..929b44df1 Binary files /dev/null and b/id/server/doc/handbook/interfederation/interfederation_sequenz.png differ diff --git a/id/server/doc/handbook/protocol/protocol.html b/id/server/doc/handbook/protocol/protocol.html index 40277aa6b..03a31a2bf 100644 --- a/id/server/doc/handbook/protocol/protocol.html +++ b/id/server/doc/handbook/protocol/protocol.html @@ -104,6 +104,11 @@ Redirect Binding + + + + +
    https://<host>:<port>/moa-id-auth/pvp2/redirect
    PVP 2.1Attribut Query für IDP Interfederationhttps://<host>:<port>/moa-id-auth/pvp2/attributequery
    OpenID Connect Authentifizierungsrequest
    -- cgit v1.2.3