gemSpec_IDP_FD_V1.0.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation Identity Provider – Nutzungsspezifikation
für Fachdienste

    

     

      
Version
      
1.0.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
30.06.2020
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_IDP_FD
     
    

Dokumentinformationen

Änderungen zur Vorversion

Es handelt sich um die Erstversion des Dokumentes.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test und Betrieb des Produkttyps gemSpec_IDP_FD.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller und Anbieter von Fachdiensten und Fachanwendungen, welche die Funktion des Identitäts-Prüfungs-Dienst (IdP-Dienst) nutzen 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 dem Produkttyp IdP-Dienst bereitgestellten (angebotenen) Schnittstellen sowie die Bedingungen, unter denen diese zu nutzen sind. Weitere Details zu den benutzten Schnittstellen werden in der Spezifikation des IdP-Dienstes beschrieben. Auf die entsprechenden Dokumente wird referenziert (siehe auch Anhang 6).

Die vollständige Anforderungslage für den Produkttyp IdP-Dienst ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten; diese sind in dem Produkttypsteckbrief des Produkttyps IdP-Dienst verzeichnet.

Die vollständige Anforderungslage für den Produkttyp, welcher den Identitäts-Prüfungs-Dienst nutzt, ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten; diese sind in dem Produkttypsteckbrief des jeweiligen Produkttyps (IdP-Dienst bzw. IdP-Frontend) verzeichnet.

Nicht Bestandteil des vorliegenden Dokumentes sind die Festlegungen und Anforderungen, welche sich an 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

In der Telematikinfrastruktur (TI) werden zahlreiche Fachdienste angeboten. Um es den Anbietern von Fachdiensten (Service Provider) zu ermöglichen, den Aufwand für die Kontrolle der Zugriffsberechtigung auf ein Minimum zu beschränken, bietet die TI einen Identitäts-Prüfungs-Dienst (IdP-Dienst) an. Der IdP-Dienst stellt durch gesicherte JSON Web Token attestierte Identitäten aus und ist Garant dafür, dass deren aktuelle Gültigkeit gegeben ist.

Aufgabe des IdP-Dienstes ist es, die von verschiedenen Entitäten vorgetragenen Attribute auf Zugehörigkeit zur TI ebenso wie auf aktuelle Gültigkeit und Integrität zu prüfen. Der IdP-Dienst übernimmt für den Fachdienst die Aufgabe der Identifikation des Nutzers. Zudem bestätigt der IdP-Dienst die Rolle des Nutzers anhand dessen professionOID sowie weiteren für den Fachdienst notwendigen Attributen und fasst diese in einem signierten JSON Web Token ("ID_Token") zusammen. Fachdienste müssen somit keine aufwendige Überprüfung selbst implementieren, sondern können sich darauf verlassen, dass der Besitzer des bei ihnen eingereichten "ID_TOKEN" bereits sicher identifiziert wurde, und dass dessen vorgetragenen Attribute aktuell gültig sind.

Der IdP-Dienst prüft hierbei, ob das vorgetragene X.509-nonQES-Signatur-Zertifikat der verwendeten Prozessor-Chipkarte (eGK oder eHBA sowie ggf. SMC-B) für die vorgesehene Laufzeit des Token zeitlich gültig ist, dessen Integrität sichergestellt ist und ob andere Gründe (z.B. Widerruf, Sperrung) vorliegen, welche eine Token-Herausgabe verhindern.

Der IdP-Dienst wird nur solche "ID_TOKEN" ausstellen, welche auf gültigen AUT-Zertifikaten (C.CH.AUT, C.HP.AUT oder C.HCI.AUT) basieren, und wird nur Attribute bestätigen, welche im vorgetragenen Zertifikat enthalten sind.

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)
• Abstimmen des Claims mit dem IdP-Dienst (organisatorischer Prozess gemäß Abschnitt 5.1.1)
• Token Introspection (siehe Abschnitt ) 
• Abstimmen der Rahmenbedingungen für die Gültigkeit von "ID_TOKEN" (siehe Abschnitt 5.4)

