Prozesse

Dieses Kapitel bietet eine detaillierte Beschreibung der Prozessflüsse, welche bei einer Anmeldung mittels ID Austria an einem Service Provider (SP) durchgeführt werden. Die Anmeldung kann entweder in einer mobilen App oder in einer web-basierten App des Service Providers durchgeführt werden. Für die technische Kommunikation zwischen Service Provider und ID Austria System stehen die Authentifizierungsprotokolle SAML2 und OIDC zur Verfügung.

Anmeldung mit SAML2

Prozessfluss für SAML2 in Webbrowseranwendungen

Dieser Prozessfluss beschreibt eine SAML2 Authentifizierung eines Users, wobei die Interaktion über den Webbrowser erfolgt. Abbildung 1 bietet eine Darstellung des Prozessflusses aus Sicht eines Users im Webbrowser.

1. Ein User möchte mittels Webbrowser auf eine geschützte Ressource in der Online-Applikation eines Service Providers zugreifen.
2. Der Service Provider erkennt, dass es sich um einen nicht-authentifizierten User handelt und antwortet dem Browser mit einem SAML2 Authentifizierungsrequest und einer Weiterleitung zum Identity Provider (IdP) des ID Austria Systems.
3. Der Browser sendet einen Authentifizierungsrequest an den IdP, worauf dieser mit einer HTML Seite zur Auswahl der zur Verfügung stehenden Authentifizierungsmethoden (ID Austria oder EU-Login) antwortet. Der User entscheidet sich an dieser Stelle für eine der Authentifizierungsvarianten. Die nachfolgenden Prozessschritte basieren auf der Annahme, dass der User ID Austria gewählt hat.
4. Nach Auswahl der Authentifizierungsmethode schickt der IdP ein Security-Layer 2.0 Kommando an den VDA, um einen ID Austria spezifischen Identifikations- und Authentifizierungsprozess am VDA zu starten.
5. Im Zuge des Identifikations- und Authentifizierungprozesses werden Benutzername und Signaturpasswort des Users abgefragt. Die Abfrage des Benutzernamens entfällt, falls der User Identifikation und Authentifizierung vollständig in der mobilen App durchführen kann, z. B. bei Services auf mobilen Geräten.
6. Danach kann die Authentifizierung mit zwei Varianten fortgesetzt werden:
   • Authentifizierung über initialisierte App „ID Austria“: Der VDA sendet eine Push-Notification an die App „ID Austria“ des Users, wodurch diese am mobilen Gerät geöffnet wird. Anschließend kann die „ID Austria“ zur Eingabe des zweiten Faktors für die Authentifizierung verwendet werden. Hierfür stehen aktuell Fingerprint und Gesichtserkennung zur Verfügung.
   • Authentifizierung in initialisierter App „ID Austria“: Der User befindet sich bereits in der App „ID Austria“ und wird direkt zur Eingabe des zweiten Faktors aufgefordert.
7. Nach einer erfolgreichen Authentifizierung wird eine qualifizierte Signatur, welche die Authentifizierung des Users für das ID Austria System darstellt, erzeugt. Die qualifizierte Signatur und weitere Basisdaten zum User werden anschließend an den IdP zurückgeliefert, welcher die weitere Kommunikation mit dem ID Austria Backend übernimmt, um die Personenbindung anzufordern.
8. Der IdP antwortet dem Browser mit einer SAML2 Authentifizierungsresponse, welche die SAML2-Assertion und somit die Identifikationsdaten des Users beinhaltet, und der Aufforderung zur Weiterleitung an den Service Provider.
9. Der Browser übermittelt die SAML2 Authentifizierungsresponse an den Service Provider. Nach erfolgreicher Validierung der SAML2 Authentifizierungsresponse durch den Service Provider ist der User angemeldet.

Anmeldung mit OpenID Connect

