From 4be68fb9fecc579e2dae08be0af0b527d69387d8 Mon Sep 17 00:00:00 2001 From: Christian Maierhofer Date: Wed, 7 Jan 2015 13:43:17 +0100 Subject: new format(css) for the handbook --- id/server/doc/handbook/protocol/protocol.html | 329 +++++++++++++------------- 1 file changed, 165 insertions(+), 164 deletions(-) (limited to 'id/server/doc/handbook/protocol/protocol.html') diff --git a/id/server/doc/handbook/protocol/protocol.html b/id/server/doc/handbook/protocol/protocol.html index 1c6e51661..2989ca4af 100644 --- a/id/server/doc/handbook/protocol/protocol.html +++ b/id/server/doc/handbook/protocol/protocol.html @@ -6,19 +6,19 @@ - - - - - - -
Logo BKADokumentationLogo EGIZ
-
-

MOA-ID (Identifikation)

-

Protokolle

-
-

Inhalt

-
    +
    +
    + +

    MOA-ID-AUTH

    +
    +
    +
    + +
    +

    Protokolle

    + +

    Inhalt

    +
    1. Allgemeines
      1. Übersicht der Zugangspunkte
      2. @@ -78,18 +78,18 @@
      3. Referenzierte Spezifikation
      -
      -

      1 Allgemeines

      -

      Dieses Kapitel behandelt jene Authentifizierungsprotokolle die vom Modul MOA-ID-Auth unterstützt werden. + +

      1 Allgemeines

      +

      Dieses Kapitel behandelt jene Authentifizierungsprotokolle die vom Modul MOA-ID-Auth unterstützt werden. Wobei die Verwendung der Protokolle PVP 2.1 oder OpenID Connect empfohlen wird. Das Protokoll SAML 1, welches bis zur MOA-ID Version 1.5.1 - verwendet wurde, wird jedoch ab der Version 2.0 nur mehr aus Kompatibilitätsgründen angeboten und nicht mehr aktiv weiterentwickelt.

      -

      1.1 Übersicht der Zugangspunkte

      + verwendet wurde, wird jedoch ab der Version 2.0 nur mehr aus Kompatibilitätsgründen angeboten und nicht mehr aktiv weiterentwickelt.

      +

      1.1 Übersicht der Zugangspunkte

      In diesem Abschnitt sind die Zugangspunkte der vom Modul MOA-ID-Auth unterstützten Protokolle kurz zusammengefasst. Eine detaillierte Beschreibung der einzelnen Protokolle finden Sie in den anschließenden Unterkapiteln.

      - +
      - - - + + + @@ -122,12 +122,12 @@ Redirect Binding - + - + @@ -153,21 +153,21 @@ Redirect Binding

      http://<host>:<port>/moa-id-auth/idpSingleLogout

      ProtokollRequesttypURLProtokollRequesttypURL
      PVP 2.1 OpenID Connect Authentifizierungsrequest
      (AuthCode-Request)
      https://<host>:<port>/moa-id-auth/oauth2/authhttps://<host>:<port>/moa-id-auth/oauth3/auth
      OpenID Connect

      AccessToken-Request

      https://<host>:<port>/moa-id-auth/oauth2/tokenhttps://<host>:<port>/moa-id-auth/oauth3/token
      SAML 1
      -

      1.2 Übersicht der möglichen Attribute

      +

      1.2 Übersicht der möglichen Attribute

      Die nachfolgende Tabelle beinhaltet eine Liste aller Attribute die vom Modul MOA-ID-Auth an die Online-Applikation zurückgeliefert werden können, sofern diese nach der Authentifizierung zur Verfügung stehen. Alle Namen beziehen sich auf den Attributnamen im jeweiligen Protokoll. Detailinformationen zu den einzelnen Attributen finden Sie in der PVP 2.1 Spezifikation der der STORK Spezifikation.

      - +
      - + - + - + - - + + @@ -515,16 +515,16 @@ Redirect Binding

      Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung.

      ProtokolleBeschreibungBeschreibung
      PVP 2.1PVP 2.1 OpenID ConnectSAML 1SAML 1
      NameProfilNameProfil
      urn:oid:1.2.40.0.10.2.1.1.149
      -

      1.3 Übersicht der möglichen MOA-ID spezifischen Statuscodes

      +

      1.3 Übersicht der möglichen MOA-ID spezifischen Statuscodes

      Vom Modul MOA-ID-Auth werden verschiedene Authentifizierungsprotokolle wobei diese Protokolle die Fehlerrückgabe unterschiedlich spezifizieren. Zusätzlich zu den protokollabhängigen Statuscodes (siehe Spezifikation des jeweiligen Protokolls) werden zusätzliche protokollunabhängige Statuscodes an den Service Provider zurückgeliefert, wobei sich das Format der Fehlerrückgabe jedoch weiterhin protokollspezifisch ist.

      Die nachfolgende Tabelle zeigt alle protokollunabhängigen Statuscodes welche vom Modul MOA-ID-Auth zurückgeliefert werden können.

      -

      1.3.1 Statuscodes 1xxxx

      +

      1.3.1 Statuscodes 1xxxx

      Alle Statuscodes beginnend mit der Zahl eins beschreiben Fehler welche während des Identifizierungs- und Authentifizierungsvorgangs aufgetreten sind.

      -

      1.3.1.1 Authentifizierung (10xxx)

      - +
      1.3.1.1 Authentifizierung (10xxx)
      +
      - - + + @@ -559,11 +559,11 @@ Redirect Binding
      StatuscodeBeschreibungStatuscodeBeschreibung
      1000 Vollmachtsmodus für ausländische Personen wird nicht unterstützt.
      -

      1.3.1.2 Validierung (11xxx)

      - +
      1.3.1.2 Validierung (11xxx)
      +
      - - + + @@ -606,11 +606,11 @@ Redirect Binding
      StatuscodeBeschreibungStatuscodeBeschreibung
      1100 Fehler beim Validieren der SZR-Gateway Response
      -

      1.3.1.3 STORK (12xxx)

      - +
      1.3.1.3 STORK (12xxx)
      +
      - - + + @@ -637,16 +637,16 @@ Redirect Binding
      StatuscodeBeschreibungStatuscodeBeschreibung
      1200 Der geforderte QAA Level ist höher als der QAA Level der gewählten Authentifizierungsmethode
      -

      1.3.2 Statuscodes 4xxxx

      +

      1.3.2 Statuscodes 4xxxx

      Alles Statuscodes beginnend mit der Zahl vier beschreiben Fehler die während der Kommunikation mit externen Services aufgetreten sind.

      -

      1.3.2.1 BKU (40xxxx)

      +
      1.3.2.1 BKU (40xxxx)

      Tritt während des Anmeldevorgangs in der Bürgerkartenumgebung ein Fehler auf so wird der entsprechende Fehlercode an den Service Provider weitergereicht. Der der durch das Modul MOA-ID-Auth weitergereichte Statuscode für Bürgerkartenumgebungsfehler weißt das folgende zweiteilige Format auf. Der erste Teil, bestehend aus zwei Dezimalstellen, kennzeichnet den Fehler als Fehler als Bürgerkartenumgebungsfehler. Der zweite Teil, bestehend aus vier Dezimalstellen bezeichnet den eindeutigen Identifikator des Fehlers aus der Bürgerkartenumgebung (siehe SecurityLayer Spezifikation).

      {40}{xxxxx}

      {40} ... MOA-ID Statuscode für Fehler aus der Bürgerkartenumgebung

      {xxxx} .... Fehlercode der Bürgerkartenumgebung.

      -

      1.3.2.2 MIS (41xxxx)

      +
      1.3.2.2 MIS (41xxxx)

      Tritt während der Kommunikation mit dem Online-Vollmachten Service oder der Vollmachtsauswahl ein Fehler auf so wird der entsprechende Fehlercode an den Service Provider weitergereicht. Der der durch das Modul MOA-ID-Auth weitergereichte Statuscode für Fehler aus dem Online-Vollmachten Service weißt das folgende zweiteilige Format auf. Der erste Teil, bestehend aus drei Dezimalstellen, kennzeichnet den Fehler als Fehler als Online-Vollmachten Service Fehler. Der zweite Teil, bestehend aus drei Dezimalstellen bezeichnet den eindeutigen Identifikator des Fehlers aus dem Online-Vollmachten Service (siehe Online-Vollmachten Spezifikation).

      {411}{xxxx}

      @@ -654,10 +654,10 @@ Redirect Binding

      {xxx} .... Fehlercode des Online-Vollmachten Service.

      Zusätzlich zu den gemappten Fehlern aus dem Online-Vollmachen Service werden zusätzliche weitere Fehlercodes definiert.

      - +
      - - + + @@ -668,11 +668,11 @@ Redirect Binding
      StatuscodeBeschreibungStatuscodeBeschreibung
      41000 Allgemeiner Fehler bei der Kommunikation mit dem Online-Vollmachten Service
      -

      1.3.2.3 SZR-Gateway (42xxx)

      - +
      1.3.2.3 SZR-Gateway (42xxx)
      +
      - - + + @@ -683,35 +683,35 @@ Redirect Binding
      StatuscodeBeschreibungStatuscodeBeschreibung
      4200 Die Antragung in das SZR ist fehlgeschlagen
      -

      1.3.2.4 MOA SP/SS(43xxx)

      - +
      1.3.2.4 MOA SP/SS(43xxx)
      +
      - - + +
      StatuscodeBeschreibungStatuscodeBeschreibung
      4300 Fehler beim Aufruf von MOA SP/SS
      -

      1.3.2.5 Interfederation (44xxx)

      - +
      1.3.2.5 Interfederation (44xxx)
      +
      - - + +
      StatuscodeBeschreibungStatuscodeBeschreibung
      4400 Fehler beim Generieren der Anmeldedaten
      -

      1.3.3 Statuscodes 6xxxx

      +

      1.3.3 Statuscodes 6xxxx

      Alles Statuscodes beginnend mit der Zahl sechs beschreiben protokollspezifische Fehler die nicht durch das jeweilige Authentifizierungsprotokoll abgebildet werden.

      -

      1.3.3.1 Allgemein (61xxx)

      - +
      1.3.3.1 Allgemein (61xxx)
      +
      - - + + @@ -722,11 +722,11 @@ Redirect Binding
      StatuscodeBeschreibungStatuscodeBeschreibung
      6000 Der STORK Request wurde nicht erkannt oder wird nicht unterstützt
      -

      1.3.3.2 PVP 2.1 (61xxx)

      - +
      1.3.3.2 PVP 2.1 (61xxx)
      +
      - - + + @@ -753,35 +753,35 @@ Redirect Binding
      StatuscodeBeschreibungStatuscodeBeschreibung
      6100 Der Request konnte nicht gültig validiert werden.
      -

      1.3.3.3 OpenID Connect (62xxx)

      - +
      1.3.3.3 OpenID Connect (62xxx)
      +
      - - + +
      StatuscodeBeschreibungStatuscodeBeschreibung
      6200 Fehlerhafte redirect url
      -

      1.3.3.4 SAML 1(63xxx)

      - +
      1.3.3.4 SAML 1(63xxx)
      +
      - - + +
      StatuscodeBeschreibungStatuscodeBeschreibung
      6300 Fehlerhaftes SAML Artifact Format
      -

      1.3.4 Statuscodes 9xxxx

      +

      1.3.4 Statuscodes 9xxxx

      Alles Statuscodes beginnend mit der Zahl neun beschreiben interne Serverfehler.

      -

      1.3.4.1 Konfigurationsfehler (90xxx)

      - +
      1.3.4.1 Konfigurationsfehler (90xxx)
      +
      - - + + @@ -816,11 +816,11 @@ Redirect Binding
      StatuscodeBeschreibungStatuscodeBeschreibung
      9000 Der SZR-Gateway Client konnte nicht initialisiert werden.
      -

      1.3.4.2 Interne Fehler (91xxx)

      - +
      1.3.4.2 Interne Fehler (91xxx)
      +
      - - + + @@ -844,7 +844,7 @@ Redirect Binding
      StatuscodeBeschreibungStatuscodeBeschreibung
      9100

       

      -

      1.4 Single Sign-On

      +

      1.4 Single Sign-On

      Das Modul MOA-ID-Auth unterstützt ab der Version 2.0 Single Sign-On (SSO), wobei diese Funktionalität unabhängig vom verwendeten Protokoll ist. Bei Verwendung von SSO muss sich der Benutzer nur ein Mal bei MOA-ID-Auth authentifizieren und danach steht die authentifizierte Session für die Benutzerin oder den Benutzer für weitere Anmeldevorgänge ohne weitere Authentifizierung mittels Bürgerkarte, Handy-Signatur oder STORK zur Verfügung. Die SSO Session kann danach durch die Benutzerin oder den Benutzer beendet werden, oder sie wird von MOA-ID-Auth nach der maximal erlaubten Sessionzeit serverseitig beendet.

      Das nachfolgende Sequenzdiagramm zeigt eine Anmeldung mittels Single Sign-On an zwei Online-Applikationen unter Verwendung von PVP 2.1. Aus Gründen der Übersichtlichkeit wurden die Teile welche die Kommunikation mit der Bürgerkartenumgebung, die Vollmachten-Auswahl oder den Metadatenaustausch betreffen bewusst nicht berücksichtigt.

      Sequenzdiagramm einer Anmeldung mittels Single Sign-On

      @@ -873,7 +873,7 @@ Redirect Binding
    2. Ist die Validierung der Assertion erfolgreich wird die Benutzerin oder der Benutzer an der Online-Applikation 2 angemeldet

    Zusätzliche Informationen zur Konfiguration und die sich daraus ergebenden Anforderungen oder Einschränkungen finden sie hier.

    -

    1.5 SSO Logout

    +

    1.5 SSO Logout

    Das Modul MOA-ID-Auth stellt ein einfaches Service zur Beendigung einer bestehenden Single Sign-On Session zur Verfügung. Nach dem Aufruf dieses Service aus dem Browser des Users wird eine bestehende SSO Session beendet und anschließend wird die Benutzerin oder der Benutzer an eine im LogOut Request angegebene URL weitergeleitet.

    Das SSO Logout Service steht unter folgender URL zur Verfügung und benötigt einen http GET Parameter:

    http://<host>:<port>/moa-id-auth/LogOut
    @@ -882,11 +882,11 @@ Redirect Binding
     
     https://<host>:<port>/moa-id-auth/LogOut
       
    - +
    - - - + + + @@ -901,7 +901,7 @@ https://<host>:<port>/moa-id-auth/LogOut
    https://demo.egiz.gv.at/moa-id-auth/LogOut?redirect=https://demo.egiz.gv.at/demoportal-openID_demo
     

    Hinweis: Dieses Service bietet jedoch NICHT eine vollständige Single Log-Out Funktionalität wie sie im SAML 2 Protokoll vorgesehen ist, sondern beendet ausschließlich die SSO Session in der MOA-ID-Auth Instanz.

    -

    1.5.1 Single LogOut

    +

    1.5.1 Single LogOut

    Ab der Version 2.1 unterstützt das Modul MOA-ID-Auth Single LogOut (SLO) laut SAML2 Spezifikation. Die SLO Funktionaltität steht jedoch nur für Online-Applikationen zur Verfügung welche als Authentifizierungsprotokoll PVP 2.1 verwenden. Für alle anderen Authentifizierungsprotokolle steht aktuell kein SLO zur Verfügung.

    Für Single LogOut stehen sowohl IDP initialisiertes SLO als auch Service Provider initialisiertes SLO zur Verfügung. Als Einsprungpunkt für IDP initialisiertes SLO stellt das Modul MOA-ID-Auth folgende Web Adressen zur Verfügung. Nach dem Aufruf dieses Services wird der Single LogOut Vorgang gestartet. Nach erfolgreicher Bearbeitung aller SLO Requests / Response erfolgt die Statusausgabe in den Browser.

    https://<host>:<port>/moa-id-auth/idpSingleLogout
    @@ -912,14 +912,14 @@ https://<host>:<port>/moa-id-auth/LogOut

     

    Hinweis: Wenn Single Sign-On mit Authentifizierungsprotokollen, welche kein SLO untersützen verwendet wurde, schlägt der Single LogOut Vorgang auf jeden Fall fehl, da der Benutzer an den jeweiligen Online-Applikationen nicht angemeldet werden kann. Die SSO Session am Identityprovider wird jedoch auf jeden Fall beendet

     

    -

    1.6 Legacy Request (Bürgerkartenauswahl beim Service Provider)

    +

    1.6 Legacy Request (Bürgerkartenauswahl beim Service Provider)

    Soll die Bürgerkartenauswahl jedoch weiterhin, wie aus MOA-ID 1.5.1 bekannt direkt in der Online-Applikation des Service Providers erfolgen muss für das jeweilige Protokoll der Legacy Modus aktiviert werden. Wird der Legacy Modus verwendet muss jedoch zusätzlich zu den protokollspezifischen Parametern mindestens der Parameter bkuURI, welcher die gewählte Bürgerkartenumgebung enthält, im Authentifizierungsrequest an MOA-ID-Auth übergeben werden (siehe Protokoll SAML 1). Die folgenden Parameter stehen bei Verwendung des Legacy Modus unabhängig vom verwendeten Protokoll zur Verfügung und bilden den gesamten Umfang der Bürgerkartenauswahl, wie aus MOA-ID 1.5.1 bekannt, ab.

    -
    NameBeispielwertBeschreibungNameBeispielwertBeschreibung
    redirect
    +
    - - - + + + @@ -948,10 +948,10 @@ https://<host>:<port>/moa-id-auth/LogOut

     

    Hinweis: Bei einer vollständigen Neukonfiguration ist der Legacy Modus standardmäßig für alle Protokolle deaktiviert.

    Hinweis: Bei der Verwendung des Legacy Request für die Bürgerkartenauswahl ist jedoch zu beachten dass im Falle einer aktiven Single Sign-On Session, MOA-ID-Auth mit einer Abfrage zum SSO Anmeldevorgang antwortet.

    -

    2 PVP 2.1

    +

    2 PVP 2.1

    Die PVP 2.1 Implementierung des Modules MOA-ID-Auth bezieht sich auf das S-Profil der PVP 2 Spezifikation. Das S - Profil von PVP 2 verwendet SAML WebSSO für die Authentifizierung von Benutzern mit Webbrowser. Dadurch wird die direkte Kommunikation des Browsers mit der Anwendung ermöglicht, was in Anwendungsfällen notwendig ist, wo Anwendungen nicht kompatibel mit dem Reverse - Proxy - Verfahren sind, datenschutzrechtliche Probleme bestehen oder SAML WebSSO als Industriestandard unterstützt werden soll.

    Bevor PVP 2.1 als Authentifizierungsprotokoll verwendet werden kann muss das Modul MOA-ID-Auth entsprechend konfiguriert werden. Detailinformationen zur Konfiguration finden Sie hier.

    -

    2.1 Ablauf einer Anmeldung mittels PVP 2.1

    +

    2.1 Ablauf einer Anmeldung mittels PVP 2.1

    Die nachfolgende Abbildung zeigt das Sequenzdiagramm eines Anmeldevorgangs mittels PVP 2.1 und des Modules MOA-ID-Auth als Identity Provider. Aus Gründen der Übersichtlichkeit wurden die Teile welche die Kommunikation mit der Bürgerkartenumgebung oder die Vollmachten-Auswahl betreffen bewusst nicht berücksichtigt.

    Sequenzdiagramm PVP 2.1

      @@ -973,7 +973,7 @@ https://<host>:<port>/moa-id-auth/LogOut
    -

    2.2 Metadaten

    +

    2.2 Metadaten

    Das Modul MOA-ID-Auth stellt für Service-Provider (Online-Applikationen) Metadaten bereit welche alle PVP 2.1 spezifischen Informationen der MOA-ID-Auth Instanz beinhalten. Diese Metadaten werden durch das Modul MOA-ID-Auth signiert, wodurch Service Provider die Authentizität der Metadaten verifizieren können. Ein Beispiel für Metadaten von MOA-ID-Auth finden sie hier. Die aktuellen Metadaten zu Ihrer MOA-ID-Auth Instanz können unter folgender URL abgerufen werden.

    http://<host>:<port>/moa-id-auth/pvp2/metadata
     
    @@ -993,7 +993,7 @@ https://<host>:<port>/moa-id-auth/pvp2/metadata

    Zusätzlich unterstützt das Modul MOA-ID-Auth auch die Verschlüsselung PVP 2.1 Assertion mit einem vom Service-Provider definierten Zertifikat. Um diese Funktion zu nutzen muss in den Metadaten ein zweites XML Element md:EntitiesDescriptor/md:EntityDescriptormd:SPSSODescriptor/md:KeyDescriptor mit dem Attribut use="encryption" vorhanden sein (siehe Beispiel). In diesem Fall verwendet das Modul MOA-ID-Auth, dass in diesem Element hinterlegte Zertifikat zur Verschlüsselung der PVP 2.1 Assertion.

    Hinweis: Fehlt im XML Element md:EntitiesDescriptor/md:EntityDescriptormd:SPSSODescriptor/md:KeyDescriptor das Attribut use wird das in diesem Element hinterlegte Zertifikat sowohl zur Prüfung der Signatur des Authentifizierungsrequest als auch zur Verschlüsselung der PVP 2.1 Assertion verwendet.

    -

    2.3 Zugangspunkte

    +

    2.3 Zugangspunkte

    Für die Kommunikation zwischen Service Provider und dem Modul MOA-ID-Auth stellt MOA-ID-Auth aktuell zwei PVP 2.1 spezifische Zugangspunkte zur Verfügung. Detailinformationen zu den beiden Zugangspunkten (Bindings) entnehmen finden Sie in der SAML2 Spezifikation.

    • POST Binding: In diesem Fall erfolgt die Übertragung mittels http POST. Hierfür stellt MOA-ID-Auth den folgenden Zugangspunkt zur Verfügung.
    • @@ -1004,16 +1004,16 @@ https://<host>:<port>/moa-id-auth/pvp2/metadata
    https://<host>:<port>/moa-id-auth/pvp2/redirect

    Hinweis: Die Zugangspunkte können auch direkt aus den von MOA-ID-Auth generierten Metadaten entnommen werden.

    -

    2.3.1 Authentifizierungsrequest

    +

    2.3.1 Authentifizierungsrequest

    Der Authentifizierungsrequest wird vom Service Provider erstellt und an das Modul MOA-ID-Auth übermittelt. Zur Übertragung, muss je nach verwendetem Binding, einer der beiden Zugangspunkte und die entsprechende Kodierung der Parameter verwendet werden.

    Folgende Minimalanforderungen an den Authentifizierungsrequest müssen erfüllt sein.

    • Der Request muss durch den Service Provider signiert sein (siehe Beispiel). Die Signatur wird durch das Modul MOA-ID-Auth mit Hilfe des in den Metadaten hinterlegten Zertifikats validiert. Schlägt die Signaturprüfung fehl oder ist keine Signatur vorhanden wird der Request abgewiesen und MOA-ID-Auth antwortet mit http Code 400 und der Fehlermeldung NO valid protocol request received!.
    • -
    NameBeispielwertBeschreibungNameBeispielwertBeschreibung
    bkuURI=<bku-url>
    +
    - - + + @@ -1026,7 +1026,7 @@ https://<host>:<port>/moa-id-auth/pvp2/metadata
    Namesaml2p:AuthnRequest/saml2:IssuerNamesaml2p:AuthnRequest/saml2:Issuer
    Gebrauch
  1. - +
    @@ -1044,7 +1044,7 @@ https://<host>:<port>/moa-id-auth/pvp2/metadata

    Einen Beispielrequest finden Sie hier.

    Hinweis: Detailinformationen finden Sie im Abschnitt Spezifikationen in der PVP 2.1 Spezifikation und der SAML2 Spezifikation.

    -

    2.3.2 Authentifizierungsresponse

    +

    2.3.2 Authentifizierungsresponse

    Nach erfolgreicher Authentifizierung antwortet das Modul MOA-ID-Auth mit einer PVP 2.1 Assertion. Zur Übertragung der Assertion erfolgt an das in den Metadaten der Online-Applikation angegebene AssertionConsumerService (siehe Metadaten).

    Aktuell werden vom Modul MOA-ID-Auth zwei Bindings zur Übertragung der Assertion unterstützt.

      @@ -1145,13 +1145,13 @@ https://<host>:<port>/moa-id-auth/pvp2/metadata
    Name /saml2p:AuthnRequest/@ID

    Dieses Attribut beinhaltet einen von MOA-ID-Auth ausgestellten Gültigkeitszeitraum für diese Assertion. Aktuell beträgt der Gültigkeitszeitraum fünf Minuten ab dem Ausstellzeitpunkt.

    -

    3 OpenID Connect

    -

    OpenID Connect ist ein Authentifizierungsprotokoll welches auf dem OAuth 2.0 Protokoll aufbaut. Dieses Protokoll erlaubt Online-Applikationen die Identifizierung und Authentifizierung von Benutzern, mit Hilfe des Modules MOA-ID-Auth. Der Vorteil von OpenID Connect im Vergleich zu auf SAML basierten Protokollen (PVP 2.1, SAML 1) ist der einfachere Aufbau der einzelnen Protokollnachrichten. Zusätzlich existieren einige frei Verfügbare Bibliotheken für unterschiedliche Programmiersprachen, welche OpenID Connect implementieren.

    +

    3 OpenID Connect

    +

    OpenID Connect ist ein Authentifizierungsprotokoll welches auf dem OAuth 2.0 Protokoll aufbaut. Dieses Protokoll erlaubt Online-Applikationen die Identifizierung und Authentifizierung von Benutzern, mit Hilfe des Modules MOA-ID-Auth. Der Vorteil von OpenID Connect im Vergleich zu auf SAML basierten Protokollen (PVP 2.1, SAML 1) ist der einfachere Aufbau der einzelnen Protokollnachrichten. Zusätzlich existieren einige frei Verfügbare Bibliotheken für unterschiedliche Programmiersprachen, welche OpenID Connect implementieren.

    Bevor OpenID Connect in Kombination mit dem Modul MOA-ID-Auth verwendet werden kann muss das Modul MOA-ID-Auth konfiguriert werden. Detailinformationen zur Allgemeinen Konfiguration und zur online-applikationsspezifischen Konfiguration finden Sie im jeweiligen Abschnitt des Kapitels Konfiguration.

    -

    Die nachfolgende Beschreibung gibt einen kurzen Überblick zur Verwendung des Protokolls OpenID Connect in Kombination mit dem Modul MOA-ID-Auth. Detailinformationen zu OpenID Connect entnehmen Sie bitte der aktuellen OpenID Connect Spezifikation

    +

    Die nachfolgende Beschreibung gibt einen kurzen Ãœberblick zur Verwendung des Protokolls OpenID Connect in Kombination mit dem Modul MOA-ID-Auth. Detailinformationen zu OpenID Connect entnehmen Sie bitte der aktuellen OpenID Connect Spezifikation

    -

    3.1 Ablauf einer Anmeldung mittels OpenID Connect

    -

    Die nachfolgende Abbildung zeigt das Sequenzdiagramm eines Anmeldevorgangs mittels OpenID Connect und des Modules MOA-ID-Auth als Identity Provider. Aus Gründen der Übersichtlichkeit wurden die Teile welche die Kommunikation mit der Bürgerkartenumgebung oder die Vollmachten-Auswahl betreffen bewusst nicht berücksichtigt.

    +

    3.1 Ablauf einer Anmeldung mittels OpenID Connect

    +

    Die nachfolgende Abbildung zeigt das Sequenzdiagramm eines Anmeldevorgangs mittels OpenID Connect und des Modules MOA-ID-Auth als Identity Provider. Aus Gründen der Übersichtlichkeit wurden die Teile welche die Kommunikation mit der Bürgerkartenumgebung oder die Vollmachten-Auswahl betreffen bewusst nicht berücksichtigt.

    Sequenzdiagramm OpenID Connect

      @@ -1182,23 +1182,23 @@ https://<host>:<port>/moa-id-auth/pvp2/metadata
