latest

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

Sektoraler Identity Provider

    

     

      
Version
      
2.3.1
     
     

      
Revision
      
879129
     
     

      
Stand
      
05.04.2024
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_IDP_Sek
     
    

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test und Betrieb des Produkttyps sektoraler Identity Provider (IDP). Ein sektoraler IDP basiert auf den Standards OpenID Connect (OIDC), Open Authorization 2.0 (OAuth 2) und JSON Web Token (JWT). Die hier beschriebenen Schnittstellen werden vom Authenticator-Modul und von Clients für eine Authentifikation eines Nutzers genutzt. Diese Authentifikation ist die Voraussetzung, damit ein Client Zugang zu Fachdaten und Prozessen eines Fachdienstes erlangen kann. Ein sektoraler IDP verwaltet und steuert den Authentifizierungsprozess für Anwendungen der Telematikinfrastruktur (TI).

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller und Anbieter von Identity Providern, welche die Funktionen eines sektoralen IDP für die TI realisieren wollen.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur TI des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. gemPTV_ATV_Festlegungen, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekanntgegeben.

Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzungen

Nicht Bestandteil des vorliegenden Dokumentes ist die konkrete Umsetzung der Authentifizierung eines Nutzers durch einen sektoralem IDP.

Als Umsetzungsleitlinie ist [OpenID Connect Core 1.0] heranzuziehen sowie das Kapitel "Authentifizierungsverfahren" . Die TI-weit übergreifenden Festlegungen – insbesondere aus Dokumenten wie beispielsweise [gemSpec_Krypt] bezüglich Algorithmen und Schlüsselstärken sowie [gemSpec_PKI] bezüglich zu verwendender Zertifikatstypen und deren Attributausprägungen – haben Bestand, sind weiterhin bindend und werden nicht in diesem Dokument beschrieben. Die konkreten, für das Produkt relevanten Anforderungen finden sich in den entsprechenden Steckbriefen.

1.5 Methodik

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Sie werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche zwischen Afo-ID und der Textmarke [<=] angeführten Inhalte.

Hinweis auf offene Punkte

2 Systemkontext

2.1 Allgemeiner Überblick

Zentrales Merkmal der zu entwickelnden Gesamtlösung der sektoralen IDP ist das Prinzip der Föderation. Die Funktionalität des IDP wird nicht von einem einzigen zentralen Dienst bereitgestellt, sondern „kollektiv“ durch eine Menge von sektoralen IDP, für die jeweils die entsprechenden identitätsherausgebenden Institutionen verantwortlich sind, welche auch für die jeweiligen Nutzergruppen zuständig sind.

Um eine Gesamtlösung sicherzustellen, bei der Anwendungen in möglichst einfacher Weise die verschiedenen sektoralen IDP nutzen können, sind in bestimmten Bereichen einheitliche Vorgaben für die technische und organisatorische Umsetzung zu erstellen:

• Einheitliche Identitätsattribute für die Nutzergruppen (scopes, claims)
• Einheitliche Verfahren zum Auffinden von sektoralen IDP (IDP Discovery)
• Grundstruktur der Vertrauensbeziehungen der Föderierung (Zwischen Fachdiensten und IDP)
• Einheitliche Vertrauensniveaus (Trust Framework).

Abbildung 1 : Überblick TI-Föderation

Die TI-Föderation besteht aus drei Systemen, welche untereinander über standardisierte Schnittstellen kommunizieren. Zusammen bilden die beteiligten Systeme einen Vertrauensraum.

Die TI-Föderation besteht aus mehreren Fachdiensten (Fachanwendungen). Die Fachdienste sind Apps oder Browseranwendungen. Hier werden Nutzern spezielle i.d.R. medizinische digitale Services angeboten. Die Fachdienste nutzen sektorale IDPs zur Überprüfung, ob ein Anwender zur Nutzung des Fachdienstes befugt (autorisiert) ist. Jeder Fachdienst verfügt über einen eigenen Authorization-Server, welcher basierend auf den Informationen der sektoralen Identity Provider über den jeweiligen Nutzer dessen Zugriffsrechte definiert.

Als sektoraler IDP wird ein Dienst zur Authentifizierung von Nutzern bezeichnet. Nach erfolgreichen Durchlaufen des Authentifizierungsprozesses stellt der sektorale IDP Identitätsinformationen für eine bestimmte Gruppe von Nutzern, welche einem Sektor zuzuordnen sind, innerhalb der Telematikinfrastruktur des Gesundheitswesens bereitstellt. Die Identitätsinformationen der Nutzer werden durch den anfordernden Fachdienst zur Prüfung verwendet, auf welche Fachdaten und -prozesse der Nutzer zuzugreifen darf. Insbesondere umfasst ein Sektor die Krankenkassen mit den Versicherten als Nutzer.  Zukünftig werden allerdings auch andere Personengruppen wie z. B. Ärzte oder Pflegeinstitutionen über Identity Provider für Leistungserbringer (LE) und Leistungserbringer Institutionen (LEI) angebunden. Dabei ist nicht ausgeschlossen, dass ein sektoraler IDP Identitätsinformationen mehrere Nutzergruppen bedienen kann (siehe auch Parameter "user_type_supported" in Kapitel "3.2 Anwendungsfall - IDP-Liste bereitstellen" in [gemSpec_IDP_FedMaster]).

Der TI-Vertrauensraum wird durch den sogenannten Federation Master (siehe [gemSpek_IDP_FedMaster]) verwaltet. Der Federation Master ist eine zentrale Komponente für alle Teilnehmer - Fachdienste und sektoralen IDPs - in der Föderation. Beim Federation Master sind alle Teilnehmer der Föderation registriert, nur dort registrierte Teilnehmer sind berechtigt, die Dienste der Föderation in Anspruch zu nehmen. 

Die Kommunikation zwischen den Systemen in der TI-Föderation basiert auf den Standards OpenID Connect (OIDC), Open Authorization 2.0 (OAuth 2) und JSON Web Token (JWT).

Neben den Systemen der TI-Föderation sind im Gesamtkontext weitere Systeme über Schnittstellen an die TI-Föderation angeschlossen (ohne selbst Bestandteil der Föderation zu sein). Das sind u.a. die Bestandsysteme, in denen aktuell die Informationen zu Nutzern gepflegt werden.

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.

2.2 Detaillierter Überblick

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. 

Abbildung 2: Systemkontext

2.3 Zerlegung des Produkttyps

Der Produkttyp des sektoralen IDP besteht aus 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 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 (siehe auch Kapitel 2.1. letzter Absatz).

2.4 Schnittstellen, Akteure und Rollen

2.4.1 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 spezifikationsrelevante interne Schnittstellen zwischen dem eigentlichen IDP - dem OpenID-Provider - und dem Authenticator-Modul aufgeführt. Die Tabelle "Schnittstellenübersicht" listet die für die Spezifikation des sektoralen IDP relevanten und in diesem Dokument näher beschriebenen Schnittstellen auf.

Tabelle 1 : Schnittstellenübersicht

2.4.2 Akteure und Rollen

Als sektoraler IDP wird ein Dienst bezeichnet, welcher die Nutzerauthentifizierung  durchführt. Nach erfolgreicher Nutzerauthentisierung stellt der sektorale IDP Identitätsinformationen zum Nutzer bereit. Die Identitätsinformationen werden von den Fachdiensten zur Durchführung einer Nutzerautorisierung verwendet, also zur Feststellung, auf welche Fachdaten und -prozesse des Fachdienstes dem Nutzer Zugriff gewährt wird. Die bereitgestellten Identitätsinformationen sind spezifisch für die unterschiedlichen Gruppen von Nutzern bzw. Sektoren innerhalb der TI des Gesundheitswesens. Einen Sektor stellen insbesondere die Krankenkassen mit den Versicherten als Nutzer dar. Zukünftig werden allerdings auch andere Personengruppen wie z. B. Ärzte oder Pflegeinstitutionen über sektorale IDP angebunden.

Im Systemkontext eines sektoralen IDP interagieren verschiedene Akteure (Nutzer und aktive Komponenten) in unterschiedlichen OAuth2-Rollen gemäß [The OAuth 2.0 Authorization Framework (section-1.1) ] und OpenID-Connect-Rollen gemäß [OpenID Connect Core 1.0] und [OpenID Connect Federation 1.0 ].

Die Abläufe zur Nutzerauthentifizierung  für einen Fachdienst sowie der Herausgabe der Identitätsinformationen durch den sektoralen IDP sind als innere Flow und der äußere Flow in Abschnitt 2.5 Nachbarsysteme und Interaktion erläutert.

Tabelle 2 : Akteure und Rollen

Nutzer (Rolle: Resource Owner) 

Der Resource Owner ist eine natürliche Person, welcher auf die beim Fachdienst (Resource Server) für ihn bereitgestellten Daten und Prozesse (Protected Resource) zugreift.

Der Resource Owner verfügt über die folgenden Komponenten:

• Endgerät des Nutzers
• Authenticator-Modul
• Anwendungsfrontend des Fachdienstes.

Fachdienst (Rolle: Authorization-Server)

Der Authorization-Server des Fachdienstes (OIDC Relying Party) stößt die Authentifizierung des Nutzers beim sektoralen IDP an und erhält als Ergebnis einen Authorization Code, den er gegen ein ID_TOKEN und ACCESS_TOKEN beim sektoralen IDP eintauschen kann. Der Authorization-Server des Fachdienstes verwendet die Informationen aus dem ID_TOKEN für die Feststellung der Zugriffsrechte des Anwendungsfrontend auf die Ressourcen des Fachdienstes. Der Authorization-Server des Fachdienstes stellt eigene ACCESS_TOKEN und REFRESH_TOKEN für das Anwendungsfrontend aus.

Fachdienst (Rolle: Resource Server)

Der Resource Server ist der Fachdienst, der dem Nutzer (Resource Owner) Zugriff auf seine Fachdaten und Prozesse (Protected Resource) gewährt. Der Fachdienst, der die geschützten Fachdaten (Protected Resources) anbietet, ist in der Lage, auf Basis von ACCESS_TOKEN Zugriff für Clients zu gewähren. Ein solches Token repräsentiert die delegierte Identifikation der Zugriffsberechtigung des Clients im Auftrag des Resource Owner.

Anwendungsfrontend (Rolle: Client)

Das Anwendungsfrontend (OAuth2 Client) greift auf Fachdienste (Resource Server) und ihre geschützten Fachdaten (Protected Resource) zu. Das Anwendungsfrontend kann auf einem Server als Webanwendung (Primärsystem als Terminalserver), auf einem Desktop-PC oder einem mobilen Gerät (z. B. Smartphone) oder als App auf einem mobilen Gerät ausgeführt werden. Finden für die Anwendung relevante Prozess (Businesslogik) in einem Hintergrundsystem statt, so ist die Backend-Komponente, welche die UI für die Visualisierung auf dem Gerät des Nutzers realisiert, ebenfalls Teil des Clients.

Sektoraler IDP mit dem Authenticator-Modul als Frontend (Rolle: OpenID Provider)

Der Authorization-Server des sektoralen IDP authentifiziert den Resource Owner (Nutzer) und stellt einen Authorization Code aus. Dieser Authorization Code kann später gegen ein ID_TOKEN beim sektoralen IDP eingetauscht werden. Das ID_TOKEN enthält die Informationen über den Nutzer (scopes bzw. claims), die für den Authorization-Server der Fachanwendung zur Zugriffsentscheidung über den angefragten für den vom Resource Owner erlaubten Anwendungsbereich (scope) benötigt werden.

Weitere Akteure im Kontext des sektoralen IDP sind:

Fachdaten und Prozesse (Rolle: Protected Resource)

Die geschützten Fachdaten und Prozesse, welche vom Fachdienst (Resource Server) angeboten werden.

Attributbestätigende Stelle

Attributbestätigende Stellen sind legitimierte Organisationen, welche die Korrektheit der Attribute verantworten, die durch sie für einen Nutzer beim sektoralen IDP bestätigt werden.

Als Teilprozess der Registrierung ist die zuverlässige und eindeutige Identifikation der Nutzer zwingend notwendig. Hierbei werden eindeutige Identifikationsmerkmale der realen Identitäten benötigt und letztlich als Identitätsinformationen dem sektoralen IDP zur Verfügung gestellt.

Die eindeutigen Identitäten von natürlichen Personen (Versicherte, Leistungserbringer) bzw. juristischen Personen (medizinische Institutionen, Gesellschafterorganisations- und Kostenträger) werden innerhalb der TI über die Krankenversichertennummer des Versicherten und die Telematik-ID eines Leistungserbringers bzw. einer medizinischen Institution oder Organisation des Gesundheitswesens repräsentiert.

Federation Master

Der Federation Master ist eine zentrale Komponente und ein eigener Produkttyp [gemSpec_IDP_FedMaster] in der TI. Der Federation Master bietet die Anwendungsfälle (siehe auch Tabelle Übersicht über die Anwendungsfälle im GesamtkontextFederation Master in [gemSpec_IDP_FedMaster]):

• Teilnehmer registrieren
• IDP-Liste bereitstellen
• Entity Statement bereitstellen
• Schlüssel der TLS-Zertifikate abgleichen
• Schlüssel verwalten

Alle Teilnehmer der Föderation müssen beim Federation Master registriert sein (siehe auch A_22662). Teilnehmer der Föderation sind in diesem Kontext alle Fachdienste und sektoralen IDP. Die Registrierung erfolgt durch einen organisatorischen Prozess, der vom Anbieter des Produkttyp Federation Master bereitgestellt wird. Der Federation Master verwaltet die öffentlichen Schlüssel aller Teilnehmer und zusätzlich für registrierte Fachdienste die jeweils zugelassenen scopes und claims. Er stellt auf Anfrage Teilnehmerbestätigungen in Form von Entity Statements aus. Der Federation Master agiert als Trust Anchor im Sinne der OpenID-Connect-Federation Spezifikation. Für Fachdienst stellt der Federation Master eine Schnittstelle bereit, über die eine Liste aller in der Föderation registrierten sektoralen IDP abgerufen werden kann.

2.5 Nachbarsysteme und Interaktion

Ein sektoraler IDP bietet zahlreiche Schnittstellen gegenüber unterschiedlichen Akteuren an, weswegen es notwendig ist, die einzelnen Schnittstellen so zu beschreiben, dass andere Akteure deren Funktionsweise leichter verstehen können. 

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.

Abbildung 3 : OAuth- und OIDC-Flow

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 Parameter idp_iss (siehe Kapitel 7.1.4 Detailinformationen zum Flow )  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 von scope und claims der anfragenden Anwendung sowie eine CODE_CHALLENGE ein. Der scope und die claims der angefragten Nutzdaten sind 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 wird 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.

