Vom IDP-Dienst unterstützte claims & scopes
Unterstütze claims
- given_name: Zustimmung zur Verarbeitung des Vornamens
- family_name: Zustimmung zur Verarbeitung des Nachnamens
- idNummer: Zustimmung zur Verarbeitung der Id (z.B. Krankenversichertennummer, Telematik-Id)
- professionOID: Zustimmung zur Verarbeitung der Rolle
- organizationName: Zustimmung zur Verarbeitung der Organisationszugehörigkeit
Der IDP-Dienst liefert nach korrekter Authentifizierung einen ID-Token an den aufrufenden Fachdienst zurück. Die Inhalte (claims), welche der IDP-Dienst zu einer angefragten Identität im ID-Token liefern kann, sind auf die Daten beschränkt, welche in den jeweiligen Zertifikaten der zugrunde liegenden Smartcards enthalten sind.
Folgende Tabelle listet die möglichen Attribute und ihre Quelle im Zertifikat auf:
claim | Leistungserbringer (HBA) (Quellzertifikat: C.HP.AUT) | Leistungserbringerinstitution (SMC-B) (Quellzertifikat: C.HCI.AUT) | Versicherte (eGK) (Quellzertifikat: C.CH.AUT) |
|---|---|---|---|
given_name (Zertifikatsfeld) | Vorname des HBA-Inhabers (givenName) | Vorname des Verantwortlichen/Inhabers (givenName) | Vorname des Versicherten (givenName) |
family_name (Zertifikatsfeld) | Nachname des HBA-Inhabers (surname) | Nachname des Verantwortlichen/Inhabers (surname) | Nachname des Versicherten (surname) |
| organizationName (Zertifikatsfeld) | leer (organizationName) | Organisationsbezeichnung (commonName) | Herausgeber (organizationName) |
| professionOID (Zertifikatsfeld) | professionOID (Admission/professionOID) | professionOID (Admission/professionOID) | professionOID (Admission/professionOID) |
idNummer (Zertifikatsfeld) | Telematik-ID (Admission/registrationNumber) | Telematik-ID (Admission/registrationNumber) | unveränderlicher Anteil der KVNR (organizationalUnitName) |
Unterstütze scopes
Jeder beim IDP-Dienst registrierte Fachdienst hat einen eindeutigen scope, der bei der Registrierung durch die gematik vergeben wird. Alle diese scopes sind im Discovery Document in der Liste scopes_supported als unterstützte scopes enthalten. Die Zuordnung der claims zu den (fachdienstspezifischen) scopes erfolgt ebenfalls im Rahmen des Registrierungsprozess des Fachdienstes beim IDP-Dienst. Die (fachdienstspezifischen) scopes mappen auf jeweils eine Zieladresse, unter welcher der Fachdienst erreichbar ist. Diese Adresse entspricht der audience (aud) des Fachdienstes. Die folgende Tabelle zeigt den Zusammenhang zwischen Fachdienst, scope, aud und claims.
Fachdienst | scope | aud | zugeordnete claims |
|---|---|---|---|
| E-Rezept | e-rezept | https://erp-ref.zentral.erp.splitdns.ti-dienste.de/ | given_name, family_name, idNummer, professionOID, organizationName |
| Fhir-VZD | fhir-vzd | https://fhir-directory-ref.vzd.ti-dienste.de/signin-gematik-idp-dienst | idNummer, professionOID |
| DEMIS | fh-fokus-demis | https://demis.fokus.fraunhofer.de/auth/realms/PUB/broker/gematik/endpoint | given_name, family_name, idNummer, professionOID, organizationName |
Registrierung, Änderung und Abmeldung von Clientsystemen
Bevor der IDP-Dienst von Fachdiensten oder durch deren Anwendungsfrontends genutzt werden kann, ist eine organisatorische Registrierung dieser Dienste notwendig. Die organisatorische Registrierung erfolgt über das Einreichen eines Registrierungsformulars (Service-Name: "Organisatorische Registrierung am IDP Dienst exkl. PVS").
Der organisatorische Prozess unterstützt neben der Registrierung (Neuanlage) auch Änderungen von Registrierungsdaten und Löschungen.
Ansprechpartner für eine Registrierung sind unter IDP-Registrierung@gematik.de zu erreichen.
Daten zur Registrierung oder Registrierungsänderungen
Für die Registrierung oder Registrierungsänderungen von Fachdiensten oder deren Anwendungsfrontends müssen von diesen Daten bereitgestellt werden:
| Beschreibung | Werte / Beispiele | |||
|---|---|---|---|---|
| 1 | Antragstyp | Mit Antragstyp legt der Antragssteller fest, welche Art von Änderung er mit dem Antrag bezweckt. Der Antragssteller wählt unter folgenden Antragstypen:
| ||
| 2 | Rolle Serviceteilnehmer | Der Antragssteller wählt die Rolle, in welcher der Fachdienst oder das Anwendungsfrontend gegenüber dem IDP-Dienst agiert. Die Rollenzuordnung ist wichtig für die Zuordnung von Eigenschaften. Der Antragssteller wählt unter folgenden Rollen:
| ||
| 3 | redirect_uri | Zu jedem zu registrierenden Anwendungsfrontend muss mindestens eine redirect_uri angegeben werden. Der IDP-Dienst nutzt die in der Anfrage verwendete "redirect_uri" dazu seine Antwort, nach erfolgter Authentisierung, an den Dienst zu übermitteln. Dabei wird der ausgestellte Authorization-Code vom Authenticator-Modul mittels dieser URI an das Anwendungsfrontend weitergeleitet. Der IDP-Dienst prüft zuvor die redirect_uri, die vom Client geliefert werden, gegen die beim ihm registrierten redirect_uris. Das Format muss eine gültige URI gemäß [RFC3986] sein. Es ist also somit möglich, mehrere Anwendungsfrontends für einen Fachdienst gleichzeitig zu registrieren. Eine App ist genau ein Client, d.h. das "E-Rezept Frontend" ist eine App. Es gibt davon im Feld genau EINE, welche in einer Vielzahl von Instanzen betrieben wird. Es gibt zusätzlich viele (ca. 200) PVS (Primärsysteme), welche über einen gesonderten Service Request (RISE_ServiceID_010-012) registriert werden können. Notwendig ist die Angabe der redirect_uri bei jeder erstmaligen Registrierung (Neuanlage) oder Änderung eines Anwendungsfrontends (Rolle Hersteller Anwendungsfrontend). | https://redirect.gematik.de/erezept | |
| 4 | URI_FD | URI_FD ist die URI des Fachdienstes (Root-Pfad). Sie wird in der Kommunikation mit dem IDP-Dienst als eindeutigen Identifier des Fachdienstes verwendet (aud) verwendet. Für die URI-FD gelten die folgenden Kriterien:
Notwendig ist die Angabe der URI_FD bei jeder erstmaligen Registrierung (Neuanlage) Fachdienstes (Rolle Anbieter Fachdienst) oder Änderung der URI_FD des Fachdienstes. Soll die Registrierung eines ein Fachdienstes am IDP-Dienst gelöscht werden, so muss ebenfalls die URI_FD im Antrag mit angegeben werden. | https://erp-ref.zentral.erp.splitdns.ti-dienste.de/ | |
| 5 | claims | Ein Fachdienst erwartet Attribute und Werte in Form von claims. Die claims müssen in der Liste der unterstützten claims enthalten sein. Die vom Fachdienst für Access-Token / ID-Token vorgesehenen Attribute und Werte in Form von claims, welche im Access-Token oder ID-Token aufgenommen werden sollen, werden im Zuge der Registrierung abgestimmt. Hierfür ist je Token aus der Liste der claims zu wählen. ID-Token und Access-Token können weitere claims enthalten. Notwendig ist die Angabe der benötigten claims bei jeder erstmaligen Registrierung (Neuanlage) eines Fachdienstes oder bei Änderung der vom Fachdienst angeforderten claims. | [given_name, family_name, professionOID] | |
| 6 | Lebensdauer eines ausgestellten Access-Tokens | In der Lebensdauer eines ausgestellten Access-Tokens wird festgelegt, wie lange ein Access-Token für Fachdienste oder Anwendungsfrontends gültig sein soll. Hier ist ein Wert von maximal 300 Sekunden erlaubt. Notwendig ist die Angabe des Wertes bei jeder erstmaligen Registrierung (Neuanlage) eines Fachdienstes oder der Änderung des Wertes der Lebensdauer für die Access-Token für einen Fachdienste. | ||
| 7 | client_id | Die client_id wird vom Anbieter des IDP-Dienstes zentral bei der Registrierung eines Anwendungsfrontends am IDP-Dienst vergeben. Sollen Registrierungswerte zum Anwendungsfrontend am IDP-Dienst geändert oder die Registrierung gelöscht werden, so muss ebenfalls die client_id im Antrag mit angegeben werden. |
Antragsstellung
Die Bestellung des Service erfolgt über das zentrale ITSM-System der TI (ZIS). Die Autorisierung erfolgt durch den Servicegeber (RISE) sowie durch gematik.
Auszug aus der Servicebeschreibung der organisatorischen Registrierung von Anwendungsfrontend und Fachdiensten am IDP-Dienst:
Der RISE IDP-Dienst (Identity Provider Dienst) ist der zentrale Dienst zur Benutzer-Authentifizierung für digitale Fachdienste in der Deutschen Telematikinfrastruktur. Nach
erfolgreicher Authentifizierung bekommt der Benutzer (Fachdienst) einen Token. Im Rahmen dieses Service müssen sich Fachdienste und Anwendungsfrontends, welche für
diese Zwecke verwendet werden möchten, am IDP-Dienst registrieren.
Nachfolgend seien die Schritte zur (a) Neuanlage, (b) Änderung und (c) Löschung der organisatorischen Registrierung am IDP-Dienst beschrieben.
Neuanlage
Bevor der IDP-Dienst von Fachdiensten oder durch deren Anwendungsfrontend genutzt werden kann, ist eine organisatorische Registrierung dieser Dienste notwendig. Dazu müssen diese Schritte durchlaufen werden:
- Der Servicenehmer wendet sich an IDP-Registrierung@gematik.de zur Eröffnung des Registrierungsprozess
- Die gematik eröffnet den Service Request und gibt die in "Eingangsdaten" genannten Daten an
- Die gematik nimmt die Autorisierung vor und erstellt eine gematik Anforderungsaufgabe zur Umsetzung durch den Servicegeber
- Der Servicegeber nimmt die Autorisierung vor und bestätigt den Eingang des Service Request und der Anforderungsaufgabe
- Der Servicegeber pflegt die Daten in die jeweilige Umgebung ein
- Der Servicegeber schickt folgende Daten an den Servicenehmer gem. „Bestellung des Services“ als Abschlusskommentar
- Falls es sich um ein Anwendungsfrontend handelt
- Eine client_id zu jedem registrierten Anwendungsfrontend
- Den Downloadpunkt des Discovery Dokuments des IDP-Dienst
- Falls es sich um einen Fachdienst handelt
- Der Wert des "scope" (besteht aus „openid“ + genau einem zusätzlichen scope)
- Den Downloadpunkt des Discovery Dokuments des IDP
- Falls es sich um ein Anwendungsfrontend handelt
- Der Servicegeber informiert den Servicenehmer bzw. gematik, dass die Einpflege erledigt ist durch Meldung der Fertigstellung derAnforderungsaufgabe
- Der Servicenehmer validiert die Daten (siehe “Abschluss und Verifikation”)
Änderung/Löschung
Möchte der Servicenehmer seine Registrierungsdaten ändern oder löschen, so ist der Ablauf identisch mit dem der Neuanlage. Allerdings muss der Servicenehmer bei den Eingangsdaten den eindeutigen Identifier von Anwendungsfrontend oder Fachdienst mit angeben.
Abschluss und Verifikation
Der Servicenehmer sollte nach Abschluss des Registrierungs- bzw. Änderungsprozess technischer validieren, ob der Service Request erfolgreich abgeschlossen wurde. Bezüglich der Auftragslage gilt der Service Request nach 5 Tagen als erfolgreich, auch wenn keine technische Validierung durch den Servicenehmer erfolgt ist.
Identifikation von Clientsystemen im laufenden Betrieb
Der IDP-Dienst verwaltet und steuert den Authentisierungsprozess für Fachdienste (z.B. E-Rezept). Damit kommt ihm eine Relevanz in der Gesundheitsversorgung zu, die sich zum einen in einer hohen Verfügbarkeit und zum anderen in einem hohen Angriffspotential widerspiegelt. Zur Unterstützung der betrieblichen Überwachung des IDP-Dienstes wird die Nutzung der im Feld befindlichen Clientsysteme protokolliert. Dabei ist der Zugriff auf die Schnittstellen des IDP-Dienstes nur durch Primärsysteme der Leistungserbringer, sein eigenes Authenticator-Modul und zugelassene Fachdiensten zulässig. Der Fachdienst (z.B. E-Rezept-Fachdienst) erkennt die Clientsysteme anhand des User-Agent-Header eingehender HTTP-Requests und protokolliert diesen Wert. Ein Client bekommt bei der organisatorischen Registrierung am IDP-Dienst von diesem eine eindeutige client_id zur Nutzung des IDP-Dienstes zugewiesen. Der IDP-Dienst erkennt das vom aufrufenden Nutzer verwendete Clientsystem (Authenticator-Modul, Fachdienst oder Primärsystem) anhand des im HTTP-Request enthaltenen Header-Feld "User-Agent" (gemäß [RFC7231]) und protokolliert diese zur Performance-Rohdatenerfassung. Der IDP-Dienst beantwortet bei fehlendem User-Agent-Header den Request mit dem HTTP-Status-Code 403, damit in der Betriebsüberwachung des IDP-Dienstes die Nutzung unzulässiger Clientsysteme erkannt werden kann. Der IDP-Dienst erkennt in der Kommunikation mit dem Client die vom Clientsystem mitgeteilte Versionsnummer aus dem HTTP-Header User-Agent. Clients können von der Kommunikation mit dem IDP-Dienst ausgeschlossen werden, wenn deren Versionsnummern auf einer geführten Blacklist enthalten sind.
Der IDP-Dienst gibt in diesen Fällen eine entsprechende Fehlermeldung an das Clientsystem. Der Ausschluss von Clients mit bestimmten Versionsnummern erfolgt dabei immer auf Anweisung der gematik.