-

3.2 Zugangspunkte

-

Zur Verwendung von OpenID Connect stellt das Modul MOA-ID-Auth zwei Zugangspunkte zur Kommunikation mit der Online-Applikation zur Verfügung. Diese Zugangspunkte bezeichnen die URLs unter welchen das Modul MOA-ID-Auth die entsprechenden OpenID Connect Nachrichten entgegennimmt.

+

3.2 Zugangspunkte

+

Zur Verwendung von OpenID Connect stellt das Modul MOA-ID-Auth zwei Zugangspunkte zur Kommunikation mit der Online-Applikation zur Verfügung. Diese Zugangspunkte bezeichnen die URLs unter welchen das Modul MOA-ID-Auth die entsprechenden OpenID Connect Nachrichten entgegennimmt.

-

3.3 Beschreibung der Nachrichten

-

Dieser Abschnitt beschreibt die einzelnen OpenID Connect spezifischen Nachrichten, welche zwischen der Online-Applikation und dem Modul MOA-ID-Auth während eines Authentifizierungsvorgangs ausgetauscht werden. Hierbei wird auch auf das Sequenzdiagramm aus Abschnitt 3.1 Bezug genommen.

+

3.3 Beschreibung der Nachrichten

+

Dieser Abschnitt beschreibt die einzelnen OpenID Connect spezifischen Nachrichten, welche zwischen der Online-Applikation und dem Modul MOA-ID-Auth während eines Authentifizierungsvorgangs ausgetauscht werden. Hierbei wird auch auf das Sequenzdiagramm aus Abschnitt 3.1 Bezug genommen.