Tabelle 3 : Schritte OAuth- und OIDC-Flow

Die Abläufe für App-App Kommunikation, Web-App Kommunikation und Kommunikation unter Beteiligung von zwei Geräten sind im Anhang B detailliert beschrieben.

2.6 Ausblick auf die weitere Entwicklung der sektoralen IDPs

Über den aktuellen Stand dieser Spezifikation hinaus werden verschiedene Erweiterungen der Funktionalitäten der sektoralen Identity Provider diskutiert, auf welche dieses Kapitel bereits einen Ausblick geben soll. Diese Aspekte benötigen jedoch zuvor eine angepasste Gesetzeslage, um in den Funktionsumfang des Identity Provider aufgenommen zu werden.

Möglichkeit der Einwilligung zur Nutzung von niederschwelligen Authentisierungsverfahren:

Die gematik plant, für die Versicherten neben den Authentifizierungsverfahren auf einem hohen Sicherheitsniveau zusätzlich auch komfortablere Verfahren auf einem niedrigeren Sicherheitsniveau zu erlauben, sofern die Versicherten nach sachgerechter Aufklärung über bestehende Risiken in diese Verfahren explizit einwilligen und die Einwilligung freiwillig erfolgt (d. h. Verfahren auf dem Niveau "hoch" auch tatsächlich parallel zur Verfügung stehen). Dabei ist sichergestellt, dass die Versicherten nur Risiken für sich selbst, niemals aber für Dritte eingehen können. Diese Einwilligungsmöglichkeit wird zudem bewusst nur für Versicherte, nicht aber für Leistungserbringende vorgesehen, da letztere auch Zugriff auf andere Patientendaten haben und deshalb durch die Einwilligung ein Risiko zulasten Dritter eingehen könnten.
Die einmalige Identifizierung (in Abgrenzung zur Authentifizierung) bleibt in jedem Fall auf dem Niveau "hoch", sodass zum einen eine lückenlose Identifizierung und Authentifizierung auf dem Niveau "hoch" ermöglicht wird und zum anderen, im Falle einer Einwilligung in ein niederschwelliges Authentifizierungsverfahren, die korrekte Identität des oder der Einwilligenden zweifelsfrei sichergestellt ist. Ziel ist es, die Nutzerakzeptanz zu verbessern, indem diese - im Sinne der informationellen Selbstbestimmung - selbst entscheiden können, wie komplex sie den Zugang zu ihren Anwendungen absichern wollen.

Biometrie:

Vorgaben zur Biometrie sind in der aktuellen Spezifikation noch nicht vorhanden sind, da nach Aussage des BSI kein ausreichendes Schutzniveau erreicht werden kann. Diese Features werden spezifiziert, sobald sie ein ausreichendes Schutzniveau erreichen können.

Die Verwendung von biometrischen Faktoren wird in die Spezifikation mit aufgenommen, sobald Einigung zu klaren technischen Vorgaben und Prozessen besteht, nach denen transparent für den Nutzer entschieden wird, ob die biometrischen Sensoren eines Endgerätes für den Einsatz als Authentisierungsfaktor verwendet werden können. Ebenso ist es Voraussetzung, dass die Umsetzung der Vorgaben auf Entwicklungsebene praktikabel mit Systemmitteln zu realisieren ist, ohne die Verwaltung der Schlüssel und biometrischen Sensoren in der Software der Authenticator Module realisieren zu müssen.

Unterstützung von sektoralen Identity Provider für Leistungserbringer:

Es werden die Vorgaben definiert, nach denen einer oder auch mehrere Identity Provider elektronische Identitäten für Leistungserbringer verwalten. Dies geschieht mit Fokus auf mobile Anwendungsszenarien. Mit entsprechenden Bedarfen soll es jedoch weitergehend auch auf Authentisierungen im Praxisumfeld erweitert werden. Die Institutionszugehörigkeit dabei als Attribut zu betrachten, welches durch benannte Vertreter der jeweiligen Institution verwaltet werden kann, wird in diesem Zusammenhang ebenfalls diskutiert.

3 Übergreifende Festlegungen

Der sektorale IDP muss die folgenden übergreifenden Anforderungen erfüllen.

Hinweis 1: Dies bezieht sich nicht auf für eine Authentisierung verwendete eGK oder den elektronischen Identitätsnachweis (Online-Ausweisfunktion).

Hinweis 2: Grundsätzlich sollte eine effektive Sperrung so schnell wie möglich erfolgen (siehe auch TR 03107-1 Kap. 3.4.1).

3.1 Sicherheitsanforderungen für den operativen Betrieb

Hinweis: Die Nichtanwendbarkeit eines OWASP-Top-10-Risikos ist zu begründen. Für Informationen zum Umgang mit den OWASP-Top-10-Risiken wird auf den aktuellen [OWASP Top 10 Report] und die darin enthaltenen Vorgehensweisen für z. B. Entwickler und Tester verwiesen.

Hinweis 1: Eine Übersicht zu den externen Schnittstellen findet sich in der Tabelle "Schnittstellenübersicht".

Hinweis 2: Die Attributbestätigende Stelle (z. B. der Kostenträger für Versicherte) verantwortet die Korrektheit dieser Daten.

Hinweis 1: Eine Protokollierungspflicht besteht nicht.

Hinweis 2: Sollte es zur Störungsbehebung notwendig sein, eine Fachdienstanfrage und Nutzerauthentisierung zu korrelieren, kann der sektorale IDP zu diesem Zweck die durch den Fachdienst für diesen Fall auf organisatorischem Weg zu liefernde "nonce" der Anfrage nutzen.

Hinweis: Eine Prüfung der Eingabewerte muss produktseitig bereitgestellt werden und sollte mindestens Prüfungen auf Länge, Character Set, Schlüsselwörter und Steuerzeichen enthalten. Ein Fuzzing im Rahmen des Produkttests bzw. der Inbetriebnahme ist durchzuführen.

Hinweis: Serviceprozesse welche der Nutzer über den Support in Anspruch nimmt (z. B. Passwort ändern/rücksetzen) sind von dieser Anforderung nicht betroffen.

Hinweis: Im Regelfall erfolgen solche Datenänderungen in den Bestandsystemen der Krankenkassen, die über Synchronisationsprozesse den Datenbestand des sektoralen IDP aktualisieren. Hier erfolgt die Information an die Versicherten allein über die kassenüblichen Prozesse.

Hinweis: Durch die Zurückweisung von Verbindungen wird sichergestellt, dass Clients einen Verbindungsaufbau mit einer anderen Instanz des Dienstes versuchen, bei der die erforderlichen Systemressourcen zur Verfügung stehen.

Hinweis: Weitere Informationen finden Sie unter: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/RZ-Sicherheit/Standort-Kriterien_Rechenzentren.pdf

Hinweis: Eine Übersicht zu den Schnittstellen findet sich in der Tabelle "Schnittstellenübersicht".

Hinweis: Die Informationen zu den Empfehlungen des BSI sind zu berücksichtigen:
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Cyber-Sicherheit/Themen/Dienstleister-DDos-Mitigation.html
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Cyber-Sicherheit/Themen/Dienstleister-DDos-Mitigation-Liste.pdf; 

Hinweis: Ein Aktiv-Aktiv Betrieb der beiden Standorte ist nicht gefordert, entscheidend ist die Sicherstellung der Verfügbarkeit.

Hinweis: Im Regelprozess sichert der Betreiber in Eigenverantwortung zu, dass nur unterstützte und sichere Versionen des Authenticator-Moduls mit den Serverkomponenten des Sektoralen IDP kommunizieren dürfen.
Bei dieser Anforderung handelt es sich um eine betriebliche Eskalation im Notfall und nicht um einen Regelprozess. 

Hinweis: Für TLS Schlüssel ist dies konsistent zu den aktuellen Vorgaben des CAB-Forum.

3.2 Vertrauenswürdige Ausführungsumgebung

In diesem Abschnitt werden die Anforderungen an den sektoralen IDP zur Umsetzung einer Vertrauenswürdigen Ausführungsumgebung (VAU) dargestellt. Die VAU dient der datenschutzrechtlich zulässigen und sicheren Verarbeitung von schützenswerten Klartextdaten innerhalb des sektoralen IDP sowie dem technischen Ausschluss einer Profilbildung durch den Anbieter bzw. Betreiber. Sie verhindert ein Eingreifen des Anbieters in den sicheren Betrieb und die Manipulation von Daten. Die VAU stellt dazu Verarbeitungskontexte (d. h. Instanzen der VAU) bereit, in denen die Verarbeitung sensibler Daten im Klartext erfolgen kann. Diese Verarbeitungskontexte sind entsprechend zu schützen. Durch diese Ausgrenzung des Betreibers von kritischen Operationen ist es nicht mehr Notwendig Einschränkungen für den Umfang der weiteren durch den Anbieter bzw. Betreiber bereitgestellten Dienste umzusetzen, um möglichen Interessenkonflikten zu begegnen. Im Anhang C ist u.a. ein  beschrieben.

Abbildung 4: Schnittstellen der in der VAU laufenden Komponente des sektoralen IDP

Tabelle 4: Vorgaben für die im sektoralen IDP befindlichen Endpunkte zur Ausführung in einer VAU 

3.2.1 Verarbeitungskontext

Die Gesamtheit aus der für eine Klartextverarbeitung erforderlichen Software, dem für eine Klartextverarbeitung genutzten physikalischen System sowie den für die Integrität einer Klartextverarbeitung erforderlichen organisatorischen und physischen Rahmenbedingungen bildet den Verarbeitungskontext der Vertrauenswürdigen Ausführungsumgebung (VAU). Zur Vertrauenswürdigen Ausführungsumgebung gehören neben den Verarbeitungskontexten alle für ihre Erreichbarkeit und betriebliche Steuerung erforderlichen Komponenten. Der Verarbeitungskontext grenzt sich von allen weiteren, im betrieblichen Kontext beim Anbieter des sektoralen IDP vorhandenen Systemen und Prozessen dadurch ab, dass die sensiblen Klartextdaten von Komponenten innerhalb des Verarbeitungskontextes aus erreichbar sind oder sein können, während sie dies von außerhalb des Verarbeitungskontextes nicht sind. Sensible Daten verlassen den Verarbeitungskontext ausschließlich gemäß wohldefinierten (Zugriffs-)Regeln und in verschlüsselter Form.

Umsetzungsempfehlungen für die Realisierung einer Vertrauenswürdigen Ausführungsumgebung finden sich im Anhang C.

Hinweis 1: Siehe in diesem Zusammenhang auch A_23031 - TLS-Verbindung Authenticator-Modul - Vertrauenswürdige Ausführungsumgebung.

Hinweis 2: Ein Logging zur Betriebsüberwachung und Fehleranalyse ist zulässig, darf jedoch keine Identifikation des genutzten Fachdienstes zulassen.

3.2.2 Ausschluss von nicht autorisierten Zugriffen aus dem Betriebsumfeld

Der Schutzbedarf der in der VAU verarbeiteten Klartextdaten erfordert den technischen Ausschluss von Zugriffen des Anbieters. Dies umfasst insbesondere Zugriffe durch Personen aus dem betrieblichen Umfeld des Anbieters.

Hinweis: Schützenswerten Daten im Kontext der sektoralen IDP sind die Daten, welche innerhalb der VAU zum laufenden Authentifizierungsprozess erzeugt bzw. gespeichert werden (client_id, state, redirect_uri, code_challenge, AUTHORIZATION_CODE, ID-TOKEN), sowie die Daten für das Nutzerprotokoll.

Hinweis: Schützenswerten Daten im Kontext der sektoralen IDP sind die Daten, welche innerhalb der VAU zum laufenden Authentifizierungsprozess erzeugt bzw. gespeichert werden (client_id, state, redirect_uri, code_challenge, AUTHORIZATION_CODE, ID-TOKEN), sowie die Daten für das Nutzerprotokoll.

Hinweis: Kommt es zum TLS Verbindungsaufbau und es besteht eine HTTP-Verbindung zwischen Fachdienst und sektoralen IDP, so muss der sektorale IDP gemäß Anforderung A_22649 den Fachdienst als unbekannt abweisen, wenn ihm das TLS-Zertifikat des Fachdienstes nicht bekannt ist oder es nicht mit dem im Entity Statement des Fachdienstes übermittelten TLS-Zertifikat übereinstimmt.

Hinweis: Die Erstellung einer eigenen Subdomäne für die VAU eines sektoralen IDP ist notwendig um die Certificate Transparency TLS-Zertifikate im Federation Master effektiv prüfen zu können.

Hinweis: Auf diesem Weg kann der Federation Master verifizieren, dass keine TLS-Zertifikate für diese Adressen erstellt werden deren privater Schlüssel nicht nachgewiesenermaßen im Verarbeitungskontext der VAU liegt. Der Federation Master bietet hierzu einen organisatorischen Prozess an.

Hinweis: Da der Verarbeitungskontext der VAU des sektoralen IDP für jede fachliche Operation neu aufgebaut werden muss, ist ein Low-Level-Mechanismus zur Kontextseparation aus Gründen der Performance bzw. Skalierung nicht zwingend vorgeschrieben. Der hier geforderte Separationsmechanismus kann daher auch als Server-Thread, Worker, o. Ä. ausgeführt sein, solange für den dadurch gebildeten Verarbeitungskontext die geforderte Separation nachgewiesen werden kann. Dies setzt voraus, dass die Umsetzung der Verarbeitungskontexte und der in ihnen ablaufenden Verarbeitungsvorgänge technisch möglichst einfach und nachvollziehbar gestaltet ist.

Hinweis 1: Schützenswerten Daten im Kontext der sektoralen IDP sind die Daten, welche innerhalb der VAU zum laufenden Authentifizierungsprozess erzeugt bzw. gespeichert werden (client_id, state, redirect_uri, code_challenge, AUTHORIZATION_CODE, ID-Token), sowie die Daten für das Nutzerprotokoll.

Hinweis 2: Für die Separation zwischen Verarbeitungskontexten und Verarbeitungsprozessen des Anbieters, die der betrieblichen Steuerung des Systems dienen, ist eine Low-Level Separation anzustreben, da - im Unterschied zur Separation zwischen Verarbeitungskontexten - hier technisch sehr verschiedene Aspekte getrennt werden müssen.

Hinweis: Falls die Verarbeitungskontexte als Threads, Workers, o. ä. umgesetzt sind und daher gemeinsam in einem übergreifenden Anwendungsprozess ausgeführt werden, kann dieser Anwendungsprozess eine authentisierte Verbindung zur Kryptographieschnittstelle des HSM herstellen und aufrechterhalten, um darüber die Kryptographieschnittstelle des HSM den Verarbeitungskontexten (und nur diesen) lokal zur Verfügung zu stellen. Das bedeutet auch, dass die Hardware für mehrere Mandanten nutzbar ist. Dabei muss allerdings sichergestellt werden, dass der Schlüsselzugriff nur im Verarbeitungskontext des jeweiligen Mandanten möglich ist.