Die Prozessflüsse einer Anmeldung mit OpenID Connect (OIDC) unterscheiden sich abhängig vom gewählten Response-Type und dem damit verbundenen Authentication Flow. Vom ID Austria System wird jedoch nur der Response-Type code und somit der Authorization Code Flow entsprechend der OIDC Spezifikation unterstützt. Die nachfolgenden Kapitel geben einen allgemeinen Überblick zum Authorization Code Flow im ID Austria System und skizzieren mögliche Szenarien für den Einsatz von OpenID Connect zur Authentifizierung in Apps auf mobilen Geräten.

Authorization Code Flow in OIDC

Der Authorization Code Flow eignet sich für Web-Browser basierte Anwendungen sowie für native (mobile oder Desktop-) Anwendungen, welche über eine Anbindung an ein Backend System des Service Providers verfügen. Abbildung 2 bietet eine Darstellung des Prozessflusses des Authorization Code Flow.

1. Der User möchte mittels eines von ihm verwendeten Geräts auf eine geschützte Ressource in der Applikation eines Service Providers zugreifen. Der Service Provider erkennt, dass es sich um einen nicht-authentifizierten User handelt und antwortet mit einem OIDC Authentifizierungsrequest und einer Weiterleitung zum IdP des ID Austria Systems. Das nachfolgende Beispiel zeigt einen OIDC Authentifizierungsrequest für die Applikation: https://eid.a-sit.at/notes

• response_type: Der Response Typ muss mit code angegeben werden, da vom ID Austria System nur der Authorization Code Flow unterstützt wird.
• client_id: Der eindeutige Identifikator der SP Applikation, die am ID Austria System registriert sein muss. Das ID Austria System fordert als client_id eine URL, welche im Kontext der Anwendung liegen muss.
• scope: Definiert in OIDC das Set von Identitätsinformationen welche vom IdP angefordert werden. Im ID Austria System erfolgt die Anforderung von Attributen über das Applikationsregister der ID Austria und somit wird in diesem Zusammenhang empfohlen, die Scopes openid und profile anzufragen.
• redirect_uri: Die Redirect URI definiert die Client-Callback URI an welche das ID Austria System die Authentication Response an den Service Provider ausliefern soll.
• state: Optionaler jedoch empfohlener Parameter als CSFR / XSRF Schutz um den State zwischen Request und Callback beizubehalten.

2. Der IdP führt die Authentifizierung mit dem User durch. Die einzelnen Schritte für die Identifikation und Authentifizierung des Users unterscheiden sich nicht von den unter Punkt "Anmeldung mit SAML2" beschriebenen Schritten 3 bis 7.

3. Nach einer erfolgreichen Authentifizierung antwortet der IdP mit einem Berechtigungscode als Authentifizierungsresponse, der über das Gerät des Users an die SP Applikation weitergeleitet wird. Technisch erfolgt diese Weiterleitung an die Redirect URI entsprechend der OIDC Spezifikation.

4. Die SP Anwendung sendet den Berechtigungscode zusammen mit einer Client-Id und einem Client Secret in einem Token-Request an den Token Service des IdP um das eigentliche signierte idToken und somit die Identifikationsdaten des Users aus dem ID Austria System zu erhalten. Eine Authentifizierung des Clients gegenüber dem IdP ist im ID Austria System verpflichtet und somit muss ein Client Secret verwendet werden.

5. Der IdP validiert den Token-Request und antwortet mit einer Token-Response und dem vom ID Austria signierten idToken. Nach erfolgreicher Validierung der Token-Response durch den SP ist der User angemeldet.

ID Austria Integration mittels OIDC auf mobilen Geräten

Die Verwendung der ID Austria auf mobilen Endgeräten unterscheidet sich aus Sicht des OpenID Connect Authentifizierungsprotokolls nur geringfügig von dem bereits zuvor beschriebenen Authorization Code Flow für OIDC. Der Unterschied im Authentifizierungsprotokoll ergibt sich aus der Empfehlung zur Unterstützung des RFC8252 – OAuth 2.0 for Native Apps und der damit einhergehenden Integration von RFC7636 – Proof Key for Code Exchange by OAuth Public Clients zur besseren Absicherung der Kommunikation zwischen mobiler App und dem ID Austria System.