-

3.2.1 AuthCode Request

-

Der AuthCode Request ist die Authentifizierungsanfrage einer Online-Applikation für eine Benutzerin oder einen Benutzer. -Folgende Parameter müssen mit dem AuthCode-Request mitgesendet werden, wobei für die Übertragung der Parameter sowohl http GET als auch http POST verwendet werden kann.

- +

3.2.1 AuthCode Request

+

Der AuthCode Request ist die Authentifizierungsanfrage einer Online-Applikation für eine Benutzerin oder einen Benutzer. +Folgende Parameter müssen mit dem AuthCode-Request mitgesendet werden, wobei für die Übertragung der Parameter sowohl http GET als auch http POST verwendet werden kann.

+
- - - + + + @@ -1241,7 +1241,7 @@ Folgende Parameter m
NameBeispielwertBeschreibungNameBeispielwertBeschreibung
client_id

 

Nachfolgend ein Beispiel für einen OpenID Connect Authentifizierungsrequest an das Modul MOA-ID-Auth.

-
<form method="get" action="https://demo.egiz.gv.at/demoportal_moaid-2.0/oauth2/auth">
+
<form method="get" action="https://demo.egiz.gv.at/demoportal_moaid-2.0/oauth3/auth">
   <input type="hidden" value="code" name="response_type">
   <input type="hidden" value="https://demo.egiz.gv.at/demoportal-openID_demo" name="client_id">
   <input type="hidden" value="https://demo.egiz.gv.at/demoportal-openID_demo/securearea.action" name="redirect_uri">
