Überblick

Als sektoraler IDP wird ein Dienst zur Authentisierung von Nutzern bezeichnet. Nach erfolgreichen Durchlaufen des Authentisierungsprozesses stellt der sektorale IDP Identitätsinformationen für eine bestimmte Gruppe von Nutzern, welche einem Sektor innerhalb der Telematikinfrastruktur des Gesundheitswesens zuzuordnen sind, bereit. Die Identitätsinformationen zu Nutzern werden durch den anfordernden Fachdienst zur Zugriffsautorisierung auf Fachdaten und -prozesse durch den Nutzer verwendet. 

Das Konzept der sektoralen IDP sieht vor, dass diese nicht ausschließlich von Fachdiensten der TI zur Authentifizierung von Anwendern zu verwenden sind. Vielmehr können (und sollen) auch Anwendungen außerhalb der TI (z. B. Anwendungen der Krankenkassen für ihr Versicherten) den sektoralen IDP zur Nutzerauthentifizierung und Attributübertragung verwenden. 

Für Anwendungen, die nicht übergreifend durch mehrere IDPs unterstützt werden sollen, ist es ausreichend diese direkt bei den jeweiligen IDPs zu registrieren. Die Föderation bietet hier keinen Mehrwert da beide Kommunikationspartner sich ohnehin kennen und vertrauen. Die in den Spezifikationen der gematik festgelegten Anforderungen sind für diese Anwendungen und den Anmeldungsflow am sektoralen IDP nicht bindend. Die (z. B. kasseneigenen) Anwendungen können mit ihren Kassen-IDP weitere scopes und claims vereinbaren. Eine Registrierung am Federation Master für diese Anwendungen nicht notwendig, da sie nicht Teil der Föderation sind. Die Fachdienste müssen sich lediglich OIDC konform am sektoralen IDP (also dem OpenID Provider) registrieren. Der sektorale Identity Provider kann für diese Anwendungen auch zugleich als Authorization-Server agieren und Access-Token ausstellen.

Die untere Abbildung beschreibt den Systemkontext aus Sicht des sektoralen IDP. Das Anwendungsfrontend des Fachdienstes stellt die Anfrage zur Authentifizierung des Nutzers an den Authorization-Server des Fachdienstes. Dieser generiert eine Code-Challenge und stellt einen Pushed Authorization Request (PAR) an den entsprechenden sektoralen IDP. Der Fachdienst agiert diesem gegenüber als Client. Über das Authenticator-Modul des sektoralen IDP findet dann die Authentifizierung des Nutzers statt. Anschließend erhält der Authorization-Server des Fachdienstes einen  Authorization-Code, welchen er bei Token-Endpunkt des sektoralen IDP gegen einen ID-Token eintauscht. Der Authorization-Server des Fachdienstes erstellt nun ein Access-Token für das Anwendungsfrontend, mit welchem dieses auf die, für den Nutzer freigegebenen, Ressourcen des Fachdienstes zugreifen kann. Die Kommunikation zwischen Anwendungsfrontend und Authorization-Server des Fachdienstes kann ebenfalls über einen eigenen Authorization-Code abgesichert werden.

Der Fachdienst und der sektoralen IDP müssen sich zuvor beim Federation Master in Form eines organisatorischen Prozesses registriert haben.

Der Produkttyp des sektoralen IDP besteht aus zwei Komponenten - der zentralen Komponente IDP (OP), dem eigentlichen OpenID-Provider und einer Frontend-Komponente u. a. für die Interaktion mit dem Nutzer, dem Authenticator-Modul. Das Authenticator-Modul unterstützt die Durchführung des Authentifizierungsprozesses und übernimmt die Ausführung der Nutzerauthentisierung. 

Der sektorale IDP stellt über standardkonforme Schnittstellen die zentralisierte Identitätsprüfung der auf die Fachdienste zugreifenden Nutzer bereit. Als weitere Teile der Gesamtlösung sind neben dem sektoraler IDP die Clients (Anwendungsfrontend) und die Fachdienste zu nennen, auf denen Fachdaten für den Zugriff durch die Nutzer (z. B. Versicherte oder Bediener eines AVS, PVS oder KVS) bereitgestellt werden. Ein sektoraler IDP bietet seine Dienste Fachdiensten an, auf welche Millionen Nutzer zeitgleich zugreifen. Auch Anwendungen außerhalb der TI-Föderation, z. B. kassenspezifische Anwendungen, werden direkt den jeweiligen sektoralen IDP nutzen.