Da das ID Austria System jedoch auch über eine mobile Komponente (App „ID Austria“) verfügt, welche am mobilen Gerät installiert und aktiviert sein kann, ergeben sich aus Sicht des Users und der am Anmeldeprozess involvierten Komponenten Unterschiede, je nachdem welche Apps am mobilen Gerät nun tatsächlich zur Verfügung stehen.

Anmeldeprozess mit App „ID Austria“

Dieser Prozessfluss beschreibt die Authentifizierung eines Users mit installierter und aktivierter App „ID Austria“ unter Verwendung des beschriebenen OIDC Authorization Code Flow. Eine Darstellung der einzelnen Prozessschritte ist in Abbildung 3 gegeben.

1. Die Service Provider App möchte auf eine geschützte Ressource in einer Serverkomponente (Applikation) des Service Providers (SP) zugreifen. Ein praktisches Beispiel ist der Zugriff auf ein REST Service des SPs, welches Daten für die SP App und somit dem User bereitstellt.

2. Die Serverkomponente des SP erkennt, dass es sich um einen nicht-authentifizierten User handelt und antwortet mit einem Authentifizierungsrequest welcher den User zum IdP des ID Austria System weiterleitet.

3. Die SP App öffnet die URL mit dem Authentifizierungsrequest an den IdP. Da im aktuell beschriebenen Szenario eine App „ID Austria“ verfügbar ist, welche entsprechend RFC8252 Kapitel 7.2 auf die https URL des ID Austria Systems registriert ist, wird die URL in der App „ID Austria“ geöffnet.

4. Die App „ID Austria“ erkennt den Authentifizierungsrequest und startet einen Authentifizierungsvorgang für den User in der App "ID Austria". Hierfür wird der Authentifizierungsrequest an den Shibboleth IdP des ID Austria Systems weitergeleitet. Der IdP antwortet mit einer Auswahl an möglichen Anmeldeoptionen, wie in Abbildung 4 dargestellt. Hier wählt der User „Anmelden mit ID Austria“ aus.

5. Der IdP leitet den User zur Authentifizierung an den VDA weiter.

6. Der VDA führt die Authentifizierung mit dem User durch, wobei diese vollständig in der App „ID Austria“ durchgeführt wird. Die einzelnen Schritte für die Identifikation und Authentifizierung des Users sind ähnlich zu den unter Punkt "Anmeldung mit SAML2" beschriebenen Schritten 3 bis 7. Es ist jedoch keine Push Notification an die App „ID Austria“ notwendig, da sich der User bereits in der App „ID Austria“ befindet, was sich aus Sicht des Users in einem durchgehenden Prozess in der App „ID Austria“ widerspiegelt.

7. Nach einer erfolgreichen Authentifizierung retourniert der IdP einen Authorization Code (Berechtigungscode) über den User Agent via einem Redirect an die Redirect-URI des SPs. Die App „ID Austria“ löst den Redirect des IdP auf und sendet die Response zur SP App.

Um die Authentifizierungsresponse in der mobilen App des SPs zu empfangen, spezifiziert RFC8252 – Receiving the Authorization Response in a Native App mehrere Möglichkeiten, um die SP App auf eine RedirectURL zu registrieren. Diese werden durch das ID Austria System unterstützt, wobei die Verwendung https basierter Redirects empfohlen wird, da diese aus aktueller Sicht auf unterschiedlichen mobilen Plattformen unterstützt werden.

8. Nach Empfang der Authentifizierungsrespose in der mobilen App des SPs, kann diese den OIDC Berechtigungscode und optionale weitere Parameter an die Serverkomponente des SPs weiterleiten. Die Serverkomponente kann den Berechtigungscode entsprechend dem Authorization Code Flow gegen das OIDC IdToken mit den Informationen des Users tauschen und den User am Service anmelden. Eine Authentifizierung der Serverkomponente des SPs gegenüber dem IdP ist im ID Austria System verpflichtet und somit muss an dieser Stelle ein Client Secret verwendet werden.