Alle Fachdienste müssen zur Absicherung der JSON Web Token gegen Einsichtnahme durch Dritte den Transportweg zusätzlich mit TLS gemäß [gemSpec_Krypt] absichern. Dies ist erforderlich, da es sich um im höchsten Maße schützenswerte  Daten handelt und der Datenverkehr auf Proxy Servern ansonsten unverschlüsselt vorliegen würde. Die Absicherung mit TLS Transportweg-Sicherung erfolgt auf Seiten des Dienstanbieters. Der Fachdienst muss daher sowohl im Internet als auch innerhalb der TI über ein entsprechend innerhalb der Domäne, in der sich der jeweilige Nutzer bewegt, ohne weitere Umstände überprüfbares TLS-Serverzertifikat verfügen. Innerhalb der TI werden Fachdienste mit TLS-Serverzertifikaten ausgestattet, welche in der gesamten Zertifikatskette bis zur Root-CA geprüft werden können. Im Internet müssen die Fachdienste durch ein öffentlich prüfbares Serverzertifikat gesichert werden.

Fachdienste sind Nutzer des IdP-Dienstes und verwenden die vom IdP-Dienst ausgegebenen "ID_TOKEN", um Nutzern Zugriff auf die von ihnen bereitgestellten geschützten Ressourcen zu gewähren.

3 Systemkontext

3.1 Akteure und Rollen

Die Beschreibung der einzelnen Akteure und Rollen ist im Dokument [gemSpec_IDP_Dienst] enthalten.

3.2 Nachbarsysteme

Aus Sicht des Fachdienstes sind die Nachbarsysteme primär das Endgerät des Nutzers, da dieser neben dem Anmeldeprozess auch die angebotenen Fachdienste nutzen möchte. Als weiteres Nachbarsystem ist der IdP-Dienst mit der Schnittstelle für Token Introspection zu sehen. Dieser bietet dem Fachdienstbetreiber zudem die Möglichkeit, die Subject Session eines Nutzers in Frage zu stellen, sodass diese beendet wird.

4 Registrierung des Fachdienstes beim IdP-Dienst

Fachdienste MÜSSEN sich beim IdP-Dienst registrieren,

Da ein Nutzer eine Session nur wenige Sekunden vor Ablauf der Gültigkeit des aktuell verwendeten Schlüssels einen längere Zeit andauernden Prozess initiieren kann, muss die Gültigkeit des serverseitig verwendeten Schlüssels die doppelte Lebensdauer aufweisen wie die des Nutzers. Nur so ist gewährleistet, dass der Nutzer in jedem Fall die ihm möglicherweise durch einen Fachdienst zugesicherte Verbindungsdauer von 24 Stunden ohne Schlüsselwechsel erreichen kann.

