latest

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation Identity Provider – Nutzungsspezifikation
für Fachdienste

    

     

      
Version
      
1.7.1
     
     

      
Revision
      
879129
     
     

      
Stand
      
05.04.2024
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_IDP_FD
     
    

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

Dieses Kapitel definiert die Anforderungen zu Herstellung, Test und Betrieb der Schnittstellen von Fachdiensten, die am föderierten Identity Management der TI teilnehmen wollen, um dessen Benutzern darüber die Authentisierung zu ermöglichen, oder die den Identity Provider-Dienst (IDP-Dienst) nutzen wollen.

Die bisherigen Inhalte der gemSpec_IDP_FD beschreiben die Nutzung des IDP Dienstes und gelten weiterhin als Unterkapitel.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller und Anbieter von Fachdiensten und Fachanwendungen, welche die Funktion des IDP-Dienstes nutzen wollen oder die am föderierten Identity Management der TI teilnehmen wollen.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur 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. Dokumentenlandkarte, 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

Spezifiziert werden in diesem Dokument die von den Produkttypen sektoraler Identity Provider und IDP-Dienst bereitgestellten Schnittstellen sowie die Bedingungen, unter denen diese zu nutzen sind. Weitere Details zu den benutzten Schnittstellen werden in den Spezifikationen des sektoralen Identity Providers bzw. des IDP-Dienstes beschrieben. Auf die entsprechenden Dokumente wird referenziert (siehe auch Anhang 6 Anhang A – Verzeichnisse).

Die vollständige Anforderungslage für die Produkttypen sektoraler Identity Provider und IDP-Dienst ergibt sich aus den weiteren Konzept- und Spezifikationsdokumenten; diese sind in den jeweiligen Produkttypsteckbriefen verzeichnet.

Nicht Bestandteil des vorliegenden Dokumentes sind die Festlegungen und Anforderungen, welche sich an sektorale Identity Provider und den IDP-Dienst selbst richten.

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 Systemüberblick

Im Rahmen der Telematikinfrastruktur (TI) werden zahlreiche Fachdienste angeboten. Sektorale Identity Provider (IDPs) übernehmen für diese Fachdienste die Aufgabe der Authentisierung des Nutzers. Anwendungsfrontends können, über die Authentifizierung des Nutzers gegenüber sektoralen IDP, Zugriff zu den von den Fachdiensten für den jeweiligen Nutzer angebotenen Daten erhalten. Sektorale IDP stellen durch gesicherte JSON Web Token (JWT) attestierte Identitäten aus, sogenannten ID_TOKEN. Auf dieser Basis wird dem Anwendungsfrontends vom Authorization-Server des Fachdienstes ein ACCESS_TOKEN ausgestellt. Gegen Vorlage dieses ACCESS_TOKEN erhalten Anwendungsfrontends, entsprechend der im Token attestierten Informationen, Zugriff auf die Inhalte der Fachdienst API. Der Authorization-Server und die Fachdienst API sind Teile des Fachdienstes. Fachdienste müssen keine Überprüfung des Nutzers selbst implementieren, sondern können sich darauf verlassen, dass der Nutzer bereits identifiziert und authentisiert wurde und die im ID_TOKEN enthaltenen Attribute gültig sind. Zudem müssen im ACCESS_TOKEN keine persönlichen Informationen enthalten sein, sondern diese können, sofern benötigt von der Fachdienst API abgerufen werden.

Im Falle einer App als Anwendungsfrontend werden direkt dort die ACCESS_TOKEN gehandhabt und gespeichert. Im Falle eines Web-basierten Anwendungsfrontends kann diese Aufgabe das Web-Backend übernehmen.

Abbildung 1: Systemüberblick

Die Abbildung stellt den Systemüberblick dar. Der Authentifizierungsprozess, welcher mit der Ausstellung und Übergabe der Token an das Anwendungsfrontend endet, wird dabei zur besseren Übersicht vereinfacht dargestellt.

Fachdienste, welche sektorale IDPs der TI-Föderation zur Nutzer-Authentisierung nutzen möchten, müssen die folgenden Prozesse und Schnittstellen bedienen:

