SAML2

Prozessfluss für SAML2 Anmeldungen in Web Browser Anwendungen

Dieser Prozessfluss beschreibt eine SAML2 Authentifizierung eines Benutzers in einem Web Browser. Abbildung 1 bietet eine Darstellung des Prozessflusses.

Abbildung 1: Prozessfluss einer SAML2 Authentifizierung im Web-Browser
  1. Der Benutzer will mit einem Web-Browser auf eine geschützte Ressource in der Online-Applikation eines Service Providers (SP) zugreifen.
  2. Der Service Provider erkennt, dass es sich um einen nicht-authentifizierten Benutzer handelt und antwortet dem Browser mit einem SAML2 Authentifizierungs-Redirect zum Identity Provider (IdP) des E-ID Systems.
  3. Der Browser löst den Authentifizierungs-Redirect auf und sendet einen Authentifizierungsrequest an den IdP, wonach dieser mit einer HTML Seite zur Auswahl einer möglichen Authentifizierung per VDA (Handy-Signatur), oder optional eine Anmeldung per EU-Login (eIDAS), antwortet. Der Benutzer entscheidet sich an dieser Stelle für eine der Authentifizierungsvarianten.
  4. Nach Auswahl des Authentifizierungsvorgangs schickt der IdP ein Security-Layer 2.0 Kommando an den VDA, um den Signaturvorgang zu starten.
    Securiy Layer Kommando:
    
  5. Im Zuge der Authentifizierung wird die Telefonnummer und das Signaturpasswort des Benutzers abgefragt.
  6. Danach kann die Authentifizierung mit 2 Varianten fortgesetzt werden:
    • Authentifizierung über initialisierte E-ID App: Der VDA sendet eine Push-Notification an die E-ID App des Benutzers, um einen Fingerprint durchzuführen.
    • Authentifizierung ohne E-ID App: Der VDA sendet einen SMS-TAN an das Mobiltelefon des Benutzers, der anschließend in der Eingabemaske im Web-Browser eingegeben werden muss. Alternativ kann ein QR Code mit der E-ID gescannt werden, um einen App-TAN zu übermitteln.
  7. Nach einer erfolgreichen Authentifizierung wird die qualifizierte Signatur erstellt und an den IdP zurückgeliefert, welcher die weitere Kommunikation mit dem E-ID Backend übernimmt, um die Personenbindung anzufordern.
  8. Der IdP antwortet der Applikation des SP mit einer SAML2 Authentifizierungsresponse, die die SAML2-Assertion beinhaltet.
  9. Abschließend übermittelt der Browser die SAML2 Assertion an die Applikationn des SP, wonach der Benutzer angemeldet ist.

OIDC

Die Prozessflüsse einer Anmeldung mit OIDC unterscheidet sich abhängig vom gewählten Response Type des SP und dem damit verbundenen Authentication Flow. Grundsätzlich werden folgende Authentication Flows vom E-ID System unterstützt:

Die beiden Authentication Flows werden nachfolgend im Detail beschrieben.

Basic Authentication Flow in OIDC

Wird der Response Type "code" gewählt, erfolgt die Authentifizierung entsprechend dem Basic Authentication Flow. Der Basic Authentication Flow eignet sich für herkömmliche Web-Anwendungen- sowie native (mobile oder Desktop-) Anwendungen mit Backend. Abbildung 2 bietet eine Darstellung des Prozessflusses des Basic Authentication Flows.

Abbildung 2: Prozessfluss eines Basic Authentication Flows in OIDC
  1. Der Benutzer möchte mit seinem User Agent (PC/Laptop oder Smartphone/Tablet) eine Applikation eines SP nutzen, der mit einem Authentifizierungs-Redirect antwortet. Der User-Agent des Benutzers folgt dem Authentifizierungs-Redirect und sendet einen OIDC Authentifizierungsrequest an den IdP.
  2. Der IdP führt die Authentifizierung mit dem Benutzer durch.
  3. Nach einer erfolgreichen Authentifizierung antwortet der IdP mit einem Berechtigungscode, der über den User-Agent an die Redirect URI der SP Applikation geschickt wird.
  4. Die SP Anwendung sendet den Berechtigungscode zusammen mit einem Client Secret, falls notwendig, in einem Token-Request an den Token Service des IdP.
  5. Der IdP validiert den Token-Request und antwortet mit einem ID-Token, der die Identitätsmerkmale des Benutzers beinhaltet.