@@ -1249,13 +1249,13 @@ Folgende Parameter m
   <input type="hidden" value="1152547590" name="state">
   <input type="submit" value="OpenID Connect login">
 </form>
-

3.2.2 AuthCode Response

+

3.2.2 AuthCode Response

Das Ergebnis des AuthCode Requests wird an die redirect_uri der Online-Applikation gesendet. Die nachfolgenden Parameter werden dabei übergeben.

- +
- - - + + + @@ -1271,13 +1271,13 @@ Folgende Parameter m

 

Nachfolgend ein Beispiel für eine AuthCode Response.

https://demo.egiz.gv.at/demoportal-openID_demo/securearea.action?state=1425782214234&code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7 
-

3.2.3 AccessToken Request

+

3.2.3 AccessToken Request

Mit dem AccessToken Request können vom Service Provider der Online-Applikation die Anmeldedaten an der MOA-ID-Auth Instanz abgeholt werden. Für die Abholung müssen folgende Parameter mit dem AccessToken Request an MOA-ID-Auth übertragen werden, wobei für die Übertragung der Parameter sowohl http GET als auch http POST verwendet werden kann.

-
NameBeispielwertBeschreibungNameBeispielwertBeschreibung
state
+
- - - + + + @@ -1307,7 +1307,7 @@ Folgende Parameter m
NameBeispielwertBeschreibungNameBeispielwertBeschreibung
grant_type

 