• Registrierung des Fachdienstes beim Federation Master (organisatorischer Prozess gemäß [gemSpec_IDP_FedMaster]), sowie der verwendeten öffentlichen Schlüssel für die Signatur von Entity Statements und Mitteilung der benötigten scopes bzw. claims (Key/Value-Paare im Payload eines JWT)
• Veröffentlichung ihres signierten Entity Statements (siehe 4.5).

Alle Fachdienste müssen zur Absicherung der JWT gegen Einsichtnahme und Profilbildung durch Dritte den Transportweg bis in die Vertrauenswürdige Ausführungsumgebung (siehe [gemSpec_IDP_Sek]) mit Transport Layer Security (TLS) gemäß [gemSpec_Krypt] absichern.

3 Systemkontext

Der Systemkontext besteht für den Fachdienst aus einem sektoralen Identity Provider, dem Federation Master und einem Anwendungsfrontend.

Der Fachdienst muss beim Federation Master eine organisatorische Registrierung durchführen [gemSpec_IDP_FedMaster], bei welcher der vom Fachdienst verwendete kryptographische öffentlicher Schlüssel sowie dessen Adresse beim Federation Master hinterlegt werden.

Der Fachdienst besteht aus einem Authorization-Server, einer Fachdienst API und optional aus einem Web-Backend. Das Web-Backend kann im Falle einer Web-Anwendung zur Anwendung kommen. In diesem Fall besteht das Anwendungsfrontend aus einer Web-Anwendung die üblicherweise im Browser des Benutzers ausgeführt wird. Diese Web-Anwendung interagiert mit dem Web-Backend, der wiederum Teilaufgaben übernehmen kann und insb. mit dem Authorization-Server kommuniziert. Bei einer solchen Web-Lösung muss keine direkte Interaktion zwischen Anwendungsfrontend und Authorization-Server erfolgen.

Im Falle einer mobilen App stellt diese das Anwendungsfrontend dar und es ist kein Web-Backend nötig.

Das Anwendungsfrontend bzw. Web-Backend erlangt nach Vorlage des ACCESS_TOKEN und positiver Validierung der Inhalte des Tokens durch den Fachdienst Zugang zu den angeforderten Fachdaten.

Die folgende Abbildung stellt den Systemkontext aus Sicht eines Fachdienstes dar.

Abbildung 2: Systemkontext

3.1 Akteure und Rollen