3.2.3 Konsistenz des Systemzustands, Logging und Monitoring

Hinweis: Eine Möglichkeit zur Wiederherstellung der Konsistenz kann im Roll-Back des Verarbeitungskontexts auf den letzten konsistenten Zustand vor dem Auftreten des Fehlers bestehen. Das Ziel der Anforderung ist in jedem Fall sicherzustellen, dass der besonders geschützte Verarbeitungskontext nicht durch eine Fehlersituation in einen nicht zu korrigierenden, nicht nutzbaren Zustand gelangen kann, der weitere Zugriffe des Nutzers unmöglich machen könnte.

3.3 Betriebliche Unterstützung des Probings

Zur Überprüfung der Erreichbarkeit des sektoralen IDP werden durch die gematik regelmäßig invalide Requests an diese Schnittstellen gemäß Entity Statement (siehe Tabelle: "Body Entity Statement des sektoralen IDP") gestellt.:

• pushed_authorization_request_endpoint
• token_endpoint 

Als Ergebnis der Request wird ein Fehlercode gemäß [OpenID Connect Federation 1.0#rfc.section.7.5] erwartet. Testidentitäten müssen demnach in der produktiven Umgebung nicht bereitgestellt werden.

Hinweis: Die Benachrichtigung an die gematik kann per E-Mail (S/MIME) an transition@gematik.de erfolgen.

3.4 Testseitige Vorgaben an den sektoralen IDP

Föderiertes Identitätsmanagement stellt einen der ersten Schritte auf dem Weg von der bestehenden TI 1.0 mit ihren drei getrennten Umgebungen hin zu einer cloudbasierten TI 2.0, in der die Dienste über das Internet erreichbar sind, dar. Daher müssen die sektoralen IDPs einerseits mit bestehenden Strukturen und Konzepten verträglich sein, andererseits zukünftige Entwicklungen unterstützen. Dieser Konflikt zeigt sich deutlich in den testseitigen Anforderungen an den Anbieter und das Produkt. Übergreifende Anforderungen aus [gemKPT_Test] passten inhaltlich nicht mehr vollständig und neue Anforderungen werden notwendig.

3.4.1 Testinstanzen

Damit die gematik Zulassungstests durchführen kann und andere Hersteller frühzeitig mit den sektoralen IDP integrieren können, werden neben der produktiven Instanz auch Testinstanzen benötigt. Auch wenn diese eigentlich nicht mehr Teil der geschlossenen Netze RU und TU der TI 1.0 sind, werden sie zur besseren Verständlichkeit mit den bestehenden Strukturen in Verbindung gebracht. Daher bezeichnen wir die Instanz für entwicklungsbegleitende Integrationstest im Folgenden als RU-Instanz und die sehr produktionsnahe Instanz für Abnahmen und Zulassungstests im Folgenden als TU-Instanz.

3.4.1.1 zentrale Komponente

3.4.1.2 Authenticator-Modul

3.4.2 Testidentitäten

Um eine Nutzung der Testinstanzen eines sektoralen IDPs in produktübergreifenden Integrationstests anderer Hersteller und bei Zulassungstests durch die gematik zu ermöglichen, werden Testidentitäten benötigt. Abhängig von der genauen Verwendung ergeben sich unterschiedliche Anforderungen an diese Testidentitäten. Im Folgenden werden wir zwischen "einfachen" und "komplexen" Testidentitäten unterscheiden. "Einfache" Testidentitäten sollen z. B. in automatisierten e2e-Tests, in Zulassungstests des sektoralen IDPs oder zum Nachweis der Interoperabilität mit dem Authenticator-Modul verwendet werden. Sie müssen nicht den gesamten Life Cycle einer Identität abbilden. Im Gegensatz dazu sind "komplexe" Testidentitäten für den Einsatz in komplexen e2e-Tests und in speziellen Tests zur Authentisierung und zum Life Cycle vorgesehen. Dafür benötigen sie einen Bezug zu den Bestandssystemen der Kassen und müssen sich auch sonst wie die produktiven Identitäten verhalten.

4 Funktionsmerkmale

4.1 Entity Statement des sektoralen IDP

Das Entity Statement enthält die Metadaten und Adressen des sektoralen IDP, sowie seine verwendeten kryptographischen Identitäten.

Hinweis 1: Die öffentlichen Schlüssel für Signatur von Entity Statement müssen nicht in der VAU liegen. Hier kann der Anbieter einen nicht weiter vorgegebenen Prozess etablieren.

Hinweis 2: Der organisatorische Prozess zur Teilnehmerregistrierung wird vom Anbieter des Federation Master [gemSpec_IDP_FedMaster] bereitgestellt.

Hinweis: Nicht betroffen von dieser Anforderung sind kurzfristig notwendige Schlüsselwechsel, z. B. aufgrund von Sicherheitsvorfällen. Diese Maßnahmen sind beispielsweise über security incidents abzuwickeln. Die Bearbeitung solcher kurzfristigen Schlüsselwechsel muss die Aktualisierung beim Federation Master mitberücksichtigen, da es ansonsten zu Verarbeitungsfehlern wegen ungültiger Schlüssel kommen kann.

Hinweis: Die Anforderung gilt sowohl für die Entity Statements der Fachdienste als auch für die Entity Statements des Federation Master über diese Fachdienste. Ist der Federation Master oder der Fachdienst ggf. temporär nicht erreichbar, so sollte das Herunterladen der Entity Statements über die Fachdienste weiter (z.B. stündlich) versucht werden.

Hinweis: Das Verwerfen des Entity Statements eines bekannten Fachdienstes dient der Aktualisierung des Status des Fachdienstes und bedeutet nicht eine automatische Deregistrierung des Dienstes beim IDP.

4.2 API-Endpunkte des sektoralen IDP

4.2.1 Anforderung an die Schnittstelle zum Authorization-Server des Fachdienstes

Hinweis: Wenn eine signed_jwks_uri im Entity Statement des Fachdienstes angegeben ist, müssen auch diese Schlüssel importiert werden. Sowohl dies als auch die Nutzung eines jwks im Statement selbst muss unterstützt werden.

4.2.2 PAR - Endpunkt

Am PAR-Endpunkt des sektoralen IDP werden Anfragen der Authorization-Servern eines Fachdienstes eingereicht und verifiziert. Inhalt der Anfrage ist unter anderem: 

• Die client_id des anfragenden Fachdienstes sowie dessen öffentlicher Authentisierungsschlüssel.
• Die redirect_uri, an welche der Authorization Request beantwortet werden soll.
• Der über das eigene CODE_VERIFIER [Proof Key for Code Exchange by OAuth Public Clients (section-4.1)] gebildete HASH CODE_CHALLENGE [Proof Key for Code Exchange by OAuth Public Clients (section-4.2)] mit Angabe des Algorithmus code_challenge_method [Proof Key for Code Exchange by OAuth Public Clients (section-4.3)] entsprechend dem gewählten Authorization Code Flow (response_type=code).
• Der state-Parameter [OAuth 2.0 for Native Apps (section-8.9)] wird genutzt, um CSRF (Cross-Site-Request-Forgery) zu verhindern.
• Der scope und die claims der Anfrage, welcher einen definierten Satz von benötigten Attributen für die entsprechende Anwendung beinhaltet.

Der PAR-Endpunkt des sektoralen IDP nimmt den Pushed Authorization Request [OAuth 2.0 Pushed Authorization Requests] des Authorization-Server eines Fachdienstes entgegen. Der am PAR-Endpunkt des sektoralen IDP eingehende Request wird validiert, um frühzeitig unautorisierte Abfragen zu verhindern.

Ist der Pushed Authorization Request geprüft und valide, erstellt der PAR-Endpunkt des sektoralen IDP eine Request-URI. Diese wird im weiten Ablauf für die Nutzerauthentifizierung benötigt. Die Request-URI und deren Gültigkeitsdauer sind Parameter der Antwort des sektorale IDP auf den eingegangenen Request.

4.2.2.1 PAR-Endpunkt Eingangsdaten

Hinweis: Nach [OpenID Connect Core 1.0# AuthRequest] ist es zulässig, dass ein Client mehrere redirect_uri bei der Registrierung hinterlegt. Der sektorale IDP muss laut der OIDC-Spezifikation prüfen, ob die im Request gelieferte redirect_uri mit exakt einer der hinterlegten redirect_uri übereinstimmt. Die Prüfung muss über eine 'Simple String Comparison' nach [Uniform Resource Identifier (URI)#section-6.2.1] erfolgen.

Hinweis: Der Fachdienst gegen dessen Entity Statement geprüft werden muss wird durch die client-id im Request identifiziert.

4.2.2.2 PAR-Endpunkt Ausgangsdaten

4.2.3 Authorization-Endpunkt

Am Authorization-Endpunkt des sektoralen IDP wird in Kommunikation mit dem Authenticator-Modul die Authentisierung des Nutzers durchgeführt.

4.2.3.1 Schnittstelle Authorization-Endpunkt

4.2.3.2 Authorization-Endpunkt Ausgangsdaten

Sind alle in scope bzw. claims geforderten Attribute vorhanden und die Gültigkeit der Attribute geprüft sowie eine erfolgreiche Authentifizierung des Nutzers erfolgt, erstellt der Authorization-Endpunkt des sektoralen IDP einen AUTHORIZATION_CODE und sendet diesen an den Authorization-Server eines Fachdienstes.

Hinweis: Im Fall des App-App-Flow (7.1 App-App-Flow) und des Web-App-Flow (7.2 Web-App-Flow) wird der Request durch das Authenticator-Modul angenommen und an den sektoralen IDP gestellt. Im Fall des Zwei-Geräte-Flow (7.3 Zwei-Geräte-Flow) wird der Request direkt über den Browser gestellt und damit auch an diesen zurückgeliefert.

4.2.4 Token-Endpunkt

Der Token-Endpunkt des sektoralen IDP nimmt die Anfrage des Authorization-Server eines Fachdienstes entgegen und prüft neben deren Integrität, ob der eingereichte CODE_VERIFIER bei Nutzung des Hash-Verfahrens S256 (nach [Proof Key for Code Exchange by OAuth Public Clients (section-4.2)]) zum bitgleichen Hash-Wert führt. Stimmt der Hash-Wert aus dem initialen Aufruf über das Authenticator-Modul - die Code-Challenge - mit dem gebildeten Hash-Wert überein, ist sichergestellt, dass Aufrufer und Initiator identisch sind. Der Token-Endpunkt gibt daraufhin das ID_TOKEN an den Authorization-Server des Fachdienstes heraus.

4.2.4.1 Token-Endpunkt Eingangsdaten

Hinweis: Der Fachdienst gegen dessen Entity Statement geprüft werden muss wird durch die client-id im Request identifiziert.

Das Protokoll wird intern und ggf. für Audits verwendet.

4.2.4.2 Token-Endpunkt Ausgangsdaten

Hinweis: Nicht vorhandene oder zur Weitergabe nicht zugestimmte claims werden nicht in den ID_TOKEN übernommen.

Hinweis 1: Die angefragten scopes werden so mit Werten belegt, wie sie zum Abfragezeitpunkt beim sektoralen IDP (bzw. dessen Quellsystem) vorliegen.

Hinweis 2:  Die Regel zur Festlegung des Geburtsdatums bei unbekanntem Tag bzw. Monat basiert auf den Gemeinsamen Grundsätzen für die Datenerfassung und Datenübermittlung (DEÜV) (https://www.gkv-datenaustausch.de/media/dokumente/arbeitgeber/deuev/rundschreiben_anlagen/04_Gem_RS_Anlage_9.4_Vers_8.00.pdf)

Hinweis 3: Die über den scope urn:telematik:email angefragte Adresse ist vor der Verwendung durch den Fachdienst zu verifizieren. Eine Verifikation durch den IDP ist nicht vorgesehen, da diese ohnehin nur eine begrenzte zeitliche Gültigkeit haben kann.

Hinweis 4: Da ein Wechsel des Email-Provider durch den Nutzer jederzeit möglich ist und die Email-Adresse bei sektoralen IDPs nicht für alle Versicherten zuverlässig und vorhanden vorausgesetzt werden kann, wird von der Verwendung der Email als 'essential claim' abgeraten, um keine Nutzer ungewollt auszuschließen. Fachdienste sind angehalten, ggf. angeforderte Email-Adressen selbständig vor deren Verwendung auf Gültigkeit zu überprüfen.

4.3 Identifizierung und Authentifizierung des Nutzers

Die Durchführungsverordnung (EU) 2015/1502 [eIDAS 2015/1502] gemäß Artikel 8 Absatz 3 der Verordnung (EU) Nr. 910/2014 [eIDAS 910/2014] legt die Mindestanforderungen an technische Spezifikationen und Verfahren  für Vertrauensniveaus elektronischer Identifizierungsmittel fest.

Die Identifikation des Nutzers muss immer Angreifern mit hohem Angriffspotential standhalten.

Im Rahmen der Anbieterzulassung prüft der unabhängige Sicherheitsgutachter, dass die vom Anbieter verwendeten Mechanismen die Mindestanforderungen A_23024 bzw. A_23025 des jeweiligen Vertrauensniveaus erfüllen.

Hinweis: Beim Vorliegen von Zertifizierungen, welche kein Vertrauensniveau ausweisen oder keine unterschiedlichen Angriffspotentiale berücksichtigen, ist eine Nachnutzung möglich, soweit eine Eignung zum Widerstand gegen das Angriffspotential im Sicherheitsgutachten nachgewiesen wird.

Hinweis 1: Beim Vorliegen von Zertifizierungen, welche kein Vertrauensniveau ausweisen oder keine unterschiedlichen Angriffspotentiale berücksichtigen, ist eine Nachnutzung möglich, soweit eine Eignung zum Widerstand gegen das Angriffspotential im Sicherheitsgutachten nachgewiesen wird.

Hinweis 2: Im Folgenden wird an den relevanten Stellen ausschließlich gematik-ehealth-loa-high oder/und gematik-ehealth-loa-substantial verwendet.

Hinweis: weitere Werte des claim acr sind zulässig aber werden nicht spezifiziert und auch nicht im Rahmen von Anwendungen der Telematikinfrastruktur genutzt.

Im Rahmen von Anwendungen der TI kommt aktuell nur das Niveau gematik-ehealth-loa-high zum Einsatz.

4.3.1 Identifikation des Nutzers

Eine Notifizierung des elektronischen Identifizierungssystems, welches die elektronischen Identifizierungsmittel ausstellt, ist nicht gefordert. Ebenso ist nicht gefordert, dass der Anbieter ein qualifizierter oder nicht-qualifizierter Vertrauensdiensteanbieter gemäß Verordnung (EU) Nr. 910/2014 ist.

Hinweis: Ist bei einer Identifikation des Nutzers mittels Online-Ausweisfunktion keine eindeutige Zuordnung zu einer natürlichen Person im Bestandssystem (z. B. auf Basis der dort für eine Identifikation nach [GKV-SV Richtlinie "Kontakt mit Versicherten] hinterlegten Daten) möglich, so kann die Aufklärung der Diskrepanzen bis zum Erreichen einer klaren Zuordnung, außerhalb des Kontextes des sektoralen IDP erfolgen.

Hinweis 1: Zertifizierungen, Notifizierung  oder Bestätigungen von Prozessen oder Prozessbestandteilen vergleichbarer Normen und Richtlinien, z. B. nach Verordnung (EU) Nr. 910/2014 in Verbindung mit (EU) 2015/1502 an elektronische Identifizierungsmittel, BSI TR-03107-1 oder vergleichbar, können nachgenutzt werden.

Hinweis 2: Die Einzelfallprüfung erfolgt durch die gematik in Abstimmung mit dem BSI.

Hinweis 3: Die gematik veröffentlicht und aktualisiert regelmäßig eine Liste der zugelassenen Identifikationsverfahren im Fachportal [Zulässigkeit von Identifikationsverfahren].

4.3.2 Authentifizierungsverfahren

Nach [TR-03107-1] "Elektronische Identitäten und Vertrauensdienste im E-Government Teil 1#Tabelle 2: Grundlegende Kriterien für die Vertrauensniveaus" werden je nach Vertrauensniveau unterschiedliche Anforderungen an die Authentifizierung von Nutzern gestellt. Diese bilden für die gematik die Grundlage für die folgenden Anforderungen.

Hinweis: Das amr claim wird generell von sektoralen IDPs im ID_TOKEN gemäß der Anforderung A_23129-01 mitgeliefert. Um ein bestimmtes Authentisierungsmittel bei der Nutzerauthentifizierung durch den sektoralen IDP zu erzwingen, fordert die Relying Party dies im Authorization Request mittels claims Parameter an.
Beispiel: claims Parameter (URL encoded) zum Anfordern der Nutzerauthentifizierung mit eGKclaims%3D%7B%22id_token%22%3A%7B%22amr%22%3A%7B%22values%22%3A%5B%22urn%3Atelematik%3Aauth%3AeGK%22%5D%7D%7D%7D

Hinweis: Unter iOS wird die Anwendung automatisch geschlossen, wenn der Nutzer 3 min inaktiv war.

Hinweis: Für das Veranlassen zum Öffnen des Authenticator-Moduls durch den Nutzer gibt es unterschiedliche technische Möglichkeiten (z. B. scannen eines QR-Code von Web-Seite und Codeeingabe im Authenticator, 1-Faktor Login auf Web-Seite und push an Authenticator, u. a.). Diesbezüglich werden keine Anforderungen formuliert, es können auch mehrere Verfahren angeboten werden. Es müssen vom Hersteller jedoch Maßnahmen ergriffen werden, die klassische Angriffsszenarien auf den Authentisierungsvorgang wie z.B. Remote Phishing und/oder Session Spying verhindern bzw. erschweren.

Hinweis: Dies könnten z. B. Änderungen von E-Mail-Adressen, Mobilfunknummern, registrierten Geräten oder Kennwörtern sein. Die Informationen sollen über entsprechende Anzeige im Authenticator-Modul erfolgen.

Hinweis 1: Die Minimalinformationen bestehen aus Datum/Uhrzeit des Zugriffs, Authentisierungsmittel, Gerät. Weitere Informationen, die für die Nutzer sinnvoll sind optional. 

Hinweis 2: Die Auskunft könnte z. B. über eine Protokollfunktion im Authenticator-Modul erfolgen. Die Auskunft des Versicherten kann auch über die Attributbestätigende Stelle erfolgen, der den Anbieter des sektoralen IDP mit der Erstellung des elektronischen Identifizierungsmittels beauftragt hat.

4.3.2.1 Gerätenutzung

Die unterschiedliche Ausstattung der mobilen Geräte erfordert unterschiedliche Anforderung hinsichtlich der Authentifizierungsverfahren. Unterschieden werden:

• Geräte ohne Hardware Keystore
• Geräte mit Hardware Keystore
• Geräte mit zertifiziertem Secure Element.

Das Vorhandensein eines Hardware Keystore wird hierbei wie folgt definiert:

• Apple - Entscheidend ist das Vorhandensein eines "Secure Enclave" [support.apple.com/guide/security]. Diese ist Bestandteil der A7 und neueren Chips von Apple. Die A7 Serie wurde erstmals 2013 mit dem iPhone 5s eingeführt.
• Android - Ab Android 9 gibt es den Systemaufruf [KeyInfo#getSecurityLevel()], um die Speicherung eines Schlüssels im Hardware Keystore abzufragen. Die Rückgabewerte KeyProperties.SECURITY_LEVEL_TRUSTED_ENVIRONMENT , KeyProperties.SECURITY_LEVEL_UNKNOWN_SECURE oder KeyProperties.SECURITY_LEVEL_STRONGBOX sind zulässig. Ältere Systeme bieten die Schnittstelle [KeyInfo#isInsideSecureHardware()] an. Hier ist der Rückgabewert true zulässig.

Hinweis: Die Überprüfung, zu welcher der in der Tabelle aufgeführten Kategorien das Gerät mit dem Authenticator-Modul gehört, kann im Authenticator-Modul selbst erfolgen oder alternativ beim sektoralen IDP durch Übermittlung der notwendigen Informationen vom Authenticator-Modul an den sektoralen IDP.  Die Überprüfung der in der Tabelle je Kategorie genannten Gültigkeitszeiträume für eine Gerätebindung erfolgt beim sektoralen IDP.

Hinweis: In der Praxis erlaubt dieses Vorgehen primär die Nutzung von nicht zertifizierten Hardware Keystores für eine Authentisierung auf dem formalen Sicherheitsniveau "gematik-ehealth-loa-high".

Hinweis: Die Tabelle "Übersicht Gerätebindung für gematik-ehealth-loa-high" weicht ab von der  Anforderung A_23025. Die Kriterien für die in der Tabelle angegebene Gerätebindung genügen der Verwendung als Authentisierungsfaktor für "gematik-ehealth-loa-high" und der in A_23025 geforderten Angriffswiderstand muss nicht nachgewiesen werden.

Hinweis: A_23700 weicht von der Anforderung A_23025 ab. Die System-PIN bzw. das System-Passwort kann jedoch zurzeit als genügend für die Verwendung als Authentisierungsfaktor auf Niveau "gematik-ehealth-loa-high" angesehen werden. Der in A_23025 geforderte Angriffswiderstand muss nicht nachgewiesen werden.

5 Anforderungen an Authenticator-Module sektoraler IDPs

5.1 Funktionsmerkmale Authenticator-Modul

Die folgende Beschreibung in diesem Kapitel gilt für Authenticator-Module sektoraler Identity Provider im Rahmen der Föderation. Entsprechende Vorgaben für die Authenticator-Modul des IDP-Dienstes finden sich in [gemSpec_IDP_Dienst].

Das Authenticator-Modul ist ein Modul, welches in einer Applikation für mobile Endgeräte wie Smartphones bereitgestellt wird. Bei Nutzung eines Primärsystems wird die Funktionalität des Authenticator-Moduls vom Primärsystem selbst realisiert.

Die Bereitstellung des Authenticator-Moduls erfolgt über die dem jeweiligen Betriebssystem üblicherweise zur Verfügung stehenden Portale in einer sicheren, für den Nutzer kostenfreien Form.

Aufgabe des Authenticator-Moduls ist die Nutzerauthentifizierung gegenüber dem sektoralen IDP, bei welchem der Nutzer als Identität hinterlegt ist. Eine weitere Aufgabe ist das Einholen der Zustimmung des Nutzers (Resource Owner) für den Zugriff durch Fachdienste auf Attribute des Nutzers (Consent-Freigabe). 

Es können je sektoralem IDP ein oder mehrere Authenticator-Module existieren, welche die Authentisierung des Benutzers durchführen. Über die generellen Vorgaben zum Authentifizierungsverfahren hinaus werden hier keine funktionalen Vorgaben gemacht.

Der Anbieter des sektoralen IDP ist für seine Authenticator-Module zuständig. Eine organisatorische Zuständigkeitstrennung zwischen Authenticator-Modulen und Anbietern sektoraler IDPs ist möglich. Ansprechpartner und verantwortlich bleibt in jedem Fall der Anbieter des sektoralen IDP - auch für Produkte von anderen Herstellern.

Aufgabe des Authenticator-Moduls ist, den zum Abruf der ID_TOKEN und ACCESS_TOKEN benötigten AUTHORIZATION_CODE, mit Zustimmung des Nutzers (Resource Owner) und nach eingehender Überprüfung dessen Identität, zu beantragen. Dazu nimmt das Authenticator-Modul die Authentifizierungs-Anfrage des Anwendungsfrontend entgegen und reicht diese am Authorization-Endpunkt des sektoralen IDPs ein. Der Authorization-Endpunkt des sektoralen IDPs antwortet – nach positiver Validierung der Anfrage – mit einem AUTHORIZATION_CODE. Das Authenticator-Modul nimmt den AUTHORIZATION_CODE und leitet diesen an den Authorization-Server bzw. an das Anwendungsfrontend weiter. Durch Übergabe des AUTHORIZATION_CODE erhält der Authorization-Server bzw. Anwendungsfrontend am Token-Endpunkt das ID_TOKEN und ACCESS_TOKEN (siehe auch 7.1.2 Flow-Diagramm App-App-Flow ). 

Schnittstellen des Authenticator-Moduls sind diejenigen, an welchen es Anfragen durch das Anwendungsfrontend oder Web-Frontend empfängt und jene, welche das Authenticator-Modul selbst verwendet, um mit dem Authorization-Endpunkt des sektoralen IDPs in Kontakt zu treten.

Abbildung 5 Systemkontext Authenticator-Modul

Hinweis: Handelt es sich um eine dem sektoralen IDP bekannte Anwendung (z.B. durch direkte Registerung eines Kassendienstes im Rahmen der A_23044) ist es zulässig dem Nutzer nur das Annehmen/Ablehnen aller geforderten scopes anzubieten.

Hinweis 1: Die erfolgte Zustimmung des Nutzers darf gespeichert werden und weitere Abfragen können entfallen.

Hinweis 2: Stellt der Anbieter des sektoralen Identity Provider das Authenticator-Modul nicht als eigene Anwendung, sondern z. B. über ein SDK für die Integration in andere Anwendungen zur Verfügung, so muss er lediglich die Schnittstellen zur Anzeige des "user_consent" bereitstellen.

Hinweis: Stellt der Anbieter des sektoralen IDP das Authenticator-Modul als SDK zur Verfügung (z.B. für die Integration in die kasseneigenen Apps) so sind A_23051 und A_22277-01 unwirksam. Das sollte dann in der Anbietererklärung zum Ausdruck kommen. Eine Notwendigkeit zur Prüfung der integrierenden Apps ist nicht gegeben.

Hinweis: Die Anforderung orientiert sich an Prüfaspekt 11 (Resilienz) der TR-03161 des BSI. 

Hinweis: Der Anbieter des IDP kann bei Sicherheitsbedenken von A_23203 abweichend Betriebssystemversionen ausschließen.

Der Datentyp "Device_Type" wird perspektivisch zur Übertragung von Informationen über einen Gerätetyp vom Authenticator-Modul zum sektoralen IDP verwendet. Der Datensatz wird vom Authenticator-Modul produziert und soll dem sektoralen IDP dazu dienen, TI-Weite Vorgaben zur Zulässigkeit von mobilen Endgeräten bei der Authentisierung umzusetzen. Der Datentyp umfasst die Elemente des folgenden Schemas:

Tabelle 8 : Schema Datentyp "Device_Type"

Hinweis: Die in Tabelle Schema Datentyp "Device_Type" aufgeführten Parameter sind nach aktuellem Kenntnisstand für eine Geräteprüfung notwendig. Die Tabelleninhalte können sich in späteren Releases aufgrund neuer Erkenntnisse oder geänderter sicherheitstechnischer Anforderungen ändern. 

5.2 Single-Sign-On (SSO) auf Anwendungsebene

Verwendet ein Nutzer innerhalb einer Anwendung mehrerer TI-Fachdienste, so möchte er sich nur einmalig authentisieren. Die Verwendung mehrerer Fachdienste nach einmaliger Authentisierung innerhalb einer Anwendung ist ein Single-Sign-On auf Anwendungsebene.    

Ein Beispiel für die Verwendung von SSO auf Anwendungsebene:

Der Nutzer bewegt sich in der APP seinem ePA-FdV (i.d.R. in der App seiner Krankenkassen). Neben den kassenspezifischen Funktionen bietet die APP auch Fachdienste der TI-Föderation wie ePA und TIM an. Möchte der Nutzer einen Fachdienst der TI-Föderation in der APP nutzen, so muss er sich gegenüber des sektoralen IDP der Krankenkasse authentisieren. Der Anwender möchte diesen Authentisierungsablauf nur einmal (z.B. beim Start der Anwendung) durchführen müsse (SSO auf Anwendungsebene).

5.2.1 Rahmenbedingungen

Unter folgenden Rahmenbedingungen ist ein Single-Sign-On möglich:

• Ein SSO erstreckt sich ausschließlich über die TI-Fachdienste, die innerhalb eines Anwendungskontextes (ePA-FdV) vom Nutzer aufgerufen werden können.
• Das Authenticator-Modul des sektoralen IDP, über welchen der Nutzer sich authentisiert, muss ebenfalls Teil des Anwendungskontextes sein.
• Soll ein Fachdienst SSO innerhalb des Anwendungskontextes nutzen, so muss sein Frontend im Ablauf der Nutzerauthentisierung eine vom Authenticator-Modul bereitgestellt API-Schnittstelle aufrufen.
• Der Nutzer muss sich im Anwendungskontext mindestens einmal aktiv auf dem Vertrauensniveau "gematk-loa-high" authentifizieren.
• Für die Laufzeit eines Anwendungskontextes (Laufzeit der Anwendung) wird vom sektoralen IDP eine SessionID generiert.
• Zu einem Anwendungskontext wird vom Authenticator-Modul ein Schlüsselpaar und der SessionID zugeordnet. 
• Der Nutzer muss innerhalb des Anwendungskontextes konfigurieren können, welcher Fachdienst an einem SSO-Verfahren teilnehmen darf. 

Verwenden alle Mandanten des Herstellers eines sektoralen IDP eine separate Authenticator-App, so ist ein SSO nicht umsetzbar. In diesem Fall müssen die Anforderungen des Kapitel 5.2 nicht umgesetzt werden.

5.2.2 Ablaufbeschreibung

Beim Single-Sign-On (SSO) authentisiert sich der Nutzer spätestens beim Start des ersten TI-Fachdienstes der Anwendung (i. d. R. auf gematik-ehealth-loa-high) einmalig gegenüber dem sektoralen IDP. Anschließend kann der Nutzer TI-Fachdienste und Funktionen innerhalb der Anwendung ohne weitere Interaktion  zur Authentisierung für einen festgelegten Zeitraum nutzen. Der sektorale IDP stellt dabei sicher, dass jeder TI-Fachdienst sein eigenes ID_TOKEN erhält.

Die fehlende Interaktion des Nutzers bei der Authentifizierung je TI-Fachdienst erfordert für ein SSO-Verfahren zusätzliche Sicherungsmaßnahmen zur Gewährleistung der Widerstandsfähigkeit gegen das des vom Fachdienst geforderten Angriffspotentials.

Die Abbildung "Beispiel für SSO bei Ausführung ePA Client Modul mit aktiver und E-Rezept Client Modul ohne aktive Nutzerauthentisierung aus dem ePA-FdV" und die Tabelle "Ablauf der Aufrufe der TI-Client Module aus dem ePA-FdV" zeigen einen mit dem BSI abgestimmten Ablauf anhand zweier im ePA-FdV enthalten TI-Client Module.

Abbildung 7: Beispiel für SSO bei Ausführung ePA Client Modul mit aktiver und E-Rezept Client Modul ohne aktive Nutzerauthentisierung aus dem ePA-FdV

Tabelle 9 : Ablauf der Aufrufe der TI-Client Module aus dem ePA-FdV 

Hinweis: Weitere Parameter des OAuth2 Authorization Code Flow mit PKCE wie 'client_id','state','code_challenge' oder 'code_verifier'

werden konform zu https://datatracker.ietf.org/doc/html/rfc7636 bzw. https://datatracker.ietf.org/doc/html/rfc6749#section-4.1 in den jeweiligen Requests/Responses übertragen.

Hinweis: Die Information, ob der Nutzer dem SSO-Verfahren für einen Fachdienst zugestimmt hat, kann über technische unterschiedliche Implementierungen dem Authenticator Modul zur Verfügung gestellt werden.

5.3 Verwaltung eGK

Das Authenticator-Modul des sektoralen IDP stellt im Rahmen der Anwendungsübergreifenden GesundheitsID den einzigen Kontaktpunkt zur elektronischen Gesundheitskarte dar. Daher soll dieses anstelle von Anwendungsspezifischen Funktionen im Rahmen des ePA und/oder E-Rezept Frontend eine Möglichkeit zur Verwaltung der eGK-PIN bereitstellen.

5.3.1 PIN der eGK ändern

Mit diesem Anwendungsfall kann der Nutzer das Geheimnis der PIN einer eGK ändern.

Abbildung 6 : Aktivitätsdiagramm "PIN der eGK ändern"

5.3.2 PIN der eGK entsperren

Mit diesem Anwendungsfall kann der Nutzer den gesperrten PIN einer eGK mit der PUK entsperren.

Abbildung 7 : Aktivitätsdiagramm "PIN der eGK entsperren"

6 Anhang A – Verzeichnisse

6.1 Abkürzungen

6.2 Glossar

Das Glossar wird als eigenständiges Dokument (vgl. [gemGlossar]) zur Verfügung gestellt.

6.3 Abbildungsverzeichnis

6.4 Tabellenverzeichnis

6.5 Referenzierte Dokumente

6.5.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur TI.

6.5.2 Weitere Dokumente

7 Anhang B - Abläufe

7.1 App-App-Flow

Der App-App-Flow beschreibt die Einzelschritte für die Authentifizierung eines Nutzers im Rahmen eines Fachdienstes wobei der Fachdienst eine App ist, welche auf demselben Gerät wie die Authenticator-App installiert ist.

7.1.1 Vorbedingungen App-App-Flow

• Registrierung des App-Link/Universal-Link für das Frontend auf dem Gerät des Nutzers (auf redirect Adresse des Fachdienstes) - oder einreichen über Web.
• Registrierung des App-Link/Universal-Link für das Authenticator-Modul des IDP auf dem Gerät des Nutzers (auf Adresse des IDP) - oder anfragen über Web.
• Aktueller Signaturschlüssel des Federation Master ist bekannt und vertrauenswürdig bei IDP und Fachdienst eingebracht worden.

7.1.2 Flow-Diagramm App-App-Flow

Abbildung 8 : App-App-Flow

7.1.3 Ablaufbeschreibung App-App-Flow

Tabelle 14 : Ablaufbeschreibung App-App-Flow

7.1.4 Detailinformationen zum App-App-Flow

Abruf der Schlüssel des Federation Master

Dazu wird das selbst signierte Entity Statement des Federation Master abgerufen und gegen den vorher bekanntgemachten Signaturschlüssel des Federation Master geprüft.

Response auf GET an die Adresse "http://master0815.de/.well-known/openid-federation"

HTTP 200 mit Content-Type: application/entity-statement+jwt

Folgende Werte müssen im Header des selbst signierten Entity Statement des Federation Master auftauchen:

Tabelle 15 : Header Entity Statement des Federation Master

Folgende Werte müssen im Body des selbst signierten Entity Statement des Federation Master enthalten sein:

Tabelle 16 : Body Entity Statement des Federation Master

IDP-Liste

Es wird vom Nutzer einer Anwendung der Telematikinfrastruktur erwartet, dass dieser die Institution kennt, welche seine Identität herausgibt (bei einem Versicherten wäre dies z. B. seine Krankenkasse).

Tabelle 17 : Beispiel vorliegender Identitätsdaten

Begriff	Erläuterung	Beispiel
Identität	Von Institution gemanagte ID

Jede Kasse wird als eigener IDP mit eigenen Endpunkten und Entity Statements geführt. Ein Dienstleister kann dahinter aber denselben Dienst stehen haben und die Kassen als Mandanten pflegen. Damit bleibt es auch möglich für die Kasse bei fehlender Installation auf einer eigenen Infoseite zu ihren Apps zu verweisen. Kassen geben die Freigabe für ihren Eintrag in der Föderation frei.

Die Liste der Kassen wird aus der Föderation generiert und am Federation Master zum Abruf bereitgestellt. Die Integrität der Liste wird mittels Signatur über einen Schlüssel aus dessen Keyset sichergestellt.

(0-a) Anwendungsfrontend fragt die Liste aller IDPs ab

Das Anwendungsfrontend fragt die Liste aller IDPs ab, oder der Authorization-Server lässt diese Liste selbst im Frontend anzeigen (Webview). Die Kommunikation zwischen Anwendungsfrontend und Fachdienst ist anwendungsspezifisch und wird hier nicht weiter spezifiziert.

(0-b) Authorization-Server antwortet dem Anwendungsfrontend mit der Liste aller IDPs

Der Authorization-Server antwortet dem Anwendungsfrontend mit der Liste aller IDPs oder der Authorization-Server lässt diese Liste selbst im Frontend anzeigen. Diese Liste wird als JWS formatiert und mittels eines Schlüssels des Federation Master signiert. Das Frontend lässt den Nutzer die Wahl seines IDP (seiner Kasse) treffen oder diese Auswahl erfolgt über eine Webseite des Fachdienstes. Die notwendigen Informationen können aus den Entity Statements gelesen werden. Das signierte JWS der IDP-Liste hat folgende Inhalte:

Tabelle 18 : Attribute der IDP-Liste

Folgende Werte müssen im Header der vom Federation Master signierten IDP-Liste auftauchen:

(1) Authorization Request von Anwendungsfrontend zum Authentication-Endpunkt (Auth EP) des Authorization-Servers des Fachdienstes

Das Anwendungsfrontend sendet ein HTTP-GET an den Authorization-Server des Fachdienstes. Die folgenden GET-Parameter werden im query string verwendet:

Tabelle 19: Authorization Request von Anwendungsfrontend zum Authorization-Server

{"id_token":{"amr":<pre>            {"essential": true,
             "values": ["urn:telematik:auth:eGK"]},

claims=%7B%22id_token%22%3A%7B%22amr%22%3A%7B%22essential
%22%3Atrue,%22values%22%3A%5B%22urn%3Atelematik%3Aauth
%3AeGK%22%5D%7D,%22email%22%3A%7B%22essential%22%3Atrue
%7D%7D%7D

Hinweis: Da ein Wechsel des Email-Provider durch den Nutzer jederzeit möglich ist und die Email-Adresse bei sektoralen IDPs nicht für alle Versicherten zuverlässig und vorhanden vorausgesetzt werden kann, wird von der Verwendung der Email als 'essential claim' abgeraten, um keine Nutzer ungewollt auszuschließen. Fachdienste sind angehalten, ggf. angeforderte Email-Adressen selbständig vor deren Verwendung auf Gültigkeit zu überprüfen.

(1-a) Falls der Authorization-Server des Fachdienstes das Entity Statement des IDP noch nicht kennt, lädt er dies herunter

Request:

HTTP-GET 

Adresse: "https://idp4711.de/.well-known/openid-federation"

(1-b) Der IDP sendet sein Entity Statement zurück

Der Authorization-Server verifiziert die Signatur des Entity Statement gegen einen Schlüssel aus dem Entity Statement des Federation Master über diesen issuer (OpenID Connect Federation 1.0 (section-8.2) ).

Response:

HTTP 200 mit Content-Type: application/entity-statement+jwt

Folgende Werte müssen im Header des selbst signierten Entity Statement des sektoralen IDP auftauchen:

Tabelle 20 : Header Entity Statement des sektoralen IDP

Folgende Werte müssen im Body selbst signierten Entity Statement des sektoralen IDPs enthalten sein:

Tabelle 21 : Body Entity Statement des sektoralen IDP

signed_jwks_uri

Ablageort für weitere Schlüssel des IDP etwa die zur Signatur seiner Token. Wenn eine signed_jwks_uri im Entity Statement angegeben ist, müssen auch diese Schlüssel importiert werden.

Die Auflösung der signed_jwks_uri erfolgt dabei mittels HTTP GET Request. 

Response auf GET an die Adresse "https://idp4711.de/jws.json"

HTTP 200 mit Content-Type: application/jwk-set+json

Folgende Werte müssen im Header des selbst signierten KeySet des sektoralen IDP auftauchen:

Tabelle 22 : Header des KeySet des sektoralen IDP

Folgende Werte müssen im Body enthalten sein:

Tabelle 23 : Body des KeySet des sektoralen IDP

(1-c) Der Authorization-Server des Fachdienstes ruft das Entity Statement zum IDP beim Federation Master ab

Request:

HTTP-GET 

Adresse: "http://master0815.de/federation_fetch_endpoint"

HTTPS GET Request an den federation_fetch_endpoint aus dem Entity Statement des Federation Master mit dem folgenden Parameter:

Tabelle 24 : Parameter HTTPS GET Request vom Authorization-Server des Fachdienstes an den Federation Master API zur Abfrage des Entity Statements über den sektoralen IDP

(1-d) Der Federation Master sendet sein Entity Statement über den angefragten sektoralen IDP zurück

Response:

HTTP 200 mit Content-Type: application/entity-statement+jwt

Folgende Werte müssen im Header des Entity Statement des Federation Master über den sektoralen IDP enthalten sein:

Tabelle 25 : Header HTTP-Response an den Authorization-Server des Fachdienstes vom Federation Master zum Entity Statement des sektoralen IDP

Folgende Werte müssen im Body des Entity Statement des Federation Master über den sektoralen IDP enthalten sein:

Tabelle 26 : Body HTTP-Response an den Authorization-Server des Fachdienstes vom Federation Master zum Entity Statement des sektoralen IDP

Als Ergebnis des Schritts (d2-d) kennt der Authorization-Server des Fachdienstes kennt die öffentlichen Schlüssel für Signaturen des IDP.

(2) Der Authorization-Server des Fachdienstes sendet einen Pushed Authorization Request (PAR) an den Authentication-Endpunkt (Auth EP) des sektoralen IDP

Der innere Flow startet mit dem Pushed Authorization Request (rfc9126) des Fachdienstes an den sektoralen IDP. Als Client Authentisierung wird self_signed_tls_client_auth verwendet (siehe OpenID Connect Federation 1.0 (section-10.1)).

Anmerkung: Dies passiert als Folge des Authorization Request des Anwendungsfrontends.

HTTP-POST

Der Authorization Request des Fachdienstes zum sektoralen IDP enthält die folgenden Parameter:

Tabelle 27 : Parameter Pushed Authorization Request 

code

  Zu den scopes und claims bzgl. der Identitäten für Versicherte siehe A_22989-01 in Kapitel 4.2.4.2. 

(2-a) Falls der IDP das Entity Statement des Authorization-Servers des Fachdienstes noch nicht kennt, lädt er dies herunter

Request:

HTTP-GET 

Adresse: "https://Fachdienst007.de/.well-known/openid-federation"

(2-b) Der Authorization-Server des Fachdienstes sendet sein Entity Statement zurück und der IDP registriert ihn als Client (Automatic Registration)

Der IDP verifiziert die Signatur des Entity Statement über einen Dienst gegen einen Schlüssel aus dem Entity Statement des Federation Master gemäß den Standards:

• OpenID Connect Federation 1.0 (section-10.1) 
• OpenID Connect Federation 1.0 (section-8.2)

Response:

HTTP 200 mit Content-Type: application/entity-statement+jwt

Folgende claims müssen im Header des selbst signierten Entity Statement des Fachdienstes auftauchen:

Tabelle 28 : Header des Entity Statement des Fachdienstes

Folgende Body-claims müssen im selbst signierten Entity Statement des Fachdienstes enthalten sein:

Tabelle 29 : Body des Entity Statement des Fachdienstes

Weitere Informationen zu den Inhalten zur Client-Registrierung finden sich in den Spezifikationen zum OIDC Standard:

• OpenID Connect Federation 1.0 (section-3.1) 
• OAuth 2.0 Dynamic Client Registration Protocol (section-2) 
• OpenID Connect Dynamic Client Registration 1.0
• The OAuth 2.0 Authorization Framework (section-3.3) 

signed_jwks_uri

Ablageort für weitere Schlüssel des Fachdienstes etwa die zur TLS Client Schlüssel und Zertifikate (x5c, use = sig) oder für die Verschlüsselung der ID_Token (use = "enc").

Wenn eine signed_jwks_uri im Entity Statement angegeben ist müssen auch diese Schlüssel importiert werden.

Die Auflösung der signed_jwks_uri erfolgt dabei mittels HTTP GET Request. 

Response auf GET an die Adresse "https://idp4711.de/jws.json"

HTTP 200 mit Content-Type: application/jwk-set+json

Folgende Werte müssen im Header des selbst signierten KeySet des Fachdienstes auftauchen:

Tabelle 30 : Header des KeySet des Fachdienstes

Folgende Werte müssen im Body enthalten sein:

Tabelle 31 : Body des KeySet des Fachdienstes

(2-c) Abruf des Entity Statement zum Fachdienst beim Federation Master

Request:

HTTP-GET 

Adresse: "http://master0815.de/federation_fetch_endpoint"

HTTPS GET Request an den federation_fetch_endpoint aus dem Entity Statement des Federation Master mit dem folgenden Parameter:

Tabelle 32 : Parameter HTTPS GET Request an Federation Master API

(2-d) Der Federation Master sendet sein Entity Statement über den Fachdienst zurück

Response:

HTTP 200 mit Content-Type: application/entity-statement+jwt

Folgende Werte müssen im Header zum Entity Statement des Federation Master über den Fachdienst enthalten sein:

Tabelle 33 : Header zum Entity Statement des Federation Master über den Fachdienst

Folgende Werte müssen im Body des Entity Statement des Federation Master über den Fachdienst enthalten sein:

Tabelle 34 : Body zum Entity Statement des Federation Master über den Fachdienst

Als Ergebnis des Schritts (2-d) kennt der IDP die öffentlichen Keys des Fachdienstes für Verschlüsselung und Authentisierung.

(3) Der Authentication-Endpunkt (Auth EP) des sektoralen IDP antwortet dem AS des Fachdienstes mit einer Request URI

Zuvor verifiziert der IDP das TLS CLientzertifkat gegen einen Schlüssel aus dem Entity Statement des Fachdienstes.
Response:

HTTP 201 mit Content-Type: application/json

Tabelle 35 : Parameter der HTTP-Response

Diese URI wird als redirect an das Anwendungsfrontend gesendet um über das Authenticator-Modul den IDP zu erreichen.

(4) Der Authorization-Server des Fachdienstes antwortet dem Frontend mit einem redirect und seiner Request URI

HTTP-302,

Mit mindestens den folgenden HTTP-Header Elementen:

• Location

Die Location setzt sich zusammen aus:

<target_url><authorization request IDP Dienst zu sektoralem IDP>

Die target_url entspricht dabei der Adresse des Authorization-Endpunktes des sektoralen IDP entsprechend dem Entity Statement, welche auf dem Gerät auf das Authenticator-Modul weitergeleitet wird.

Der Request des Fachdienstes AS zum sektoralen IDP enthält dabei die folgenden Parameter:

Tabelle 36 : Request Parameter des Fachdienstes zum sektoralen IDP

(5) Das Anwendungsfrontend sendet den Authentication Request an die URI des IDP und leitet ihn somit an das Authenticator-Modul weiter

Das Anwendungsfrontend sendet ein HTTP-GET an den Authorization-Endpunkt des sektoralen IDP.

Die GET-Parameter entsprechen dem Request des Fachdienstes aus Schritt 4.

Das Authenticator-Modul des sektoralen IDP fängt diesen Request dadurch, dass er diese Adresse für App2App Kommunikation im Betriebssystem registriert hat.

(6) Das Authenticator-Modul leitet den Authentication Request an den IDP weiter (proprietär)

Die Schritte zur Nutzer-Authentifizierung und zur Erstellung des AUTHORIZATION_CODE durch den IDP sind anwendungsspezifisch und werden hier nicht weiter spezifiziert.

(7) Der Authorization-Endpunkt des sektoralen IDP antwortet dem Authenticator-Modul mit einem Redirect zum Fachdienst (proprietär)

Beispielsweise

HTTP-302,

Mit mindestens den folgenden HTTP-Header Elementen:

• Location

Die Location setzt sich zusammen aus:

<uri_Fachdienst_AS>?code=<AUTHORIZATION_CODE_IDP>&state=<state_Fachdienst>

Tabelle 37 : Parameter des Redirect-Request

(8) Das Authenticator-Modul des IDP ruft über einen App-Link bzw. Universal-Link entsprechend der Redirect-URL das Anwendungsfrontend auf und übergibt den AUTHORIZATION_CODE

Der App-Link bzw. Universal-Link Aufruf des Authenticator-Modul ist anwendungsspezifisch und wird hier nicht weiter spezifiziert.

Das Anwendungsfrontend fängt diesen Request dadurch, dass er diese Adresse für App2App Kommunikation im Betriebssystem registriert hat.

(9) Das Anwendungsfrontend leitet den AUTHORIZATION_CODE an den Authorization-Server des Fachdienstes

HTTP-POST (Content-Type: application/x-www-form-urlencoded) nach uri_Fachdienst_AS

Der Request des enthält dabei die folgenden Parameter:

Tabelle 38 : Parameter des POST-Request

(10) Der Authorization-Server reicht den AUTHORIZATION_CODE(IDP) und den CODE_VERIFIER beim Token-Endpunkt des IDP ein

HTTP POST mit Content-Type: application/x-www-form-urlencoded

Die folgenden Parameter werden im payload verwendet: 

Tabelle 39 : HTTP-POST Parameter für AUTHORIZATION_CODE und den CODE_VERIFIER

(11) Der Authorization-Server erhält vom Token-Endpunkt des IDP einen ID_TOKEN und ACCESS_TOKEN mit den gewünschten claims, der mit dem öffentlichen Schlüssel aus der Registrierung verschlüsselt ist

Der Authorization-Server des Fachdienstes entschlüsselt den ID_TOKEN und verifiziert anschließend dessen Signatur. Damit endet der innere Flow.

HTTP-200:

• Content-Type=application/json
• Cache-Control=no-store
• Pragma=no-cache.

Die JSON-Struktur sieht so aus:

{

"access_token": <ACCESS_TOKEN>, 

"id_token": <ID_TOKEN>,

"token_type": "Bearer",

"expires_in": 300, (Gültigkeit des ACCESS_TOKEN in Sekunden, The OAuth 2.0 Authorization Framework (section-4.2.2))

}

Der ACCESS_TOKEN wird ignoriert.

Der Encryption Header-claims des ID_TOKEN sieht dabei wie folgt aus:

Tabelle 40 : Header-claims des ID_TOKEN des sektoralen IDP

Signature Header-claimsdes ID_TOKEN sind genau die folgenden:

Tabelle 41 : Signature Header-claims des ID_TOKEN des sektoralen IDP

Die Body-claims für den ID_TOKEN des sektoralen IDP sind Beispielsweise die folgenden:

Tabelle 42 : Body-claims für den ID_TOKEN des sektoralen IDP

(12) Der Authorization-Server des Fachdienstes erstellt ein AUTHORIZATION_CODE und sendet diesen an das Anwendungsfrontend zum Einreichen beim Token Endpunkt

Beispielsweise

HTTP-302,

Mit mindestens den folgenden HTTP-Header Elementen:

• Location

Die Location setzt sich zusammen aus:

<https://Fachdienst007.de/Token>?code=<authorization code AS>&state=<state Frontend>

Tabelle 44 : Parameter des Redirect-Request

(13) Anwendungsfrontend übergibt dem Authorization-Server den AUTHORIZATION_CODE sowie den CODE_VERIFIER

HTTP POST mit Content-Type: application/x-www-form-urlencoded

Die folgenden Parameter werden im payload verwendet:

Tabelle 45 : Parameter HTTP-POST

(14) Anwendungsfrontend erhält ACCESS_TOKEN und REFRESH_TOKEN mit den notwendigen Daten vom Authorization-Server des Fachdienstes

HTTP-200:

• Content-Type=application/json
• Cache-Control=no-store
• Pragma=no-cache.

Die JSON-Struktur sieht so aus:

{

"access_token": <ACCESS_TOKEN>, 

"refresh_token": <REFRESH_TOKEN>,

"token_type": "Bearer",

"scope": "e-rezept", 

"expires_in": 300, (Gültigkeit des ACCESS_TOKEN in Sekunden, The OAuth 2.0 Authorization Framework (section-4.2.2))

}

(15) Das Anwendungsfrontend greift auf die Fachdienst API zu und übergibt dabei das ACCESS_TOKEN

Die Kommunikation zwischen Anwendungsfrontend und Fachdienst ist anwendungsspezifisch und wird hier nicht weiter spezifiziert.

7.2 Web-App-Flow

Der Web-App-Flow beschreibt die Einzelschritte für die Authentifizierung eines Nutzers im Rahmen einer Web-Anwendung, welche im Browser desselben Geräts ausgeführt wird, auf dem auch die Authenticator-App installiert ist.

7.2.1 Vorbedingungen Web-App-Flow

• Registrierung des Fachdienstes als Relying Party (RP) beim Federation Master.
• Registrierung des App-Link/Universal-Link für das Authenticator-Modul des IDP auf dem Gerät des Nutzers (auf Adresse des IDP) - oder anfragen über Web.
• Aktueller Signaturschlüssel des Federation Master ist bekannt und vertrauenswürdig bei IDP und Fachdienst eingebracht worden.
• Sektorale IDP ist Teil des TI-Vertrauensraums und beim Federation Master registriert.
• Der Fachdienst besitzt ein Web-Backend welches Anwendungslogik realisiert.

7.2.2 Flow-Diagramm Web-App-Flow

Abbildung 9 : Web-App-Flow

7.2.3 Ablaufbeschreibung Web-App-Flow

Tabelle 46 : Ablaufbeschreibung Web-App-Flow

7.2.4 Detailinformationen zum Web-App-Flow

(1) Authorization Request von Web-Backend zum Authentication-Endpunkt (Auth ES) des Authorization-Servers des Fachdienstes

Die Kommunikation zwischen Web-Frontend und Web-Backend ist anwendungsspezifisch. Das Web-Backend des Fachdienstes sendet einen Request an den Authorization-Server des Fachdienstes. Dieser Request ist ebenfalls anwendungsspezifisch. Damit der weitere Ablauf OIDC konform und weitest gehend identisch zum App-zu-App Flow ablaufen kann, muss der Request einigen Festlegungen genügen.

Das Web-Backend sendet ein HTTP-GET an den AS des Fachdienstes.

Die folgenden GET-Parameter werden im query string verwendet:

Tabelle 47 : Parameter des GET-Requests

"digaxy"

(1-a) Falls der Authorization-Server des Fachdienstes das Entity Statement des IDP noch nicht kennt, lädt er dies herunter

Request analog App-zu-App Flow (1a).

(1-b) Der IDP sendet sein Entity Statement zurück

Response analog App-zu-App Flow (1b)

signed_jwks_uri

Die Werte sind analog zu App-zu-App Flow (1-signed_jwks_uri).

(1-c) Der Authorization-Server des Fachdienstes ruft das Entity Statement zum IDP beim Federation Master ab

Request analog App-zu-App Flow (1c).

(1-d) Der Federation Master sendet sein Entity Statement über den angefragten sektoralen IDP zurück

Response analog App-zu-App Flow (1d).

(2) Der Authorization-Server des Fachdienstes sendet ein Pushed Authorization Request an den Authentication-Endpunkt (Auth ES) des sektoralen IDP

HTTP-POST analog App-zu-App Flow (2) inclusive TLS Clientauthentisierung.

(2-a) Falls der IDP das Entity Statement des Authorization-Servers des Fachdienstes noch nicht kennt, lädt er dies herunter

Request analog zu App-zu-App Flow (2a).

(2-b) Der Authorization-Server des Fachdienstes sendet sein Entity Statement zurück und der IDP registriert ihn als Client

Response analog zu App-zu-App Flow (2b).

signed_jwks_uri

Die Werte sind analog zu App-zu-App Flow (2b-signed_jwks_uri).

(2-c) Abruf des Entity Statement zum Fachdienst beim Federation Master

Request analog zu App-zu-App Flow (2c).

(2-d) Der Federation Master sendet sein Entity Statement über den Fachdienst zurück

Response analog zu App-zu-App Flow (2d).

(3) Der Authentication-Endpunkt (Auth EP) des sektoralen IDP antwortet dem AS des Fachdienstes mit einer Request URI

Response analog zu App-zu-App Flow (3).

(4) Der Authorization-Server des Fachdienstes antwortet dem Frontend mit einem redirect und seiner Request URI

Abweichend vom App/App-Flow läuft der Redirect zum Web-Frontend.

Redirect analog zu App-zu-App Flow (4).

(5) Das Web-Frontend sendet den Authentication Request an die URI des IDP und leitet ihn somit an das Authenticator-Modul weiter

HTTP-GET analog zu App-zu-App Flow (5).

(6) Das Authenticator-Modul leitet den Authentication Request an den IDP weiter (proprietär)

Die Schritte zur Nutzer-Authentifizierung und zur Erstellung des AUTHORIZATION_CODE durch den IDP sind anwendungsspezifisch und werden hier nicht weiter spezifiziert.

(7) Der Authorization-Endpunkt des sektoralen IDP antwortet dem Authenticator-Modul mit einem Redirect zum Fachdienst (proprietär)

Redirect analog zu App-zu-App Flow (7).

(8) Das Authenticator-Modul des IDP ruft über die Redirect-URL den Authorization-Server des Fachdienstes auf und übergibt den AUTHORIZATION_CODE

Abweichend vom App/App Flow führt das Authenticator-Modul des IDP den Redirect zum Authorization-Server des Fachdienstes aus und übergibt den AUTHORIZATION_CODE. Der Request wird mit einem HTTP-OK quittiert.

HTTP-POST analog zu App-zu-App Flow (9).

(9) Der Authorization-Server reicht den AUTHORIZATION_CODE und den CODE_VERIFIER beim Token-Endpunkt des IDP ein

HTTP POST analog zu App-zu-App Flow (10) inclusive TLS Clientauthentisierung.

(10) Der Authorization-Server erhält vom Token-Endpunkt des IDP einen ID_TOKEN und ACCESS_TOKEN mit den gewünschten scopes, der mit dem öffentlichen Schlüssel aus der Registrierung verschlüsselt ist

Response analog zu App-zu-App Flow (11).

(11) Der Authorization-Server des Fachdienstes reicht das ACCESS_TOKEN und REFRESH_TOKEN an das Web-Backend der Anwendung weiter

HTTP-200:

• Content-Type=application/json
• Cache-Control=no-store
• Pragma=no-cache.

Die JSON-Struktur sieht so aus:

{

"access_token": <ACCESS_TOKEN>, 

"refresh_token": <REFRESH_TOKEN>,

"token_type": "Bearer",

"scope": "e-rezept", 

"expires_in": 300, (Gültigkeit des ACCESS_TOKEN in Sekunden, [The OAuth 2.0 Authorization Framework#section 4.2.2])

}

(12) Kommunikation Web-Frontend, Web-Backend der Anwendung und Fachdienst-API

Das Web-Backend persistiert ACCESS_TOKEN und REFRESH_TOKEN. Das Web-Backend benötigt diese für die autorisierte Kommunikation mit dem Fachdienst-API. Die Kommunikation zwischen Web-Frontend und Web-Backend ist implementierungsspezifisch. ACCESS_TOKEN und/oder REFRESH_TOKEN werden nicht an das Frontend weitergereicht.

Das Web-Backend verwendet das ACCESS_TOKEN für die Kommunikation mit dem Fachdienst-API. Das Fachdienst-API prüft den ACCESS_TOKEN bevor Anfragen entsprechend quittiert werden.

GET /resource/1 HTTP/1.1 Host: example.com Authorization: Bearer <ACCESS_TOKEN>

7.3 Zwei-Geräte-Flow

Der Zwei-Geräte-Flow beschreibt die Einzelschritte für die Authentifizierung eines Nutzers im Rahmen eines Fachdienstes wobei der Fachdienst eine App oder Web-Anwendung ist, welche auf einem anderen Gerät als die Authenticator-App ausgeführt wird.

7.3.1 Vorbedingungen Zwei-Geräte-Flow

• Registrierung des Fachdienstes als Relying Party (RP) beim Federation Master
• Registrierung des App-Link/Universal-Link für das Authenticator-Modul des IDP auf dem Gerät des Nutzers (auf Adresse des IDP) - oder anfragen über Web.
• Aktueller Signaturschlüssel des Federation Master ist bekannt und vertrauenswürdig bei IDP und Fachdienst eingebracht worden.
• Sektorale IDP ist Teil des TI-Vertrauensraums und beim Federation Master registriert.
• Der Fachdienst besitzt ein Web-Backend welches Anwendungslogik realisiert.
• Authenticator-Modul des IDP (App) läuft auf einem anderen Gerät als der Fachdienst (z. B. App → Smartphone, Anwendung → PC-Browser)

7.3.2 Flow-Diagramm Zwei-Geräte-Flow

Abbildung 10 : Zwei-Geräte-Flow

7.3.3 Ablaufbeschreibung Zwei-Geräte-Flow

Tabelle 48 : Ablaufbeschreibung Zwei-Geräte-Flow

7.3.4 Detailinformationen zum Zwei-Geräte-Flow

(1) Authorization Request von Web-Backend zum Authentication-Endpunkt (Auth ES) des Authorization-Servers des Fachdienstes

• Web-Anwendung → Request analog Web-zu-App Flow (1).

(1-a) Falls der Authorization-Server des Fachdienstes das Entity Statement des IDP noch nicht kennt, lädt er dies herunter

Request analog zu App-zu-App Flow (1a).

(1-b) Der IDP sendet sein Entity Statement zurück

Response analog zu App-zu-App Flow (1b).

signed_jwks_uri

Die Werte sind analog zu App-zu-App Flow (1-signed_jwks_uri).

(1-c) Der Authorization-Server des Fachdienstes ruft das Entity Statement zum IDP beim Federation Master ab

Request analog zu App-zu-App Flow (1c).

(1-d) Der Federation Master sendet sein Entity Statement über den angefragten sektoralen IDP zurück

Response analog zu App-zu-App Flow (1d).

(2) Der Authorization-Server des Fachdienstes sendet ein Pushed Authorization Request an den Authentication-Endpunkt (Auth ES) des sektoralen IDP

HTTP-POST analog zu App-zu-App Flow (2) inclusive TLS Clientauthentisierung.

(2-a) Falls der IDP das Entity Statement des Authorization-Servers des Fachdienstes noch nicht kennt, lädt er dies herunter

Request analog zu App-zu-App Flow (2a):

(2-b) Der Authorization-Server des Fachdienstes sendet sein Entity Statement zurück und der IDP registriert ihn als Client

Response analog zu App-zu-App Flow (2b).

signed_jwks_uri

Die Werte sind analog zu App-zu-App Flow (2b-signed_jwks_uri).

(2-c) Abruf des Entity Statement zum Fachdienst beim Federation Master

Request analog zu App-zu-App Flow (2c).

(2-d) Der Federation Master sendet sein Entity Statement über den Fachdienst zurück

Response analog zu App-zu-App Flow (2d).

(3) Der Authentication-Endpunkt (Auth EP) des sektoralen IDP antwortet dem AS des Fachdienstes mit einer Request URI

Response analog zu App-zu-App Flow (3).

(4) Der Authorization-Server des Fachdienstes antwortet dem Web-Backend mit einem redirect und seiner Request URI

Der Authorization-Server antwortet dem Web-Backend mit Request-URI und Client ID zur Weiterleitung über das Anwendungsfrontend an die Adresse des Authenticator des IDP.

(5) Das Web-Backend antwortet dem Frontend mit einem redirect und seiner Request URI

Das Web-Backend leitet den Redirect an das Anwendungsfrontend weiter.

(6) Das Web-Frontend öffnet die URI und damit eine Authentifizierungsseite des IDP

HTTP-GET analog zu App-zu-App Flow (5) - allerdings gibt es in diesem Fall eben kein Authenticator-Modul des sektoralen IDP auf dem Gerät und daher wird unter der Adresse eine Authentifizierungsseite im Browser geöffnet.

(6a-d) Anwender authentifiziert sich nach dem Verfahren des IDP

Der Anwender authentifiziert sich nach dem Verfahren des IDP. Dabei kann als 2. Faktor eine Authenticator-App auf einem 2. Gerät verwendet werden.

Beispielablauf:

6a) IDP Login-Seite im Browser Gerät 1 → Identifikation des Nutzers (möglicherweise/ratsam über ersten Faktor z. B. Name/Passwort)

6b) IDP → Prüfung der Credentials (Optional, wenn 1 Faktor genutzt)

6c) Initiierung des 2. Faktor durch Aufforderung an den Anwender zum Öffnen des Authenticator-Moduls auf einem 2. Gerät oder durch ein push des IDP auf das Gerät mit dem Authenticator-Modul

6d) Authenticator-Modul Gerät 2 → IDP → Abschluss der Authentisierung

Der Nutzer könnte auch einen Code vom IDP gezeigt bekommen im Schritt 6a und tippt/scannt diesem im Authenticator-Modul ein. Auch dies kann eine Kopplung der App zum Prozess beim IDP herstellen. 

Varianten gibt es verschiedene aber es muss klar sein zu welcher Session (Request URI) beim IDP diese Authentisierung gehört.

(7) Der Authorization-Endpunkt des sektoralen IDP antwortet dem Web-Frontend (Browser) mit einem Redirect zum Fachdienst

Die Authentifizierungsseite des Authorization-Endpunktes des sektoralen IDP reagiert und sendet dem Web-Frontend einen Redirect zum Fachdienst und den AUTHORIZATION_CODE.

Redirect analog zu App-zu-App Flow (7).

(8) Das Web-Frontend (Browser) leitet den AUTHORIZATION_CODE an das Web-Backend der Anwendung weiter

Das Anwendungsfrontend gibt die Information mit dem AUTHORIZATION_CODE an das Web-Backend der Anwendung weiter.

(9) Das Web-Backend der Anwendung leitet den AUTHORIZATION_CODE an den Authorization-Server des Fachdienstes

HTTP-POST analog zu App-zu-App Flow (9).

(10) Der Authorization-Server reicht den AUTHORIZATION_CODE und den CODE_VERIFIER beim Token-Endpunkt des IDP ein

HTTP-POST analog zu App-zu-App Flow (10) inclusive TLS Clientauthentisierung.

(11) Der Authorization-Server erhält vom Token-Endpunkt des IDP einen ID_TOKEN und ACCESS_TOKEN mit den gewünschten scopes, der mit dem öffentlichen Schlüssel aus der Registrierung verschlüsselt ist

Response analog zu App-zu-App Flow (11).

(12) Einlösen des ACCESS_TOKEN und Datenabruf

• Web-Anwendung → weiterer Ablauf analog ab Web-zu-App Flow (11).

8 Anhang C - Möglicher Aufbau einer VAU (informativ)

Anhang C trägt informativen Charakter und stellt Möglichkeiten zum Aufbau einer Vertrauenswürdigen Ausführungsumgebung VAU vor. Die Standalone-Lösung (Kapitel 8.1) orientiert sich in weiten Teilen an der Umsetzung der VAU wie es aktuell erfolgreich für das E-Rezept im Einsatz ist. Im Kapitel 8.2 soll perspektivisch ein Umsetzungsvorschlag einer VAU für eine Cloudinfrastruktur erstellt werden. Hier sind allerdings noch grundlegende Vorarbeiten notwendig.

Der Schutzbedarf der durch den sektoralen IDP verarbeiteten Daten und der Zugriff auf personenbezogene medizinische Daten der durch ihn ermöglicht wird erfordert einen spezifischen Systemaufbau des Dienstes, durch den ein unberechtigter Zugriff auf diese Daten nicht nur über das Internet, sondern auch aus dem Betriebsumfeld des Betreibers (z. B. durch einen oder mehrere Mitarbeiter des Betreibers), technisch ausgeschlossen wird.

Der Systemaufbau des sektoralen IDP ist darüber hinaus dadurch bestimmt, dass die Verfügbarkeit des Dienstes für einzelne Mandanten (Kostenträger) erhalten bleiben muss, auch wenn die Verfügbarkeit für andere Mandanten z. B. durch unerwartet hohe Aktivität eingeschränkt wird.

Zum Ausschluss von Software-Manipulationen muss das ausführende System für den Verarbeitungskontext der VAU attestiert werden. Es wird davon ausgegangen, dass die in der VAU eingesetzte Software im Rahmen der Zulassung und anschließend mit jeder Änderung durch unabhängige Begutachtung abgesichert ist. Bekannte Software-Stände werden registriert und damit attestierbar. Die Systeme bieten Hardware-basierte Unterstützung für die authentifizierbare Messung aller geladenen Software (Firmware, Bootloader, OS, Anwendungssoftware, Enklaven-Software) und lassen sich auf der Grundlage so ermittelter Messungen attestieren. Die Attestation als Teil des Boot-Vorgangs und als Voraussetzung zur Erlangung einer gültigen Service-Identität stellt damit sicher, dass nur aktuelle und geprüfte Systeme von Nutzern angesprochen werden können.

Die Nutzung von Technologien wie Intel SGX dient der Verkleinerung der Angriffsfläche gegen die Software durch Hardware-basierte Mechanismen, z. B. zur individuellen Verschlüsselung des Arbeitsspeichers eines Prozesses, um Angriffe abzuwehren, die aus einer fehlerbehafteten Speicherverwaltung resultieren können. Leider decken diese Mechanismen nicht alle denkbaren Angriffe gegen den geschützt ausgeführten Code zuverlässig ab. Es werden immer wieder neue Side Channel Angriffe entdeckt, die aus dem Kontext des Betriebssystems auch gegen Enklaven eingesetzt werden könnten. Daher wird auch sämtliche Software außerhalb der Enklave in den Attestationsprozess eingebunden, sodass zur Laufzeit kein Angriffscode eingeschleust werden kann. Dies reduziert den für die Erkennung von möglichen Schwachstellen erforderlichen Aufwand im Rahmen der Begutachtung.

8.1 Standalone

Der Betreiber des sektoralen IDP stellt pro Instanz eine dedizierte Hardware-Umgebung zur Ausführung des Dienstes bereit. Empfehlungen der gematik zum Aufbau dieser Instanzen sind im Folgenden beschrieben.

Eine Instanz besteht aus:

1. einem Load Balancer, der die Rolle der in [gemSpec_IDP_Sek], Kap. 4.2 festgelegten Eingangspunkte erfüllt:
2. • Endpunkt für Pushed Authorization Requests
   • Endpunkt für Authorization Request
   • Token-Endpunkt
   • Endpunkt für Datensynchronisation mit Bestandssystem 
3. einer Konfiguration von Servern, die eine Vertrauenswürdige Ausführungsumgebung gemäß [gemSpec_IDP_Sek], Kap. 3.2 bilden – dies umfasst ein HSM für die Attestation der Server und die Handhabung des privaten Schlüssels der Identität der VAU - und
4. einem Datenbanksystem zur Aufnahme sämtlicher persistenter Daten der Anwendung in verschlüsselter Form.

Der Betreiber des sektoralen IDP wird sämtliche Systeme unterbrechungsfrei mit Strom versorgen.

Die folgende Abbildung zeigt den Aufbau einer Instanz der sektoralen IDP im Überblick:

Abbildung 11 : 3.2.6 Umsetzungsempfehlungen für die Vertrauenswürdige Ausführungsumgebung

8.1.1 Load Balancer

Der Anbieter des sektoralen IDP realisiert die Netzanbindung der Server-Systeme des sektoralen IDP über einen Load Balancer mit folgenden Geräte- und Konfigurationseigenschaften:

• Netzanbindung: Der Load Balancer verfügt über öffentlich adressierbaren IP-Adressen. Die Anzahl der jeweils konfigurierten IP-Adressen ist so gewählt, dass die maximale Anzahl gleichzeitiger Client-Verbindungen, die sich aus dem angegebenen Mengengerüst ableitet, ermöglicht wird.
• Abwehr von DDoS-Angriffen: Der Load Balancer kann in die Abwehr von DDoS-Angriffen eingebunden sein (z. B. für die Abwehr von Syn-Flooding) und als Teil einer umfassenden (vorgelagerten) Infrastruktur zur Abwehr solcher Angriffe an der Limitierung von Netzverkehr mitwirken bzw. zur Angriffserkennung Meldungen über ungültige Aufrufe an die vorgelagerte Abwehr-Infrastruktur senden.
• Protokollierung: Der Load Balancer protokolliert alle für die Überwachung seines betrieblichen Zustands durch den Anbieter erforderlichen Daten.
• Stromversorgung: Der Load Balancer ist mit einer zweifach redundanten Stromversorgung ausgestattet.
  

8.1.2 Anwendungsserver und zugehörige Infrastruktur

Dem Schutzbedarf der im sektoralen IDP unverschlüsselt verarbeiteten Daten wird durch den Einsatz einer Vertrauenswürdigen Ausführungsumgebung (VAU) gemäß [gemSpec_IDP_Sek], Kap. 3.2 Rechnung getragen. Das in diesem Abschnitt beschriebene Subsystem des sektoralen IDP stellt die vertrauenswürdige Ausführungsumgebung dar.
Der Anbieter des sektoralen IDP stellt sämtliche Anwendungsserver auf denen die fachliche Logik des sektoralen IDP ausgeführt wird (VAU-Server), das HSM zur Attestation dieser Anwendungsserver und zur Bereitstellung und Anwendung des privaten Schlüssels der Dienstidentität des sektoralen IDP sowie sämtliche Komponenten zur Vernetzung der VAU-Server und des HSM in einem oder mehreren Serverschränken (VAU-Serverschränken) bereit. Ein VAU-Serverschrank ist ein Serverschrank der Schutzklasse WK 4, der zusätzlich mit folgenden Sicherheitsvorkehrungen ausgestattet ist:

• einer Abschirmung gegen elektromagnetische Abstrahlung insoweit diese geeignet ist, Daten aus der Verarbeitung innerhalb des Serverschranks von außerhalb des Serverschranks zu extrahieren,
• einem verstärkten Türschloss zur gegenüber Schutzklasse WK 4 verbesserten Abwehr bzw. Verzögerung von Versuchen zum gewaltsamen Eindringen in den Schrank,
• einem Türsensor, der im Falle eines unautorisierten Öffnens der Schranktür die Stromzufuhr aller im Schrank verbauten Systeme sofort unterbricht, 
• einem Mechanismus zur Alarmierung bei unautorisierter Öffnung sowie
• ein Zugang von Mitarbeitern des Anbieters des sektoralen IDP zum Schrank kann nicht unkontrolliert erfolgen.
  Der Anbieter des sektoralen IDP richtet die VAU-Serverschränke so ein, dass mehrere Gruppen von VAU-Servern verfügbar sind wie im Folgenden beschrieben: 
  Jede Gruppe von VAU-Servern besteht aus mindestens 2 physisch separaten VAU-Servern. Die Anzahl der VAU-Server für jede Gruppe wird darüber hinaus durch die Lastanforderungen (für die jeweilige Gruppe) bestimmt. Die verschiedenen Gruppen von VAU-Servern sind jeweils verschiedenen Mandanten des sektoralen IDP zugeordnet:

• Die physische Trennung der VAU-Server dient der Sicherstellung der Verfügbarkeit des sektoralen IDP für die verschiedenen Mandanten im Falle einer (z. B. überlastbedingten) Einschränkung der Verfügbarkeit des sektoralen IDP.

8.1.3 Vernetzung Load-Balancer/VAU-Server

Der Anbieter des sektoralen IDP vernetzt die VAU-Server mit dem Load Balancer wie im Folgenden beschrieben:
Die Zuführung der Netzwerkverbindungen für Zugriffe aus dem Internet zu den VAU-Servern erfolgt über den Load Balancer und von diesem ausgehend über einen Switch und eine Firewall (Eingangs-Switch, bei mehreren VAU-Serverschränken Eingangs-Switches und Firewalls) innerhalb des VAU-Serverschranks. Der Eingangs-Switch, die Firewall und die VAU-Server sind so konfiguriert, dass jede der VAU-Servergruppen ein eigenes Subnetz bildet, dass VAU-Server keine Netzverbindungen untereinander aufbauen können und dass sämtlicher nicht vorgesehener Netzverkehr blockiert wird.
Den VAU-Servern sind die für die Anwendungsfunktionalität erforderlichen mandantenspezifischen URLs zugeordnet. Der Load Balancer ist so konfiguriert, dass er die Verteilung der Requests auf die VAU-Server aufgrund der URLs der Requests vornehmen kann. Der Load Balancer ist weiterhin so konfiguriert, dass er die Verteilung der Requests auf die einzelnen VAU-Server im Round-Robin-Verfahren vornehmen kann.

8.1.4 Vernetzung VAU-Server/HSM

Der Anbieter des sektoralen IDP vernetzt die VAU-Server mit dem HSM im VAU-Serverschrank wie im Folgenden beschrieben:
Alle VAU-Server sind individuell (über ein zweites Netzwerk-Interface der VAU-Server und einen zweiten Switch (HSM-Switch) innerhalb des VAU-Serverschranks) mit dem HSM vernetzt. Diese Vernetzung innerhalb des VAU-Serverschranks darf physisch und logisch nur VAU-Server und das HSM umfassen. 
Falls mehr als ein VAU-Serverschrank für eine Instanz des sektoralen IDP erforderlich ist, darf ein einzelnes HSM in nur einem der VAU-Serverschränke von VAU-Servern in den weiteren VAU-Serverschränken mit genutzt werden. In diesem Fall muss die Vernetzung zwischen den Serverschränken als eine Switch-zu-Switch-Verbindung zwischen den dedizierten VAU-Server/HSM Netzen in den einzelnen VAU-Serverschränken ausgeführt sein. Der physische Aufbau der VAU-Serverschränke muss es dabei ausschließen, dass das Verbindungkabel von außerhalb der VAU-Serverschränke manipulierbar ist.
Der HSM-Switch (bei mehreren VAU-Serverschränken die HSM-Switches) und die VAU-Server sind so konfiguriert, dass VAU-Server keine Netzverbindungen untereinander aufbauen können.

8.1.5 Vernetzung VAU-Server/Datenbankserver

Der Anbieter des sektoralen IDP vernetzt die VAU-Server mit der außerhalb der VAU betriebenen Datenbank wie im Folgenden beschrieben:
Alle VAU-Server sind über ein drittes Netzwerk-Interface der VAU-Server und einen dritten Switch (Ausgangs-Switch) und eine Firewall innerhalb des VAU-Serverschranks mit dem Datenbankserver vernetzt.
Der Ausgangs-Switch und die Firewall (bei mehreren VAU-Serverschränken die Ausgangs-Switches und die Firewalls) und die VAU-Server sind so konfiguriert, dass VAU-Server keine Netzverbindungen untereinander aufbauen können und sämtlicher nicht vorgesehene Netzverkehr blockiert wird.

8.1.6 Vernetzung des Management Interface mit dem internen Netz des Anbieters des sektoralen IDP

Der Anbieter des sektoralen IDP stattet alle VAU-Serverschränke mit einem Management Interface mit niedriger Bandbreite (56kbps) aus, dass alle VAU-Server sowie das HSM erreichbar macht und nur die zwingend notwendigen betrieblichen Steuerungsmöglichkeiten zur Abfrage des elementaren Betriebszustands und für einen Start, Neustart sowie das kontrollierte Herunterfahren der Systeme anbietet.

8.1.7 VAU-Server

Die VAU-Server bilden den Kern der Vertrauenswürdigen Ausführungsumgebung. Neben ihrer grundsätzlichen Eignung als Anwendungsserver im Rechenzentrumsbetrieb, müssen VAU-Server zur Vertrauenswürdigkeit der Datenverarbeitung im sektoralen IDP beitragen. 
Der Anbieter des sektoralen IDP wird VAU-Server einsetzen, die folgende Sicherheitseigenschaften aufweisen:

• Ein VAU-Server ist frei von Komponenten zur persistenten Speicherung von Daten mit Ausnahme der Firmware (Diskless Server).
• Ein VAU-Server verfügt über einen Boot Loader, der Boot Images über das Netzwerk laden und ihre Signatur gegen ein vorgegebenes, d. h. manipulationssicher konfiguriertes, Zertifikat prüfen kann.
• Ein VAU-Server unterstützt Measured Boot über die gesamte geladene Software sowie über sämtliche sicherheitsrelevanten Plattform-Konfigurationswerte (z. B. mittels eines TPM-Moduls).
• Ein VAU-Server unterstützt Remote Attestation in einer Form, die keine regelmäßige (d. h. bei jedem Systemstart notwendige) Einbindung von Diensten des Herstellers erfordert (z. B. dadurch, dass ein Sealing möglich ist, oder dass eine Attestation unabhängig von Diensten des Herstellers umgesetzt werden kann).
• Ein VAU-Server bietet Hardware-Unterstützung für die Speicherverwaltung (MMU und IOMMU) und die benötigten kryptographischen Primitiven.
  Der Einsatz des Boot Loaders mit Signaturprüfung der Boot Images dient primär dazu, das Laden ungeprüfter Softwarekomponenten zu verhindern, während die Attestation zur Sicherstellung der Integrität der Gesamtheit aus geprüfter Software und Systemkonfiguration dient.
  

8.1.8 VAU-Server Software Stack

Der Anbieter des sektoralen IDP wird die Software auf den VAU-Servern darauf auslegen, die Sicherheitsziele für die Server zu erreichen, indem der Software Stack (d. h. die Gesamtheit aller auf den Servern geladenen Software) minimalistisch ausgelegt ist (Minimal Trusted Computing Base). Die Software ist gehärtet und bietet einen robusten Mechanismus zur Separation, mittels dessen verschiedene Aspekte der Verarbeitung auf den VAU-Servern gegeneinander isoliert werden.
Der Anbieter des sektoralen IDP nutzt den Separationsmechanismus mindestens dazu, die System Management Funktionen zur Steuerung des Systems durch den Betreiber von der Verarbeitung der schützenswerten Daten zu trennen. Darüber hinaus soll der Anbieter des sektoralen IDP über den Separationsmechanismus eine Partitionierung umsetzen, die potenziell angreifbare Treiber und Protokolle von der Verarbeitung der schützenswerten Daten isoliert sowie die an die einzelnen Hardware-Netzwerkschnittstellen gebundenen Netzwerkfunktionen voneinander und vom Rest der Software trennt. Die Separation soll zudem dazu genutzt werden, die verschiedenen Funktionsmodule zur Ausführung der Fachlogik voneinander zu trennen. Zu beachten ist, dass trotz der Separationsmechanismen die Attestation der gesamten geladenen Software erfolgen muss.
Die Separation der einzelnen fachlichen Verarbeitungsvorgänge (Requests) innerhalb eines Funktionsmoduls voneinander kann der Anbieter des sektoralen IDP auf der Ebene der Anwendungssoftware umsetzen. Die Anwendungssoftware gehört zur Trusted Computing Base der VAU. Ihre Sicherheits- und insbesondere ihre Separationseigenschaften müssen sicherheitstechnisch bewertbar sein.

8.1.9 Open Source Software Stack

Die Vertrauenswürdigkeit der VAU soll dadurch untermauert werden, dass VAU-Server im Rahmen des Machbaren für die Öffentlichkeit transparente Systeme darstellen. Interessierte Personen oder Organisationen müssen – die notwendige Fachkenntnis vorausgesetzt – anhand öffentlich verfügbarer Informationen in der Lage sein, im Detail nachzuvollziehen, wie die Systeme aufgebaut sind und funktionieren. Diese Nachvollziehbarkeit soll dadurch erreicht werden, dass es dem Anbieter des sektoralen IDP auferlegt wird, eine geeignete Auswahl für die technische Basis der VAU-Server zu treffen, um zu erreichen, dass die Softwarekomponenten der VAU-Server möglichst weitgehend öffentlich im Quellcode offengelegt sind.
Der offengelegte Quellcode ist fortlaufend auf dem Stand des produktiven Systems zu halten. Bei Änderungen an der Software in der Produktionsumgebung ist die öffentliche Dokumentation des Quellcodes unverzüglich zu aktualisieren.
Für alle Teile der Software der VAU, deren Quellcode nicht öffentlich gemacht werden kann, ist der zum jeweiligen Zeitpunkt gegebene binäre Stand dieser Software zu veröffentlichen.

8.1.10 Attestation und Integritätsschutz für VAU-Server

Der Anbieter des sektoralen IDP stattet die VAU-Server mit der Fähigkeit zur Remote Attestation auf der Basis der beim Booten des Systems und beim Laden sämtlicher Software gemessenen Werte und einer Signatur des TPM aus. Die Attestation erfolgt gegenüber dem im VAU-Serverschrank integrierten HSM.
Zur Gewährleistung der Wirksamkeit des durch die Remote Attestation gegenüber dem HSM gegebenen Integritätsschutzes für die Laufzeitumgebung der VAU-Server wird der Anbieter des sektoralen IDP die Software für die VAU-Server im Rahmen des technisch Machbaren so gestalten, dass sich VAU-Server nach vollständigem Abschluss des Boot- und Ladevorgangs die Rechte für ein Nachladen von Software selbst entziehen.

8.1.11 HSM

Der Anbieter des sektoralen IDP integriert ein netzwerkfähiges HSM in den VAU-Serverschrank. Das HSM stellt drei systemspezifische Schnittstellen bereit, nämlich:

1. die Schnittstelle zur Remote Attestation von VAU-Servern,
2. eine Schnittstelle zur Nutzung der kryptographischen Identität der VAU für die Terminierung von TLS Verbindungen sowie
3. eine Schnittstelle zur Nutzung der Signaturfunktion auf Basis des privaten Schlüssels der kryptographischen Identität des sektoralen Identity Providers.
   

Darüber hinaus bietet das HSM eine Management-Schnittstelle zur Einrichtung des HSM im Rahmen einer Zeremonie und zur Einbringung gültiger Referenzwerte für die Attestation der VAU-Server sowie zur Handhabung des privaten Schlüssels der VAU-Identität.
Die Management-Schnittstelle des HSM wird über das Management Interface des VAU-Serverschranks über Netz verfügbar gemacht.
Das HSM macht die Schnittstellen 2 und 3 nur erfolgreich attestierten VAU-Servern über eine TLS-Verbindung verfügbar.

8.1.12 Datenbank

Der Anbieter des sektoralen IDP stellt ein Datenbanksystem außerhalb der VAU bereit, in das alle verschlüsselten Identitätsdaten gespeichert werden und dass diese Daten über alle Instanzen des sektoralen IDP synchronisiert. 
Die Synchronisation von Änderungen muss unmittelbar erfolgen und innerhalb von 500 ms abgeschlossen sein. Eine Spiegelung der Daten mit noch geringerer Latenz ist aufgrund der Architektur des sektoralen IDP nicht erforderlich.
Das Datenbanksystem stellt für die VAU-Server eine REST-Schnittstelle bereit, über die alle benötigten Datenbanktransaktionen abgebildet werden können.
Der Anbieter des sektoralen IDP wird seine Wahl eines Datenbanksystems sowie dessen wesentliche Eigenschaften hinsichtlich Dimensionierung, Synchronisation der Datenbestände und Integration in seine Systems Management Prozesse im Umsetzungskonzept darlegen.

8.1.13 Repository

Der Anbieter des sektoralen IDP stellt ein Repository außerhalb der VAU bereit, aus dem die VAU-Server ihre Boot Images beziehen können. Die Schnittstelle des Repository richtet sich nach den Anforderungen des Bootloaders.
Das Repository muss ausreichend geschützt sein, um Ausfälle des sektoralen IDP durch fehlerhafte Boot Images auszuschließen.
Der Anbieter des sektoralen IDP wird sich mit der gematik über einen geeigneten Prozess zur kontrollierten Einbringung signierter Boot Images verständigen. Dort gibt es bereits etablierte Prozesse auch zu Remote Sitzungen für Schlüsselzeremonien und HSM Interaktionen. Der gematik fällt in diesem Prozess die Rolle des Signers der Boot Images zu.