Nachfolgend ein Beispiel für einen AccessToken Request

-
<form method="POST" action="https://demo.egiz.gv.at/demoportal_moaid-2.0/oauth2/token">
+
<form method="POST" action="https://demo.egiz.gv.at/demoportal_moaid-2.0/oauth3/token">
   <input type="hidden" value="authorization_code" name="grant_type">
   <input type="hidden" value="https://demo.egiz.gv.at/demoportal-openID_demo" name="client_id">
   <input type="hidden" value="https://demo.egiz.gv.at/demoportal-openID_demo/securearea.action" name="redirect_uri">
@@ -1315,16 +1315,16 @@ Folgende Parameter m
   <input type="hidden" value="4/P7q7W91a-oMsCeLvIaQm6bTrgtp7" name="code">
 </form>
-

3.2.4 AccessToken Response

+

3.2.4 AccessToken Response

Die AccessToken Response beinhaltet ein signiertes JSON-Token welches alle angeforderten (Parameter scope im AuthCode Request) und vorhandenen Authentifizierungsdaten beinhaltet. Dieses JSON-Token ist mit einer JSON Web Signatur von MOA-ID-Auth signiert, wobei die Signatur alle angeforderten Daten einschließt. Details zur Konfiguration des Signatur Zertifikats finden Sie hier.