Im Systemkontext des Fachdienstes interagieren verschiedene Akteure (Nutzer und aktive Komponenten) in unterschiedlichen OAuth2-Rollen gemäß [RFC6749 # section-1.1].

Tabelle 1: TAB_IDP_FD_0001 Akteure und Rollen nach OAuth2/OIDC

Nutzer

Der Resource Owner ist der Nutzer, welcher auf die beim Fachdienst (Resource Server) für ihn bereitgestellten Daten (Protected Resource) zugreift.

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

·         Endgerät des Nutzers

·         Authenticator-Modul

·         Anwendungsfrontend

Fachdienst

Der Resource Server ist der Fachdienst, der dem Nutzer (Resource Owner) Zugriff auf seine Fachdaten (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 an den Client delegierte Zugriffsautorisierung des Resource Owners.

Anwendungsfrontend

Der Frontend greift als OAuth2 Client auf Fachdienste (Resource Server) und ihre geschützten Fachdaten (Protected Resource) zu. Das Anwendungsfrontend kann auf einem Server als Webanwendung (Backend System), auf einem Desktop-PC oder einem mobilen Gerät (z.B. Smartphone) ausgeführt werden. 

Authenticator-Modul

Das Authenticator-Modul stellt eine Komponente des sektoralen IDP dar über welche die Authentifizierung des Nutzers stattfindet. Sie wird auf einem Gerät des Nutzers ausgeführt.

Authorization Server

Der Authorization Server gehört zum Fachdienst und autorisiert (erlaubt) für einen bestimmten Resource Owner Zugriff auf die Fachdaten am Fachdienst - basierend auf der Identität und den Rechten des Nutzers. Gegenüber dem sektoralen IDP agiert er als Client welcher die Authentisierung des Nutzers anfragt.

sektoraler Identity Provider

Der IDP authentifiziert den Nutzer und bestätigt die Identität des Resource Owner gegenüber dem Authorization Server. Die in der Föderation registrierten Fachdienste nutzen die sektoralen Identity Provider um Nutzer ihrer Anwendungen über die Verfahren der sektoralen Identity Provider eindeutig zu authentifizieren und die Zustimmung der Datennutzung von den Nutzern einzuholen. Dabei nutzt der sektorale Identity Provider das Authenticator-Modul als Schnittstelle zum Nutzer.

Fachdaten

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

Federation Master

Der Federation Master verwaltet und vermittelt die Vertrauensbeziehungen zwischen Identity Providern und Fachdiensten, so dass diese keine bilateralen Verbindungen über organisatorische Registrierungsprozesse bilden müssen. Er bestätigt Kryptographische Schlüssel der Dienste und ermöglicht es so das Nutzern jedes sektoralen Identity Provider direkt auf alle Dienste der Föderation zugreifen können. Und er schafft Möglichkeiten dazu Dienste aus der Föderation auszuschließen, wenn es dazu die Notwendigkeit gibt.

4 Funktion eines Authorization-Server in der Föderation

4.1 Registrierung des Fachdienstes beim Federation Master

Fachdienstbetreiber müssen ihren Authorization-Server beim Federation Master registrieren. Die Registrierung erfolgt als organisatorischer Prozess, bevor ein Fachdienst an den vom föderierten Identitätsmanagement (IDM) angebotenen Authentifizierungsprozessen teilnehmen kann. Erst nach erfolgter Registrierung, bei der die Adresse des Fachdienstes bzw. seines Authorization-Servers, seine öffentlichen Schlüssel sowie die verwendeten scopes und claims angegeben wurden, können sektorale Identity Provider ID_TOKEN für den Fachdienst ausstellen.

Hinweis: claims definieren konkrete Key/Value-Paare, die als Payload eines JWT codiert werden. Scopes fassen ein oder mehrere claims als Gruppe im Authorization Request zusammen. Ein vereinbarter scope sagt aus, welche Key/Value-Paare im Payload erwartet werden. Die Vereinbarung wird zwischen dem Fachdienst und dem Federation Master während der Registrierung des Fachdienstes getroffen. Im Rahmen einer Authentifizierung fragen Authorization-Server den jeweils benötigten scope bzw. claims an, die im Rahmen des ID_TOKEN vom sektoralen Identity Provider bestätigtwerden.

Sollte im Authorization Request ein bestimmtes Attribut (claim) sowohl über ein scope (bestimmtes claim ist in der Gruppe enthalten) als auch über den claims Parameter als essential claim angefordert werden, ist die Anforderung aus dem claims Parameter prioritär zu behandeln.

Hinweis: Weitere Signaturschlüssel des Federation Master können aus dessen Entity Statement importiert werden.

Hinweis: Diese Funktionalität kann dahingehend umgesetzt werden, dass im Pool der Vertrauenswürdigen CAs nur solche aufgenommen werden, welche dem CAB-Forum zugehören.

4.2 Übergreifende Festlegungen

Der Payload eines JWT beinhaltet Key/Value-Paare, welche in einem oder mehreren scopes definiert werden. Inhalte eines scopes sind mehrere Attribute, welche der sektorale IDP auf Basis der vorgetragenen Identität bestätigen kann.

Die scopes beinhalten die für diesen Fachdienst abgestimmten Attribute (die scopes werden pro Fachdienst in einem organisatorischen Prozess gesoert vom jeweiligen Fachdienst mit dem Federation Master abgestimmt) und den Wertebereich, welchen diese annehmen können.

Neben den im Standard vorgesehenen Attributen (siehe openid-connect-core-1_0.html#IDToken) erwarten Fachdienste in der Regel weitere Informationen, wie zum Beispiel Vorname, Name, Rolle und KVNR des Nutzers. Siehe hierzu auch [gemSpec_IDP_Sek] Kapitel: "Token-Endpunkt Ausgangsdaten".

Hinweis 1: Der Aufbau von ID_TOKEN entspricht den Anforderungen gemäß [gemSpec_IDP_Sek] Kapitel: "Token-Endpunkt Ausgangsdaten".

Hinweis 2: Fachdienste, welche keine personenbezogenen Daten des Nutzers benötigen, setzen allein den Scope "openid" und erhalten damit im Attribut sub eine dienstspezifische pseudonyme ID des Versicherten.

Hinweis: Geeignete Reaktion auf fehlenden claims könnten darin bestehen, dass nur fachliche Anwendungsfälle ausgeführt werden, für welche die Informationen zum Nutzer hinreichend vorhanden sind. Zulässig ist auch eine Ablehnung des Benutzers mit entsprechender Information für den Fall, dass ohne die notwendigen Angaben aus den fehlenden claims keine Ausführung fachlicher Anwendungsfälle möglich ist.

Hinweis: Der Authorization-Server kann die Informationen aus die vom Federation Master erhaltene IDP-Liste um zusätzliche Informationen für  den Nutzer ergänzen bzw. für eine nutzerfreundliche Darstellung in der UI aufbereiten.

Hinweis: Dabei kann das Anwendungsfrontend entweder gegen den bekannten öffentlichen Schlüssel des Federation Master prüfen, der Authorization-Server die Liste mit einem dem Anwendungsfrontend bekannten Schlüssel neu signieren oder aber die Liste durch den Authorization-Server innerhalb einer gesicherten TLS Verbindung zum Anwendungsfrontend zur Anzeige gebracht werden.

4.3 Entity Statements

Hinweis: Details zum Aufbau des Entity Statements finden sich in den [gemSpec_IDP_Sek] Tabellen: "Header des Entity Statement des Fachdienstes" und "Body des Entity Statement des Fachdienstes".

Hinweis: Die Anforderung gilt sowohl für die Statements des Identity Provider sowie für die Statements des Federation Master über die Identity Provider.

Hinweis: Der Abgleich des Signaturschlüssels muss gegen ein frisch abgerufenes Statement des Federation Master zu diesem sektoralen Identity Provider erfolgen.

Hinweis: Details zum Aufbau des signed_jwks Schlüsselsatzes finden sich in den [gemSpec_IDP_Sek] Tabellen: "Header des KeySet des Fachdienstes" und "Body des KeySet des Fachdienstes"

4.4 Anfrage von "ID_TOKEN" beim sektoralen Identity Provider

Hinweis: 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: Nach A_22649 registriert der sektorale IDP den anfragenden Fachdienst nach dem ersten Request gemäß https://openid.net/specs/openid-connect-federation-1_0.html#section-10.1.1.1.1.

4.5 Verifikation des "ID_TOKEN"

Hinweis: Wenn dem Fachdienst im ID_TOKEN zwingend notwendige Daten nicht übermittelt werden, kann er die Anmeldung des Nutzers nicht durchführen. Gemäß A_22733 ist es für sektorale Identity Provider zulässig, bei fehlenden Daten oder nicht erteilter Zustimmung des Nutzers gewisse Werte in ID_TOKEN nicht zu liefern.

4.6 Blacklisting von Client-IP-Adressen

Die Anforderungen im entsprechenden Kapitel 5.2 gelten unverändert auch für Fachdienste im Rahmen der Föderation.

4.7 ACCESS_TOKEN

4.8 REFRESH_TOKEN

5 Anbindung eines Fachdienstes an den zentralen IDP-Dienst

Während die sektoralen Identity Provider den zentralen IDP-Dienst langsam ablösen, bleibt dieser doch für die kartenbasierten Leistungserbringeridentitäten weiterhin eine wichtige Komponente. Anwendungen können den IDP-Dienst nutzen um sich die Identitäten von Leistungserbringern oder Leistungserbringerinstitutionen sicher bestätigen zu lassen ohne eigene Authentisierungsmechanismen zu implementieren.

Anwendungsfrontends können über die Authentifizierung des Nutzers am IDP-Dienst Zugriff zu den von den Fachdiensten angebotenen Daten erhalten. Der IDP-Dienst stellt durch gesicherte JSON Web Token (JWT) attestierte Identitäten aus. Gegen Vorlage eines ACCESS_TOKEN erhalten Anwendungsfrontends, entsprechend der im Token attestierten professionOID, Zugriff auf die Inhalte der Fachdienste.

Abbildung 3: Systemüberblick (vereinfacht)

Die Abbildung stellt den Systemüberblick dar. Der Authentifizierungsprozess, welcher mit der Ausstellung und Übergabe der Token an das Anwendungsfrontend endet, wird dabei zur besseren Übersicht vereinfacht dargestellt.

Der IDP-Dienst übernimmt für den Fachdienst die Aufgabe der Authentisierung des Nutzers. Der IDP-Dienst fasst die professionOID sowie weitere für den Fachdienst notwendige Attribute in signierten JSON Web Token (ID_TOKEN und ACCESS_TOKEN) zusammen. Fachdienste müssen keine Überprüfung des Nutzers selbst implementieren, sondern können sich darauf verlassen, dass der Besitzer des bei ihnen vorgetragenen ACCESS_TOKEN bereits authentisiert wurde. Des Weiteren stellt der IDP-Dienst sicher, dass die vom Nutzer vorgetragenen Attribute (aus dem Signaturzertifikat) gültig sind.

Der IDP-Dienst prüft, ob das vorgetragene X.509-nonQES-Signatur-Zertifikat der verwendeten Prozessor-Chipkarte (eGK, HBA oder SMC-B) für die vorgesehene Laufzeit des Tokens zeitlich gültig und ob dessen Integrität sichergestellt ist.

Der IDP-Dienst stellt nur solche ACCESS_TOKEN aus, welche auf gültigen AUT-Zertifikaten (d.h. C.CH.AUT, C.HP.AUT oder C.HCI.AUT) basieren.

Fachdienste, welche den IDP-Dienst nutzen, müssen die folgenden Prozesse und Schnittstellen bedienen:

• Registrierung des Fachdienstes beim IDP-Dienst (organisatorischer Prozess gemäß Abschnitt 5.1 Registrierung des Fachdienstes beim IDP-Dienst)
• Abstimmen der Claims (Key/Value-Paare im Payload eines JSON Web Token) mit dem IDP-Dienst (organisatorischer Prozess gemäß Abschnitt 5.1.1 Inhalte des Claims)
• Abstimmen der Rahmenbedingungen für die Gültigkeit von ACCESS_TOKEN (siehe Abschnitt 5.4 Abstimmen der Rahmenbedingungen "ACCESS_TOKEN"-Gültigkeit)

Alle Fachdienste müssen zur Absicherung der JSON Web Token gegen Einsichtnahme durch Dritte den Transportweg mit Transport Layer Security (TLS) gemäß [gemSpec_Krypt] absichern. Der Fachdienst muss sowohl im Internet, als auch innerhalb der TI über ein überprüfbares TLS-Serverzertifikat verfügen. 

Fachdienste sind ebenfalls Nutzer des IDP-Dienstes als Resource Server und sind bei diesem organisatorisch als OAuth2.0 Client registriert. Sie verwenden die vom IDP-Dienst ausgegebenen ACCESS_TOKEN, um Nutzern Zugriff auf die von ihnen bereitgestellten geschützten Ressourcen, die Fachdaten, zu gewähren.

Der Systemkontext besteht für den Fachdienst aus dem IDP-Dienst und dem Anwendungsfrontend.

Die vom Fachdienst angebotene Schnittstelle, um Fachdaten zu erhalten, wird vom Anwendungsfrontend, welches auf dem Endgerät des Nutzers installiert ist, genutzt. Nutzer wollen über das Anwendungsfrontend Daten vom Fachdienst zur Anzeige, Änderung etc. erhalten. Die Authentisierung des Nutzers wird anhand einer Smartcard und der Auswertung des vom Authenticator-Modul an den IDP-Dienst übergebenen Authentifizierungszertifikats (aus der Smartcard) sichergestellt.

Der Fachdienst muss beim IDP-Dienst eine organisatorische Registrierung durchführen, bei der die vom Fachdienst erwarteten Werte, welche ein ACCESS_TOKEN für einen Zugriff auf die Fachdaten des Fachdienstes enthalten muss, hinterlegt werden.

Das Anwendungsfrontend erlangt nach Vorlage des ACCESS_TOKEN und positiver Validierung der Inhalte des Tokens durch den Fachdienst Zugang zu den angeforderten Fachdaten.

Die folgende Abbildung stellt den Systemkontext aus Sicht eines Fachdienstes dar. Eine Kommunikationsbeziehung besteht nur mit dem Identity Provider und dem Anwendungsfrontend.

Abbildung 4: Systemkontext aus Sicht des Fachdienstes

5.1 Registrierung des Fachdienstes beim IDP-Dienst

Fachdienste müssen sich beim IDP-Dienst registrieren. Die Registrierung erfolgt als organisatorischer Prozess, bevor ein Fachdienst am vom IDP-Dienst angebotenen Authentifizierungsprozess teilnehmen kann. Erst nach erfolgter Registrierung, bei der die Adresse des Fachdienstes, sein öffentlicher Schlüssel und die von ihm erwarteten Attribute, in Form von Claims, angegeben wurden, kann der IDP-Dienst ACCESS_TOKEN für den Zugriff zum Fachdienst ausstellen. 

Hinweis:
Die Beantragung beinhaltet eine sprechende Fachdienstbezeichnung. Die URI des Fachdienstes URI_FD muss dem Authorization Server, welcher Teil des IDP-Dienstes ist, bekanntgegeben werden. 

Hinweis 1: Als Claims werden Key/Value-Paare im Payload eines JWT bezeichnet. Ein vereinbarter Claim sagt aus, welche Key/Value-Paare im Payload erwartet werden. Die Vereinbarung wird zwischen dem Fachdienst und dem IDP-Dienst während der Registrierung des Fachdienstes getroffen. Anwendungsfrontends, welche Zugang zum Fachdienst erhalten wollen, müssen die geforderten Claims liefern.

Hinweis 2: Der Fachdienst kann auch alleiniger Client sein wenn er selbst die Token gemäß Kapitel 5.5 vom IDP-Dienst abruft - dies ist empfohlen.

5.1.1 Inhalte des Claims

Der Payload eines JSON Web Tokens beinhaltet Key/Value-Paare, welche als Claims bezeichnet werden. Inhalte eines Claims sind die Attribute, welche der IDP-Dienst auf Basis der vorgetragenen Identität aus deren Signaturzertifikat extrahieren kann. Als Basis kommen eGK [gemSpec_PKI # Abschnitt 5.1.3.1 Authentisierung eGK] und HBA [gemSpec_PKI # Abschnitt 5.2.1 Authentisierung HBA] bzw. SMC-B [gemSpec_PKI # 5.3 Ausweis einer Organisation/Einrichtung des Gesundheitswesens] in Frage. Davon abgesehen könnten zukünftig auch Identitäten, welche in einem eigenen oder externen Identity Management gehalten werden, vom IDP-Dienst bestätigt werden.

Die Claims beinhalten die für diesen Fachdienst abgestimmten Attribute (die Claims werden pro Fachdienst in einem organisatorischen Prozess gesondert vom jeweiligen Fachdienst mit dem IDP-Dienst abgestimmt) und den Wertebereich, welchen diese annehmen können.

Neben den im Standard vorgesehenen Attributen (siehe openid-connect-core-1_0.html#IDToken) erwarten Fachdienste weitere Attribute, welche vom Standard nicht bereitgestellt werden.

Im Falle des E-Rezept-Dienstes sind dies z. B.:

Für Versicherte (eGK):

• Rolle des Nutzers (oid_Versicherter, siehe [gemSpec_OID # Tab_PKI_402])
• ID des Nutzers (KVNR)
• Vorname und Nachname der Person

Für Leistungserbringer (SMC-B LEI):

• Rolle des Nutzers (OID-Festlegung Institutionen, siehe [gemSpec_OID #Tab_PKI_403])
• ID des Nutzers (Telematik-ID)
• Bezeichnung der Organisation

Das Attribut iss beschreibt, wer den ACCESS_TOKEN ausgestellt hat.

Das Attribut sub beschreibt das Subjekt, mit welchem der Fachdienst kommuniziert. Anhand dieses Attributes lassen sich Vorgänge einer bestimmen Entität zuordnen.

Das Attribut professionOID beschreibt die Rolle der agierenden Entität und ist im Falle eines Versicherten immer mit der OID eines Versicherten oid_Versicherter befüllt. Im Falle eines Leistungserbringers oder einer Leistungserbringerinstitution wird hier die sektorspezifische professionOID gemäß [gemSpec_OID # Tab_PKI_402] bzw. [gemSpec_OID # Tab_PKI_403] eingesetzt.

Hinweise:

• Die Befüllung des Claim erfolgt grundsätzlich gemäß [rfc7519 # section-4]
  
• Beispiel-Wert des Attributes iss: "https://idp.zentral.idp.splitdns.ti-dienste.de"
• Das Attribut iss wird durch den IDP-Dienst befüllt.
• Das Attribut aud enthält die eindeutige URI des Fachdienstes oder einen beim IDP-Dienst ausschließlich diesem Fachdienst zugesprochenen Wert z. B. E-Rezept oder eRp.
• Das Attribut professionOID des Versicherten wird durch den IDP-Dienst befüllt.
• Das Attribut jti kann als eindeutiger Identifikator für einen Replay-Schutz genutzt werden. Anhand des Attributs jti lassen sich ID_TOKEN und ACCESS_TOKEN einem bestimmten Vorgang zuordnen.

Der Aufbau von ACCESS_TOKEN und ID_TOKEN entspricht [gemSpec_IDP_Dienst#Kapitel 7.6 Token Response].

Hinweise:

• Die Befüllung des Claims erfolgt grundsätzlich gemäß [rfc7519 # section-4]
  
• Beispiel-Wert des Attributs iss: "https://erp.telematik/pfad/login"
• Das Attribut iss wird durch den IDP-Dienst befüllt.
• Das Attribut aud beschreibt den Fachdienst durch dessen eindeutige URI oder einen beim IDP-Dienst ausschließlich diesem Fachdienst zugesprochenen Wert z.B. E-Rezept oder eRP.
• Das Attribut professionOID des Leistungserbringers wird durch den IDP-Dienst befüllt. Andere als die in dieser Tabelle gemäß [gemSpec_OID # Tab_PKI_402] aufgeführten OID sind in diesem Attribut nicht zulässig.
• Das Attribut idNummer wird mit den Informationen aus dem Signaturzertifikat durch den IDP-Dienst befüllt.
• Das Attribut jti kann als eindeutiger Identifikator für einen Replay-Schutz genutzt werden. Anhand des Attributs jti lassen sich ACCESS-TOKEN einem bestimmten Vorgang zuordnen.

Der Aufbau von ACCESS_TOKEN und ID_TOKEN entspricht [gemSpec_IDP_Dienst#Kapitel 7.6 Token Response].

Das Claim einer Leistungserbringerinstitution beschreibt nicht die Entität, welche im Namen der Institution agiert, sondern die Institution selbst.

Hinweise:

• Die Befüllung des Claims erfolgt grundsätzlich gemäß [rfc7519 # section-4]
  
• Beispiel-Wert des Attributs iss: "https://erp.telematik/pfad/login"
• Das Attribut iss wird durch den IDP-Dienst befüllt.
• Das Attribut aud beschreibt den Fachdienst durch dessen eindeutige URI oder einen beim IDP-Dienst ausschließlich diesem Fachdienst zugesprochenen Wert z.B. e-Rezept oder eRp.
• Das Attribut professionOID der Leistungserbringerinstitution wird durch den IDP-Dienst befüllt. Andere als die in dieser Tabelle gemäß [gemSpec_OID # Tab_PKI_403] aufgeführten OID sind in diesem Attribut nicht zulässig.
• Das Attribut idNummer wird mit den Informationen aus dem Signaturzertifikat durch den IDP-Dienst befüllt.
• Das Attribut jti kann als eindeutiger Identifikator für einen Replay-Schutz genutzt werden. Anhand des Attributes jti lassen sich ACCESS_TOKEN einem bestimmten Vorgang zuordnen.

Der Aufbau von ACCESS_TOKEN und ID_TOKEN entspricht [gemSpec_IDP_Dienst#Kapitel 7.6 Token Response].

5.2 Blacklisting von Client-IP-Adressen

Bekommt ein Fachdienst Kenntnis davon, dass ein ACCESS_TOKEN zur Durchführung eines Angriffs, z. B. einer Distributed Denial of Service DDOS-Attacke (DDOS), verwendet wird, muss der Fachdienst die IP-Adresse des Absenders in eine Blacklist eintragen, um sich vor weiteren Angriffen von dieser Adresse ausgehend zu schützen. Der Fachdienst muss diese IP-Adresse nach einer Stunde wieder aus der Blacklist entfernen, wenn von der gefilterten IP-Adresse keine weiteren Angriffe mehr verzeichnet werden, damit im Falle dynamisch vergebener IP-Adressen diese wieder genutzt werden kann.

5.3 IDP-Dienst als Authorization Server

Der IDP-Dienst stellt den authentifizierten Entitäten ACCESS_TOKEN aus, mit welchen diese den Zugriff auf die im Claim des Fachdienstes bereitgestellten Systeme realisieren können.

Hinweis: Hierbei können je nach Anwendung unterschiedliche Verfahren zum Einsatz kommen. Im Fall des E-Rezeptes wird der ACCESS_TOKEN im Rahmen des VAU-Protokolls übertragen und ist damit ausreichend geschützt.

Hinweis: Als personenbezogenes Attribute gelten gemäß Tabelle: TAB_IDP_DIENST_0005 die Claims given_name, family_name, display_name, organizationName, professionOID und idNummer.

5.4 Abstimmen der Rahmenbedingungen "ACCESS_TOKEN"-Gültigkeit

Die Registrierung eines Fachdienstes erfolgt in enger Abstimmung zwischen Fachdienst und IDP-Dienst. Fachdienste geben dem IDP-Dienst gegenüber bei der Registrierung an, mit welchen Gültigkeitszeiträumen die ACCESS_TOKEN und REFRESH_TOKEN ausgestattet werden sollen. Der Fachdienst selbst sieht vor, welche Nutzergruppe generell Zugriff erhalten, indem nur für diese Nutzer Claims vorgesehen sind. Registriert beispielsweise ein Fachdienst für die von ihm bereitgestellten Fachdaten kein Claim für Versicherte, können diese am Authorization-Endpunkt auch kein ACCESS_TOKEN zu diesem Fachdienst erhalten.

5.5 IDP-Dienst als OIDC IDP

Auf Anfrage eines Anwendungsfrontend erstellt der Fachdienst einen Authorization Request für den zentralen IDP-Dienst. Der Authorization Request wird vom Anwendungsfrontend an das Authenticator-Modul übergeben und beim zentralen IDP-Dienst eingereicht. Nach erfolgreicher Authentifizierung übergibt der IDP-Dienst einen AUTHORIZATION_CODE an das Authenticator-Modul zurück. Dieser Code wird über das Anwendungsfrontend an den Fachdienst weitergereicht. Der Fachdienst  erhält dann vom IDP-Dienst durch Vorlage des Codes einen ID_TOKEN. Durch Auswertung des ID_TOKEN kann der Fachdienst Zugriffsentscheidungen treffen. Der Fachdienst kann daraufhin beispielsweise selbst Access-Token für das aufrufende Anwendungsfrontend ausstellen. Dieses Vorgehen hat den Vorteil das die Personenbezogenen Daten zur keiner Zeit im Anwendungsfrontend selbst vorliegen und auch ein Abfangen auf den Übertragungswegen zum Frontend oder Authenticator keine Möglichkeit zur Kenntnisnahme der Daten bietet. Diese werden nur verschlüsselt an die Quelle des Authorization Request übergeben.

Durch die Umsetzung der Funktionalität durch den Fachdienst entfallen alle Anforderungen aus gemSpec_IDP_Frontend Kapitel 8.1 und 8.2. Stattdessen erfüllt das Anwendungsfrontend allein eine Weiterleitungsfunktion entsprechend Kapitel 8.4.

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 Telematikinfrastruktur.

6.5.2 Weitere Dokumente