gemSpec_IDP_FD_V1.1.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation Identity Provider – Nutzungsspezifikation
für Fachdienste

    

     

      
Version
      
1.1.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
12.11.2020
     
     

      
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

Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test und Betrieb der Schnittstellen von Fachdiensten, die den Identity Provider-Dienst (IdP-Dienst) nutzen wollen.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller und Anbieter von Fachdiensten und Fachanwendungen, welche die Funktion des 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 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 den weiteren Konzept- und Spezifikationsdokumenten; diese sind in dem Produkttypsteckbrief des Produkttyps IdP-Dienst 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. 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 1: 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 Identifikation des Nutzers. Der IdP-Dienst fasst die professionOID sowie weitere für den Fachdienst notwendige Attribute in signierten JSON Web Token ("ID_TOKEN", "ACCESS_-" und "SSO_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 identifiziert 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)
• Abstimmen der Claims (Key/Value-Paare im Payload eines JSON Web Token) mit dem IdP-Dienst (organisatorischer Prozess gemäß Abschnitt 5.1.1)
• Abstimmen der Rahmenbedingungen für die Gültigkeit von "ACCESS_TOKEN" (siehe Abschnitt 5.4)

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. Innerhalb der TI werden Fachdienste mit TLS-Zertifikaten durch die Komponenten-Public Key Infrastructure (PKI) ausgestattet. Im Internet müssen die Fachdienste durch ein öffentlich prüfbares Serverzertifikat gesichert werden.

Fachdienste sind ebenfalls Nutzer des IdP-Dienstes als Resource Server und sind bei diesem organisatorisch als Open Authorization 2.0 (OAuth 2.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.

3 Systemkontext

Der Systemkontext besteht für den Fachdienst aus dem Identity Provider und dem Anwendungsfrontend.

Der Fachdienst muss beim Identity Provider 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 2: Systemkontext aus Sicht des Fachdienstes

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 OAuth2-Rollen

Nutzer (Rolle: Resource Owner)

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 (Rolle: Resource Server)

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 delegierte Identifikation des Resource Owners.

Anwendungsfrontend/Authenticator-Modul kombiniert in einer Applikation (Rolle: Client)

Der Client  greift mit dem Authenticator-Modul und dem Anwendungsfrontend (OIDC Relying Party bzw. OAuth2 Client) 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) ausgeführt werden.

IdP-Dienst (Rolle: Authorization Server)

Der Authorization Server authentifiziert den Resource Owner (Nutzer) und stellt "ID_TOKEN", "ACCESS_TOKEN" und "SSO_TOKEN" für den vom Resource Owner erlaubten Anwendungsbereich (SCOPE) aus, welche dieser wiederum beim Fachdienst einreicht.

Tabelle 2: TAB_IDP_FD_0002 Kurzbezeichnung der Schnisttstellen des IdP-Dienstes

Weitere Akteure im Kontext IdP-Dienst sind:

Fachdaten (Rolle: Protected Resource)

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

3.2 Nachbarsysteme

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 Identifikation des Nutzers wird anhand einer Smartcard und der Auswertung des vom Authenticator-Modul an den IdP-Dienst übergebenen Authentifizierungszertifikats (aus der Smartcard) sichergestellt.

Fachdienste registrieren sich über einen organisatorischen Prozess beim IdP-Dienst.

In der nächsten Abbildung werden die Systeme, welche keine direkten Kommunikationsbeziehungen mit Fachdiensten unterhalten, grau angedeutet:

Abbildung 3: Nachbarsysteme des Fachdienstes

4 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 neben einer sprechenden Fachdienstbezeichnung eine statische IP-Adresse, auf deren Basis die URI adressiert wird. Die URI des Fachdienstes "URI_FD" muss dem Authorization Server, welcher Teil des IdP-Dienstes ist, bekanntgegeben werden.

Hinweis: 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.

4.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 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 "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 "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 "ID_TOKEN" und "SSO_TOKEN" einem bestimmten Vorgang zuordnen.

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 zugesprochenendiscovery 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 Zugriffs- und SSO-Token einem bestimmten Vorgang zuordnen.

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_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 Attributes "jti" lassen sich "ACCESS_TOKEN" und "SSO_TOKEN" einem bestimmten Vorgang zuordnen.

Das folgende Beispiel eines vom IdP-Dienst ausgestellten "ACCESS_TOKEN beschreibt die möglichen Inhalte anhand des Beispiels E-Rezept. Grundsätzlich besteht der Aufbau aus einem Header, dem Payload und der Signatur. Die jeweiligen Teile sind durch das Trennzeichen Punkt "." voneinander separiert. 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 Tokens "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": "RabcUSuuWKKZEEHmrcNm_kUDOW13uaGU5Zk8OoBwiNk",
"professionOID": "1.2.276.0.76.4.50",
"nbf": 1585336956,
"exp": 1585337256,
"iat": 1585336956,
"given_name": "der Vorname",
"family_name": "der Nachname",
"organizationName": "Institutions- oder Organisations-Bezeichnung",
"idNummer": "3-15.1.1.123456789",
"jti": "<IDP>_01234567890123456789",
"aud": "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 aus den JWT-Standard-Headern (siehe [RFC7519 # section-3.1]) "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 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.

6 "ACCESS_TOKEN"

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.

7 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 "SSO_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.

Beschreibung am Beispiel E-Rezept (eRp):

Der Fachdienst E-Rezept sieht vor, dass Nutzer mit "ACCESS_TOKEN" und "SSO_TOKEN" ausgestattet werden. Die Gültigkeit des "SSO_TOKEN" beträgt immer 43.200 Sekunden = 12 Stunden.

Für diesen Zeitraum braucht das Authenticator-Modul keine erneute Nutzer-Authentifizierung durchzuführen, um beim IdP-Dienst einen neuen "ACCESS_TOKEN" für den Fachdienst zu erlangen.

Die Gültigkeitsdauer des "ACCESS_TOKEN" beträgt im Beispiel E-Rezept 300 Sekunden = 5 Minuten.

8 Anhang A – Verzeichnisse

8.1 Abkürzungen

8.2 Glossar

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

8.3 Abbildungsverzeichnis

8.4 Tabellenverzeichnis

8.5 Referenzierte Dokumente

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

8.5.2 Weitere Dokumente