- +
- - - + + + @@ -1365,20 +1365,20 @@ Folgende Parameter m NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q - Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ + Jp6IcmD3HP99Obi1PRs-cwh4LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4 XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg" } -

3.2.5 Error Response

+

3.2.5 Error Response

Sollte während des Authentifizierungsvorgangs ein Fehler auftreten antwortet das Modul MOA-ID-Auth mit einer Error Response. Diese beinhaltet folgende Parameter

-
NameBeispielwertBeschreibungNameBeispielwertBeschreibung
access_token
+
- - - + + + @@ -1397,10 +1397,10 @@ Folgende Parameter m
NameBeispielwertBeschreibungNameBeispielwertBeschreibung
error

 

-

3 SAML 1

+

3 SAML 1

SAML 1 wird durch MOA-ID-Auth 2.0 auch weiterhin, aus Gründen der Abwärtskompatibilität, als Authentifizierungsprotokoll unterstützt. Es wird jedoch der Umstieg auf ein aktuelles Authentifizierungsprotokoll wie PVP 2.1 oder OpenID Connect empfohlen.

Die nachfolgenden Abschnitte beschreiben den Anmeldevorgang unter Verwendung von SAML1 wobei die Funktionalität, wie sie aus MOA-ID <= 1.5.1 bekannt ist, auch weiterhin unterstützt wird (Bürgerkartenauswahl auf Seiten des Service Provider). Zusätzlich steht für SAML 1 jedoch auch die Funktionalität der automatischen Generierung der Bürgerkartenauswahl durch das Modul MOA-ID-Auth zur Verfügung.