Schnittstellen und Interaktion

Ein sektoraler IDP bietet zahlreiche Schnittstellen gegenüber unterschiedlichen Akteuren an. Die Beschreibung der Interaktionen zwischen den beteiligten Systemen über die Schnittstellen soll  die Funktionsweise anderen Akteure leichter verständlich machen. 

Vorbereitende Maßnahmen:

• Der Fachdienst hat bei der Registrierung am Federation Master seine öffentlichen Schlüssel hinterlegt.
• Der Fachdienst hat bei der Registrierung am Federation Master die scopes hinterlegt, welche er für die Autorisierung eines Nutzers zwingend benötigt
• Der Fachdienst kennt das Entity Statement der sektoralen IDP und hat bei der Registrierung dort seine öffentlichen Schlüssel hinterlegt.

Schnittstellen

Aus der Abbildung des Systemkontextes ist ersichtlich, welche Schnittstellen der sektorale IDP zu welchen Systemen unterhält (externe Schnittstellen). Neben den notwendigen externen Schnittstellen sind relevante interne Schnittstellen zwischen dem eigentlichen IDP - dem OpenID-Provider - und dem Authenticator-Modul aufgeführt. Die Tabelle listet die für die Spezifikation des sektoralen IDP relevanten und in diesem Dokument näher beschriebenen Schnittstellen auf.

Interaktionen

Der gesamte Authentifizierungsprozess (Abbildung: "OAuth- und OIDC-Flow") basiert aus Gründen der Entkoppelung zwischen den Authentifizierungsmethoden und Token-Formaten der sektoralen IDP und des Fachdienstes aus zwei ineinander geschachtelten OAuth2-Flows vom Typ grant_type=authorization_code.

Im äußeren Flow (Schritt 1) wendet sich das Anwendungsfrontend als Client initial an den Authorization-Server des Fachdienstes und signalisiert diesem über einen zusätzlichen nicht im OIDC-Standard spezifizierten Parameter idp_iss  den zur Authentifizierung zu verwendenden sektoralen IDP. Der innere Flow beginnt mit einem Authorization Request in Schritt 2 und endet mit Schritt 11, der Herausgabe eines ID-Token und Access-Token vom sektoralen IDP an den Authorization-Server des Fachdienstes.

Die erste Anfrage an den sektoralen IDP geht am PAR-Endpunkt [OAuth 2.0 Pushed Authorization Requests (section-2)]  ein. Der Authorization-Server des Fachdienstes reicht dort am Endpunkt den Authorization Request zur Authentifizierung des Nutzers und zur Bestätigung des scope der anfragenden Anwendung sowie eine  ein. Der scope der angefragten Nutzdaten ist im Entity Statement des Fachdienstes hinterlegt. Dieses ist dem sektoralen IDP bekannt. Ist das nicht der Fall, so wird das Entity Statement des Fachdienstes durch den sektoralen IDP abgefragt und durch den Federation Master bestätigt. Der Authorization-Server des Fachdienstes tritt bzgl. des inneren Flow als Client auf.

Im Weiteren Ablauf wird der Nutzer dann aufgefordert sich, unter Nutzung des Authenticator-Moduls des sektoralen IDP, zu authentisieren. Dies erfolgt über eine Schnittstelle zwischen dem Authenticator-Modul und Authorization-Endpunkt des sektoralen IDP. 

Nach erfolgreicher Authentisierung und der Consent-Freigabe durch den Nutzer erstellt der sektorale IDP den Authorization-Code. Dieser wird an den Authorization-Server des Fachdienstes übermittelt, welcher ihn am Token-Endpunkt [The OAuth 2.0 Authorization Framework (section-3.2) ] des sektoralen IDP einreicht. Der sektorale IDP überprüft den Authorization-Code und stellt bei positiver Validierung einen ID-Token und ein Access-Token aus.

Anschließend erstellt der Authorization-Server des Fachdienstes einen Authorization-Code, der an das Anwendungsfrontend zurückgegeben wird. Der äußere Flow endet mit der Herausgabe eines Access-Token an das Anwendungsfrontend bzw. im Fall von Web-Anwendungen an das Web-Backend des Anwendungsfrontends. Der weitere fachliche Ablauf zum Einreichen der Token und zur Nutzung der Fachdaten und Prozesse ist anwendungsspezifisch.

Es gibt einige Unterschiede in den Abläufen für App-App Kommunikation, Web-App Kommunikation und Kommunikation unter Beteiligung von zwei Geräten.