Implicit Flow in OIDC

Wird der Response Type "id_token" gewählt, erfolgt die Authentifizierung entsprechend dem Implicit Flow. Der Implicit Flow eignet sich für für browserbasierte (JavaScript) Anwendungen- oder native Apps ohne Backend. Abbildung 3 bietet eine Darstellung des Prozessflusses des Implicit Flows.

Abbildung 3: Prozessfluss eines Implicit Flows in OIDC
  1. Der Benutzer möchte mit seinem User Agent (PC/Laptop oder Smartphone/Tablet) eine Applikation eines SP nutzen, der mit einem Authentifizierungs-Redirect antwortet. Der User-Agent des Benutzers folgt dem Authentifizierungs-Redirect und sendet einen OIDC Authentifizierungsrequest an den IdP.
  2. Der IdP führt die Authentifizierung mit dem Benutzer durch.
  3. Nach einer erfolgreichen Authentifizierung antwortet der IdP mit einem ID-Token, der die Identitätsmerkmale des Benutzers beinhaltet.

App2App Anmeldungen

Abhängig von den, im Anmeldeprozess involvierten, Client Komponenten, ergeben sich unterschiedliche Prozessflüsse.
Der Benutzer kann eine OIDC Anmeldung in einer SP App, entweder mit-, oder ohne einer initialisierten E-ID App am Client Gerät (Smartphone/Tablet) durchführen. Für beide Varianten wird der Prozessfluss nachfolgend im Detail beschrieben.

Prozessfluss für Anmeldungen in SP Apps ohne E-ID App

Dieser Prozessfluss beschreibt die Authentifizierung eines Benutzers ohne E-ID App mit Basic Authentication Flow. Eine Darstellung der einzelnen Prozessschritte ist in Abbildung 4 gegeben.