Der IdP-Dienst bietet die URIs zu den registrierten Adressen des Fachdienstes sowie den öffentlichen Schlüsseln im Discovery Document gemäß [RFC8414] bzw. [OIDC Discovery] an (siehe auch gemSpec_IDP_Dienst#Übergreifende Festlegungen). 

4.1 Inhalte des Claims

Inhalte eines Claims sind diese, 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. für die SMC-B [gemSpec_PKI # 5.3 Ausweis einer Organisation/Einrichtung des Gesundheitswesens] in Frage.

Der IdP-Dienst benötigt im Claim die Informationen, welche Attribute vom Fachdienst im "ID_TOKEN" erwartet werden, damit dieser für die von Fachdiensten angebotenen Dienste ein im jeweiligen Claim des Fachdienstes beschriebenes "ID_TOKEN" ausstellen kann. Das Claim beschreibt die für diesen Fachdienst (das Claim wird pro Fachdienst in einem organisatorischen Prozess gesondert abgestimmt) abgestimmten Attribute 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, für welche Schnittstelle das später auf Basis des Claims ausgestellte "ID_TOKEN" verwendet werden kann. Gemeinhin ist das die für den Fachdienst registrierte URL, wobei in externe (URL's für die Erreichbarkeit aus dem Internet) und interne (URL's für die Erreichbarkeit innerhalb der TI) URL unterschieden werden muss.

Das Attribut "sub" beschreibt das Subjekt, mit welchem der Fachdienst kommuniziert. Anhand dieses Attributes lassen sich Vorgänge einer bestimmen Entität zuordnen. Die Zuordnung erfolgt in Verbindung mit der professionOID der agierenden Entität.

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 Claims erfolgt grundsätzlich gemäß [rfc7519 # section-4]
  
• Beispiel-Wert des Attributes "iss": "https://erp.telematik/pfad/login"
• Das Attribut "iss" wird durch den IdP-Dienst befüllt.
• Das Attribut "sub" wird mit den Informationen aus dem Signaturzertifikat durch den IdP-Dienst befüllt.
• Das Attribut "professionOID" des Leistungserbringers wird durch den IdP-Dienst befüllt. Andere als die in dieser Tabelle aufgeführten OID sind in diesem Attribut nicht zulässig.
• Das Attribut "jti" wird auch zur Sperrung des "ID_TOKEN" in Störfällen verwendet.
  Anhand des Attributs "jti" lassen sich "ID"- und "REFRESH-TOKEN" einem bestimmten Vorgang zuordnen. Die eindeutige Token-ID aus dem Parameter "jti" wird auch zur Sperrung des "ID_TOKEN" in Störfällen verwendet.

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 "sub" wird mit den Informationen aus dem Signaturzertifikat durch den IdP-Dienst befüllt.
• 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 "jti" wird auch zur Sperrung des "ID_TOKEN" in Störfällen verwendet. Anhand des Attributs "jti" lassen sich Zugriffs- und Refresh-Token einem bestimmten Vorgang zuordnen. Die eindeutige Token-ID aus dem Parameter "jti" wird auch zur Sperrung des "ID_TOKEN" in Störfällen verwendet.

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 "sub" wird mit den Informationen aus dem Signaturzertifikat durch den IdP-Dienst befüllt.
• 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 "jti" wird auch zur Sperrung des "ID_TOKEN" in Störfällen verwendet. Anhand des Attributes "jti" lassen sich Zugriffs- und Refresh-Token einem bestimmten Vorgang zuordnen. Die eindeutige Token ID aus dem Parameter "jti" wird auch zur Sperrung des "ID_TOKEN" in Störfällen verwendet.

Möglicher Inhalt eines durch den IdP-Dienst befüllten ID_TOKEN einer Institution/Organisation, angereichert mit den im Claim vereinbarten Attributen am Beispiel E-Rezept, wie es im Attribut "jti" erkennbar ist. Als Trennzeichen zwischen den einzelnen Attribut-Wert-Paaren ist ein Komma "," vorgesehen. Nicht nummerische Werte sind in doppelte Anführungszeichen '"' zu setzen. Innerhalb eines Attribut-Wertes sind Aufzählungen durch Doppelpunkte ":" und Wertegruppen durch Komma "," zu trennen. Werte innerhalb eines Attributs können verschachtelte JSON Web Token enthalten. Diese sind durch Eingrenzung mit geschweiften Klammern "{}" einzugrenzen. 

Das im folgenden Beispiel verwendete Schlüsselmaterial lautet:

Privater Schlüssel des IdP-Dienstes "PRK_TOKEN"

MIG2AgEAMBAGByqGSM49AgEGBSuBBAAiBIGeMIGbAgEBBDAamStb0Xep3y3sWw2u
SSAdUPkgQ9Rvhlnx8XEVOYy2teh69T0on77ja02m03n8t8WhZANiAARUNSar38Rz
lKPyZFsNSGUanzpNRth0C+MikVEH8FAlDHMMpAs34dyF4IK0uxgbiEe9bQ+ieLrl
6xwFR0yaTivuwoyXC+ScGUnwnpaXmid6UUgw4ypbneHsaKuZ9JLdMAo=

Öffentlicher Schlüssel des IdP-Dienstes "PUK_TOKEN"

MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEVDUmq9/Ec5Sj8mRbDUhlGp86TUbYdAvj
IpFRB/BQJQxzDKQLN+HcheCCtLsYG4hHvW0Poni65escBUdMmk4r7sKMlwvknBlJ
8J6Wl5onelFIMOMqW53h7GirmfSS3TAK

Der Zeitstempel "exp" liegt 300 Sekunden nach dem Erstellungszeitpunkt des Token "iat". Das Attribut "jti" beinhaltet die Kennzeichnung des Providers, einen 20 Ziffern langen Zufallswert sowie die mit dem Token beantragten Rechte.

Die folgenden Attribute sind mit Beispielen befüllt.

{

"iss": "https://idp1.telematik.de/jwt",
"sub": "3-15.1.1.123456789",
"professionOID": "1.2.276.0.76.4.50",
"nbf": 1585336956,
"exp": 1585337256,
"iat": 1585336956,
"name": "Institutions oder Organisations-Bezeichnung",
"jti": "<IDP>_01234567890123456789",
"typ": "https://erp.telematik.de/login"

}

Aus den im Beispiel aufgeführten Attributen ergibt sich unter Verwendung obigen Schlüsselmaterials das folgende Token:

Base64-Darstellung des Token Header bestehend "alg" = "ES256" und "typ" = "JWT"

eyJhbGciOiJFUzM4NCIsInR5cCI6IkpXVCJ9

Trennzeichen (Punkt) gefolgt vom base64 codierten Payload des mit Parametern befüllten Claims

eyJpc3MiOiJodHRwczovL2lkcDEudGVsZW1hdGlrLmRlL2p3dCIsInN1YiI6InJmYzkyMjptZWluZVRlbGVtYXRp
lEQHRlbGVtYXRpay5kZSIsIm9pZCI6IjEuMi4yNzYuMC43Ni40LjQ5IiwibmJmIjoxNTg1MzM2OTU2LCJleHAiOj
1ODUzMzcyNTYsImlhdCI6MTU4NTMzNjk1Niwidm4xIjoiSGFucyIsIm5uMSI6Ild1cnN0IiwianRpIjoiYXZhcnR
XzAxMjM0NTY3ODkwMTIzNDU2Nzg5IGVSUDpyZWFkLGRlbGV0ZSIsInR5cCI6Imh0dHBzOi8vZXJwLnRlbGVtYXRp
ay5kZS9sb2dpbiJ9

Trennzeichen (Punkt) gefolgt von der Signatur des Tokens

NwlB-Qd2eniyqCjJFzEohC227QJ4m2ar0_ar1xUn-Ld29XFxUyxY6L-orZR-rtQhpEcR6QiZDqzhN9tauDRqQ-jpoGdcgjpVj0IwHxb9sc3ckOLKGaIFUbcEZNQ2R0ox

5 Administratives Logoff

Bekommt ein Fachdienst Kenntnis davon, dass ein "ID_TOKEN" zur Durchführung eines Angriffs (z.B. DDOS-Attacke) verwendet wird, DARF der Fachdienst die Token ID verwenden, um damit eine sofortige Löschung des "ID_TOKEN" und damit verbundener "REFRESH_TOKEN" durchzusetzen.

Hierbei wird die zwischen IdP-Dienst und Authenticator sowie Anwendungsfrontend als Basis genutzte Subject Session eliminiert, woraufhin alle darauf basierenden Token ungültig werden. Der Fachdienst kann hiervon nur durch eine Token Introspection Kenntnis erhalten. Es ist daher dringend angeraten, jedoch nicht zwingend erforderlich, vor der Annahme und Verwendung der "ID_TOKEN" eine Token Introspection durchzuführen.

Diese Maßnahme soll nur genutzt werden, wenn es unbedingt erforderlich ist und der Missbrauch des "ID_TOKEN" offensichtlich ist. Dies ist z.B. der Fall, wenn das "ID_TOKEN" von unterschiedlichen URI oder mehrfach nacheinander in hoher Frequenz eingereicht wird.

Die folgenden Anforderungen sind nicht durch die verwendeten Standards (siehe [gemSpec_IDP_Dienst] und [gemSpec_IDP_Frontend]) abgedeckt. Es ist Aufgabe des IdP-Dienstes und der Fachdienste, Angriffe durch ein befallenes oder korruptes Endgerät zu vereiteln. Da der Standard hierzu keine valide Maßnahme bietet, stehen zwei alternative Umsetzungsmaßnahmen zur Auswahl, wovon beide umgesetzt werden sollen, um das höchstmögliche Maß an Kontrolle zu gewährleisten.

Hinweis: Das Löschen der gesamten Subject Session erfordert am Endgerät des Nutzers das erneute Registrieren des Authenticators und des Anwendungsfrontend beim Authorization-Endpunkt.

6 Token Introspection

Der Fachdienst muss die Möglichkeit haben und ist ebenso dazu verpflichtet, die Gültigkeit eines vorgetragenen "ID_TOKEN" zu prüfen. Diese Prüfung hat mindestens einmal im Zeitrahmen der Gültigkeit des "ID_TOKEN" zu erfolgen. Die Prüfung kann häufiger erfolgen, soll aber zusätzlich nur dann durchgeführt werden, wenn ein begründeter Verdacht (z.B. Token-Missbrauch) vorliegt.

Für die Token Introspection bietet der IdP-Dienst gemäß [RFC7662] eine entsprechende Schnittstelle an, bei welcher Fachdienste, gegen Vorlage der ID des zu untersuchenden "ID_TOKEN", dessen aktuellen Gültigkeitsstatus überprüfen können. Die URI des Token Introspection-Endpunktes "URI_INT" erfährt der Fachdienst aus dem Discovery Document, welches beim Systemstart eingelesen und ausgewertet werden muss.

Die Anfrage (Token Introspection Request) erfolgt gemäß [RFC7662 # section-2.1], wobei dem IdP-Dienst die folgenden Informationen bereitgestellt werden müssen:

6.1 Token Introspection Request

Da es sich bei den von Fachdiensten zur Prüfung eingereichten Token-Typen ausschließlich um "ID_TOKEN" handelt, ist die Übergabe des Hinweises nicht erforderlich.

Der IdP-Dienst, welcher das Token ausgegeben hat, überprüft anhand der eingereichten Token-ID die mit der Beantragung eingereichten Attribute (Signatur-Zertifikat) und bestätigt dem anfragenden Fachdienst gemäß [RFC7662 # section-2.2] die angefragten Attribute (siehe auch [gemSpec_IDP_Dienst # Abschnitt 5.5 Token Introspection-Endpunkt]).

6.2 Token Introspection Response

Die Token Introspection Response kann weitere vom Fachdienst nicht erwartete Attribute enthalten.

Auszug einer positiven Token Introspection (Beispiel):

HTTP/1.1 200 OK Content-Type:
application/json
{
"active": true,
"client_id": "<IDP>_01234567890123456789",
...
}

Beispiel einer negativen Token Introspection

HTTP/1.1 200 OK Content-Type:
application/json
{
"active": false
}

7 "ID_TOKEN"

Der IdP-Dienst stellt den berechtigten und überprüften Entitäten "ID_TOKEN" aus, mit welchen diese den Zugriff auf die im Claim des Fachdienstes bereitgestellten Systeme realisieren können.

Die URI "URI_PUK_TOKEN", unter welcher der "PUK_TOKEN" verfügbar ist, ist im Discovery Document veröffentlicht.

Zusätzliche Prüfungsmechanismen sind im Abschnitt Token Introspection und Administratives Logoff beschrieben.

8 Abstimmen der Rahmenbedingungen "ID_TOKEN"-Gültigkeit

Die Registrierung eines Fachdienstes erfolgt in enger Abstimmung zwischen Fachdienst und IdP-Dienst. Hierbei werden Regelungen getroffen, welchem Akteur (zu erkennen an deren im Antrag übermittelter professionOID) welche Rechte zugesprochen werden sollen. Ärzte z.B. müssen die Möglichkeit haben, neue E-Rezepte einzustellen, Versicherte dürfen diese jedoch nur auflisten, abrufen oder löschen. Fachdienste geben dem IdP-Dienst gegenüber bei der Registrierung an, welche professionOID mit welchen Rechten und Gültigkeitszeiträumen mit "ID_TOKEN" oder "REFRESH_TOKEN" ausgestattet werden sollen. Der Fachdienst selbst sieht vor, welche Nutzer generell Zugriff erhalten, indem nur für diese Claims vorgesehen sind. Registriert ein Fachdienst für die von ihm bereitgestellten Protected Server z.B. kein Claim für Versicherte, können diese am Authorization-Endpunkt auch kein "ID_TOKEN" und infolge dessen auch kein "REFRESH_TOKEN" zu diesem Fachdienst erhalten.

Aus der folgenden Liste geht hervor, welche Token-Typen durch einen Fachdienst im Claim vereinbart sind und wie sich deren Lebenszyklus zusammensetzt [].

Beschreibung am Beispiel E-Rezept (eRp)

Der Fachdienst E-Rezept sieht vor, dass Nutzer mit "ID_TOKEN" und "REFRESH_TOKEN" ausgestattet werden. Die Gültigkeit des "REFRESH_TOKEN" beträgt 28.800 Sekunden = 8 Stunden und ist im Attribut "maxRefresh" hinterlegt.

Für diesen Zeitraum darf das mit der Anmeldung verbundene Anwendungsfrontend nach der Authentisierung gegen das zugelassene Authentisierungsmerkmal "ID_TOKEN" am TOKEN_ENDPOINT einfordern und beim Fachdienst eRp vorstellig werden.

Die Gültigkeitsdauer der mit einem "REFRESH_TOKEN" oder dem "ACCESS_CODE" erworbener "ID_TOKEN" beträgt im Beispiel E-Rezept 300 Sekunden = 5 Minuten.

Berechtigung: Die Spalte 'Berechtigung' beinhaltet in Abhängigkeit der professionOID des vorgetragenen Signaturzertifikates die damit verbundenen Berechtigungen. Sind diese unterschiedlich, muss für jede professionOID ein eigenes Claim mit dem IdP-Dienst abgestimmt werden.

9 Anhang A – Verzeichnisse

9.1 Abkürzungen

9.2 Glossar

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

9.3 Abbildungsverzeichnis

9.4 Tabellenverzeichnis

9.5 Referenzierte Dokumente

9.5.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert; Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument jeweils gültige Versionsnummern sind in der aktuellen, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

9.5.2 Weitere Dokumente

Die weiteren zu beachtenden Dokumente sind im zentralen Dokument des Produktyps IdP-Dienst [ ] beschrieben.