-

3.1 Ablauf einer Anmeldung mittels SAML 1

+

3.1 Ablauf einer Anmeldung mittels SAML 1

Die nachfolgende Abbildung zeigt das Sequenzdiagramm eines Anmeldevorgangs mittels SAML 1 und des Modules MOA-ID-Auth als Identity Provider. Hierbei wird die aus MOA-ID 1.5.1 bekannte Variante der Bürgerkartenauswahl beim Service Provider verwenden. Aus Gründen der Übersichtlichkeit wurden die Teile welche die Kommunikation mit der Bürgerkartenumgebung oder die Vollmachten-Auswahl betreffen bewusst nicht berücksichtigt.

Sequenzdiagramm für SAML 1

    @@ -1419,7 +1419,7 @@ Folgende Parameter m
  1. MOA-ID-Auth validiert das Artifact. Ist die Validierung erfolgreich antwortet MOA-ID-Auth mit der SAML 1 Assertion, welche die Anmeldedaten beinhaltet.
  2. Der Service Provider verarbeitet die Assertion und danach ist der Benutzer an der Online-Applikation angemeldet.
-

3.2 Zugangspunkte

+

3.2 Zugangspunkte

Zur Verwendung von SAML 1 stellt das Modul MOA-ID-Auth zwei Zugangspunkte zur Kommunikation mit der Online-Applikation (Service Provider) zur Verfügung. Diese Zugangspunkte bezeichnen die URLs unter welchen das Modul MOA-ID-Auth die entsprechenden SAML1 Nachrichten entgegennimmt.

  • StartAuthentication Request: https://<host>:<port>/moa-id-auth/StartAuthentication
    @@ -1427,7 +1427,7 @@ Folgende Parameter m
  • GetAuthenticationData: http(s)://<host>:<port>/moa-id-auth/services/GetAuthenticationData
    Unter dieser URL können nach erfolgreicher Authentifizierung die eigentlichen Authentifizierungsdaten am Modul MOA-ID-Auth abgeholt werden.