Abbildung 4: Prozessfluss einer OIDC Authentifizierung ohne E-ID App
  1. Die SP App will auf eine geschützte Ressource an der Online Applikation des SP zugreifen.
    Adresse einer Anwendung eines Beispiel-Anwendungsfalls:

    https://aeg.a-sit.at/notes/
    
  2. Die Applikation des SP erkennt, dass es sich um einen nicht-authentifizierten Benutzer handelt und antwortet mit einem Authentication-Redirect, der den Benutzer zum IdP zur Authentifizierung weiterleitet.
    Beispiel für einen OIDC Authentication-Redirect:

    https://eid.egiz.gv.at/idp/profile/oidc/authorize?response_type=code&client_id=https%3A%2F%2Faeg.a-sit.at%2Fnotes&scope=openid&state=5c7d29a1-48f2-416e-b25a-93a9b515c562&redirect_uri=at.asitplus.notes.app%3A%2Foauth2redirect
    

    Der Authentication-Redirect enthält, für die Authentifizierung benötigte, Parameter:

    • response_type: Der Response Typ kann mit "code" (Basic Authentication Flow) oder "id_token" (Implicit Flow) angegeben werden.
    • client_id: Die ID der SP Applikation, die am IdP des E-ID Systems registriert ist.
    • redirect_uri: Die Redirect URI gibt die Client-Callback URI, zum Erhalt der Authentication Response des IdP, an. Wird dies nicht angegeben, übernimmt der IdP die standardmäßig registrierte Redirect URI, die für die SP Applikation registriert ist.
    • state: Optionaler Wert, der vom Client festgelegt wird, um den State zwischen Request und Callback beizubehalten.
    • Die Service App empfängt den Redirect und öffnet ihn per View Intent. An diesem Punkt hängt der weitere Prozessfluss davon ab, ob die entsprechende E-ID App auf dem Smartphone installiert ist oder nicht.

  3. Die SP App öffnet die URL im mobilen Browser.
  4. Der mobile Browser löst den Authentication Redirect auf und sendet den Authentifizierungsrequest an den IdP. Der IdP übernimmt die Kommunikation mit dem Backend des E-ID Systems und antwortet mit einer HTML Seite zur Auswahl zur möglichen Authentifizierung, die eine Authentifizierung per Handy-Signatur, oder optional eine alternative Anmeldung per EU-Login ermöglicht.
  5. Nach der Auswahl des Authentifizierungsvorgangs wird die Authentifizierung am VDA gestartet. Im Zuge einer Authentifizierung per Handy-Signatur wird die Telefonnummer, das Signaturpasswort, wonach ein TAN (SMS- oder App-TAN) abgefragt wird.
  6. Die SP App sendet den TAN an den VDA um die Authentifizierung abzuschließen.
  7. Nach einer erfolgreichen Authentifizierung retourniert der IdP die Authentifizierungs-Response, die einen Authorization Code (Berechtigungscode) beinhaltet, via Redirect über den User Agent an die Redirect URI des SP.

    Beispiel für eine Authentifizierungs-Response vom IdP:

    at.asitplus.notes.app:/oauth2redirect?code=AAdzZWNyZXQxWrRnkI...&state=5c7d29a1-48f2-416e-b25a-93a9b515c562
    

    Die E-ID App löst den Redirect des IdP auf und sendet die Parameter zur SP App.

  8. Der E-ID Client in der SP App des Benutzers validiert im Anschluss den, im Intent enthaltenen, State.
  9. Abschließend löst die SP App den Redirect weiter auf und sendet den OIDC Berechtigungscode an die Applikation des SP, wonach der Benutzer am Service angemeldet ist.

Prozessfluss für Anmeldungen in Sp Apps mit E-ID App

Dieser Prozessfluss beschreibt die Authentifizierung eines Benutzers ohne E-ID App mit Basic Authentication Flow. Eine Darstellung der einzelnen Prozessschritte ist in Abbildung 5 gegeben.

Abbildung 5: Prozessfluss einer OpenID Connect Authentifizierung
  1. Die SP App will auf eine geschützte Ressource an der Online Applikation des SP zugreifen.
  2. Die Applikation des SP erkennt, dass es sich um einen nicht-authentifizierten Benutzer handelt und antwortet mit einem Authentication-Redirect, der den Benutzer zum IdP zur Authentifizierung weiterleitet.
  3. Die SP App löst den Redirect auf und sendet den Authentifizierungsrequest an die E-ID App, die Requests für ein bestimmtes URL Scheme empfängt.
  4. Die E-ID App löst den Authentication Redirect weiter auf und sendet den Authentifizierungsrequest an den Shibboleth IdP.
  5. Der IdP übernimmt die Kommunikation mit dem Backend des E-ID Systems und antwortet mit einer Auswahl zur möglichen Authentifizierung, die eine Authentifizierung per Handy-Signatur, oder optional eine alternative Anmeldung per EU-Login ermöglicht.
  6. Nach der Auswahl des Authentifizierungsvorgangs wird die Authentifizierung am VDA gestartet. Im Zuge der Authentifizierung wird das Signaturpasswort und der Fingerprint des Benutzers gefordert.
  7. Nach einer erfolgreichen Authentifizierung retourniert der IdP einen Authorization Code (Berechtigungscode) über den User Agent des Benutzers via einem Redirect an die Redirect-URI des SP. Die E-ID App löst den Redirect des IdP auf und sendet die Response zur SP App.
  8. Der E-ID Client in der SP App des Benutzers validiert im Anschluss den, in der Response enthaltenen, State. Abschließend löst die SP App den Redirect weiter auf und sendet den OIDC Berechtigungscode zum Anfordern des OIDC Token an die Applikation des SP und ist danach angemeldet.