-

3.3 StartAuthentication Request

+

3.3 StartAuthentication Request

MOA-ID-Auth wird immer durch eine andere (verweisende) Webseite aufgerufen. Diese Webseite kann z.B. Teil eines Portals sein. Der Aufruf erfolgt durch einen Verweis der Form, wobei die Parameter sowohl als http GET als auch als http POST an MOA-ID-Auth übergeben werden können.

<a href="https://<moa-id-server-und-pfad>/StartAuthentication
   ?Target=<geschäftsbereich>  
@@ -1436,11 +1436,11 @@ Folgende Parameter m
   &Template=<template-url>
 	&useMandate=false
   &CCC=<ccc>">
- +
- - - + + + @@ -1486,12 +1486,12 @@ Folgende Parameter m
NameBeispielwertBeschreibungNameBeispielwertBeschreibung
<moa-id-server-und-pfad>Optional: Die sourceID fließt in die Generierung des SAML1 Artifacts, welches an den Service Provider returniert wird, ein. Detailinformationen zur Generierung des SAML1 Artifacts und zur sourceID finden Sie in der SAML1 Spezifikation.
-

3.4 GetAuthenticationData Request

+

3.4 GetAuthenticationData Request

Nach erfolgter Authentisierung stehen in MOA-ID-AUTH Anmeldedaten zum Abholen bereit, und MOA-ID-AUTH veranlasst einen Redirect zur Online-Applikation (OA).

In diesem Redirect werden der Geschäftsbereich und ein SAML-Artifact als Parameter übergeben.

<a href="https://<oa-url>?Target=<geschäftsbereich>&SAMLArtifact=<saml-artifact>">
- +
@@ -1519,8 +1519,8 @@ Sollte während des Anmeldevorgangs ein Fehler aufgetreten sein, antwortet d
  • SAML 1.0 Assertion Schema
  • Der detaillierte Aufbau der <saml:Assertion> zu den Anmeldedaten ist in der Spezifikation MOA-ID 1.4 beschrieben.

    -

    A Referenzierte Spezifikation

    -
    oa-url>
    +

    A Referenzierte Spezifikation

    +
    @@ -1560,5 +1560,6 @@ Sollte während des Anmeldevorgangs ein Fehler aufgetreten sein, antwortet d
    Spezifikation
    + -- cgit v1.2.3