gemSpec_IDP_FedMaster_V1.3.0_Aend

 

 

 

 

 

Elektronische Gesundheitskarte und Telematikinfrastruktur

 

 

 

 

Spezifikation

Federation Master

 

 

 

   

Version	1.23.0
Revision	829909879335
Stand	Wert nicht konfiguriert05.04.2024
Status	freigegeben
Klassifizierung	öffentlich
Referenzierung	gemSpec_IDP_FedMaster

 

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

 

Inhaltsverzeichnis

Dokumentinformationen

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

1.2 Zielgruppe

1.3 Geltungsbereich

1.4 Abgrenzungen

1.5 Methodik

1.5.1 Anforderungen

1.5.2 Anwendungsfälle und Akzeptanzkriterien

1.5.3 Hinweise

2 Systemüberblick

2.1 Allgemeiner Überblick

2.2 Detaillierter Überblick

2.3 Akteure und Rollen

2.4 Attributbeschreibung

3 Funktionsmerkale

3.1 Anwendungsfälle

3.2 Anwendungsfall - IDP-Liste bereitstellen

3.2.1 Akzeptanzkriterien - IDP-Liste bereitstellen

3.3 Anwendungsfall - Entity Statement bereitstellen

3.3.1 Akzeptanzkriterien - Entity Statement bereitstellen

3.4 Anwendungsfall - Schlüssel verwalten

3.4.1 Akzeptanzkriterien - Schlüssel verwalten

4 Anforderungen an den Produkttyp

4.1 Aufbau und Inhalt des Federation Master Entity Statement

4.2 Organisatorische Prozesse am Federation Master

4.3 Allgemeine Sicherheitsanforderungen

4.4 Sicherheit der Netzübergänge

4.5 Fehlermeldungen

5 Anhang – Verzeichnisse

5.1 Abkürzungen

5.2 Glossar

5.3 Abbildungsverzeichnis

5.4 Tabellenverzeichnis

5.5 Referenzierte Dokumente

5.5.1 Dokumente der gematik

5.5.2 Weitere Dokumente

1 Einordnung des Dokuments

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test und Betrieb des Produkttyps Federation Master. Der Federation Master basiert auf den Standards OpenID Connect (OIDC), Open Authorization 2.0 (OAuth 2) und JSON Web Token (JWT). Der Federation Master ist einerseits der Anker des Vertrauensbereichs der Föderation. Andererseits stellt der Federation Master Schnittstellen bereit, welche Auskunft über die in der Föderation registrierten sektoralen Identity Provider gibt. Die Kernaufgaben des Federation Master sind:

• Verwaltung der öffentlichen Schlüssel aller in der Föderation registrierten Teilnehmer (OpenID Provider (OP) und Relying Party (RP) gemäß Spezifikation [openid-connect-core])
• Validierung von Anfragen über Teilnehmer der Föderation
• Bereitstellung von Schnittstellen für:
  • die Auskunft zum Federation Master (Entity Statement)
  • die Auskunft über Teilnehmer der Föderation
  • die Auskunft über die Liste aller registrierten OpenID Provider (OP)
  • die Registrierung neuer OP und RP
  • das Löschen von nicht mehr benötigten OP und RP.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller und Anbieter, welche die Funktionen des Produkttyps Federation Master der gematik realisieren wollen.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur (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. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

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 sind die Verfahrensschritte zur Erstellung des notwendigen Schlüsselmaterials. Für die Signatur des Entity Statement wird angenommen, dass die OpenID Provider (OP) und Relying Parties (RP) der Föderation ihre innerhalb der TI zu verwendenden Zertifikate für die Transport Layer Security (TLS)-Sicherung über zentrale Plattformdienste der TI beziehen und diese dort auch geprüft werden können.

Als Umsetzungsleitlinie ist [OpenID Connect Core 1.0] und [OpenID Connect Federation1.0] heranzuziehen. 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 ebenso bindend und werden nicht in diesem Dokument beschrieben.

Für weitere Komponenten der TI-Föderation gelten eigene Spezifikationsdokumente:

• sektorale Identity Provider - [gemSpec_IDP_Sek]
• Fachdienste - [gemSpec_IDP_FD]
• Anwendungsfrontend der Fachdienste - [gemSpec_IDP_Frontend].

1.5 Methodik

1.5.1 Anforderungen

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.

1.5.2 Anwendungsfälle und Akzeptanzkriterien

Anwendungsfälle und Akzeptanzkriterien als Ausdruck normativer Festlegungen werden als Grundlage für Erlangung der Zulassung durch Tests geprüft und nachgewiesen. Sie besitzen eine eindeutige, permanente ID, welche als Referenz verwendet werden SOLL. Die Tests werden gegen eine von der gematik gestellte Referenz-Implementierung durchgeführt. 

Anwendungsfälle und Akzeptanzkriterien werden im Dokument wie folgt dargestellt:
<ID> - <Titel des Anwendungsfalles / Akzeptanzkriteriums>
Text / Beschreibung
[<=]

Die einzelnen Elemente beschreiben:

• ID: einen eindeutigen Identifier.
  • Bei einem Anwendungsfall besteht der Identifier aus der Zeichenfolge 'AF_' gefolgt von einer Zahl, 
  • Der Identifier eines Akzeptanzkriteriums wird von System vergeben, z.B. die Zeichenfolge 'ML_' gefolgt von einer Zahl
• Titel des Anwendungsfalles / Akzeptanzkriteriums: Ein Titel, welcher zusammenfassend den Inhalt beschreibt
• Text / Beschreibung: Ausführliche Beschreibung des Inhalts. Kann neben Text Tabellen, Abbildungen und Modelle enthalten

Dabei umfasst der Anwendungsfall bzw. das Akzeptanzkriterium sämtliche zwischen ID und Textmarke [<=] angeführten Inhalte.

Der für die Erlangung einer Zulassung notwendige  Nachweis der Erfüllung des Anwendungsfalls wird in den jeweiligen  Steckbriefen festgelegt, in denen jeweils der Anwendungsfall gelistet ist. Akzeptanzkriterien werden in der Regel nicht im Steckbrief gelistet.

1.5.3 Hinweise

Hinweis auf offene Punkte

2 Systemüberblick

2.1 Allgemeiner Überblick

Zentrales Merkmal des zukünftigen Identity Management der Telematikinfrastruktur ist das Prinzip der Föderation. Die Identitäten werden nicht von einem einzigen zentralen Dienst bereitgestellt, sondern „kollektiv“ durch eine Menge von Identity Providern, für die jeweils die entsprechenden identitätsbestätigenden 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 Identity Provider 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 (Minimal claim Sets, scopes)
• Grundstruktur der Vertrauensbeziehungen der Föderierung (IDP Federation/Trust Chains)
• Einheitliche Verfahren zum Auffinden von sektoralen Identity Providern (IDP Discovery)
• Einheitliche Vertrauensniveaus (Trust Framework).

Die Grundidee der Föderation ist die Erstellung eines Vertrauensraums, in dem verschiedene Anwendungen und Identity Provider abgesichert über Vertrauensketten (Trust chain) miteinander kommunizieren, ohne zuvor über organisatorische Prozesse miteinander verknüpft zu werden. Diese Anwendungen und Identity Provider werden im Folgenden als Teilnehmer der Föderation bezeichnet. Die TI-Föderation baut auf dem Standard [OpenID Connect Federation 1.0] auf. Die Autorisierung und Authentisierung von Anwendungen und Nutzern orientiert sich an den Standards zu OAuth 2.0 und OpenID Connect. Die für die TI zwingend notwendige Identifikation der Nutzer ist nicht Teil der Spezifikation.

Abbildung 1: Überblick TI-Föderation

2.2 Detaillierter Überblick

Die untere Abbildung beschreibt den Systemkontext aus Sicht des Federation Master. Alle sektoralen Identity Provider der Föderation müssen beim Federation Master registriert sein. Ebenso müssen alle Fachanwendungen, welche die bei den Identity Providern hinterlegten digitalen Identitäten nutzen möchten, beim Federation Master registriert sein. Jede teilnehmende Partei inklusive des Federation Master muss ein OpenID Connect spezifikationskonformes Entity Statement bereitstellen.

Die Identity Provider der Föderation stellen sicher, dass Nutzer anfragender Fachdienste identifiziert sind. Ebenso wird sichergestellt, dass die Nutzer den Anwendungen Zugriff auf eine Teilmenge ihrer Daten gewähren (Consent).

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.

Abbildung 2: Systemkontext

Im Prozess der Autorisierung eines Nutzers für eine Anwendung ist der Federation Master als Vertrauensstelle eingebunden. Die Voraussetzung für die Kommunikation zwischen Fachdiensten und sektoralen Identity Providern ist deren Registrierung im Vertrauensbereich der Föderation. Diese initiale Registrierung erfolgt organisatorisch und unabhängig vom späteren Ablauf. 

Voraussetzungen für die Prüfung der beteiligten Komponenten im Kontext eines Nutzungsflows:

• Die aktuellen Signaturschlüssel der beteiligten sektoralen Identity Provider und Fachdienste wurden über einen vom Anbieter bereitgestellten organisatorischen Prozess beim Federation Master hinterlegt.
• Die Entity Statements der beteiligten sektoralen Identity Provider und Fachdienste entsprechen den Vorgaben [OpenID Connect Federation1.0]
• Der Identifier des Federation Master wurde vom Anbieter des Federation Master veröffentlicht.

Das folgende Übersichtsschaubild gibt einen Überblick über das Zusammenspiel der unterschiedlichen Komponenten der Föderation. Grau hinterlegte Schritte sind nicht Bestandteil des Nutzungsflows.

Die Kommunikation des Anwenders über das Anwendungsfrontend mit dem Fachdienst entspricht der OAuth-2.0-Spezifikation ([RFC6749]) mit PKCE ([RFC7636]) und wird hier nicht detailliert beschrieben.

Die Kommunikation zwischen dem Fachdienst (Relying Party) und dem sektoralen Identity Provider (OpenID-Provider) entspricht den Spezifikationen zu OpenID Connect (Final: OpenID Connect Core 1.0) und Pushed Authorization Request (https://datatracker.ietf.org/doc/html/rfc9126) und wird hier nicht detailliert beschrieben.

Abbildung 3: Übersichtsschaubild OIDC Federation

Erläuterungen zur obigen Abbildung:

Die grün dargestellten Komponenten und Schnittstellen sind Gegenstand der vorliegenden Spezifikation. Komponenten und Schnittstellen, welche in der Abbildung grau hinterlegt sind, werden in der vorliegenden Spezifikation nicht weiter betrachtet. 

Hinter den gestrichelt dargestellten Schnittstellen verbergen sich organisatorische Prozesse und Verfahren; die anderen Schnittstellen sind Bestandteil der Abläufe zur Autorisierung und Authentifizierung eines Anwenders im Kontext einer Fachanwendung.

Die organisatorischen Prozesse dienen der Registrierung und Löschung von Teilnehmern der Föderation sowie der Aktualisierung der beim Federation Master hinterlegten TLS-Schlüssel der sektoralen Identity Provider.

Im Ablauf der Autorisierung und Authentifizierung eines Anwenders im Vertrauensraum der Föderation müssen der beteiligte Fachdienst und  der beteiligte sektorale Identity Provider sicherstellen, dass der jeweilige Kommunikationspartner ebenfalls ein Mitglied der Föderation ist. Diese Teilschritte sind in der Abbildung als Federation-Flow gekennzeichnet und grün hinterlegt.

Beide Komponenten laden sich dazu das Entity Statement des Federation Master zur jeweils anderen Komponente herunter unter:

GET /.well-known/openid-federation HTTP/1.1

Host: <host Teilnehmer>

Zur Verifizierung müssen die Komponenten prüfen, ob der jeweils andere Teilnehmer Teil der Föderation ist. Das Entity Statement des Federation Master (HTTP-GET <federation master>/.well-known/openid-federation HTTP/1.1) enthält die URL der API-Schnittstelle des Federation Master. Die Information zu einem Teilnehmer der Föderation kann dann über die API-Schnittstelle des Federation Master geladen werden. Dabei müssen sowohl der Entity Identifier (URL) des Federation Master als auch der des Teilnehmers als Parameter übergeben werden. Der Federation Master liefert ein von ihm signiertes Entity Statement zum angefragten Teilnehmer zurück.

Tabelle 1: Request zur Teilnehmerabfrage an den Federation Master

Jeder Teilnehmer stellt zusätzlich ein selbst signiertes Entity Statement bereit, dessen Schlüssel gegen das durch den Federation Master signierte Statement verifiziert werden.

2.3 Akteure und Rollen

Tabelle 2: Akteure und Rollen

2.4 Attributbeschreibung

Die folgende Tabelle enthält eine Erläuterung zu den Attributen, die in den Entity Statements des Federation Master verwendet werden. Die Attribute entsprechen dem OIDC Standard für Entity-Statements. 

Tabelle 3: Attributbeschreibung

Anforderungen an die konkrete Belegung der Attribute im Entity Statement des Federation Master sind in Kapitel 4.1  beschrieben .

3 Funktionsmerkale

3.1 Anwendungsfälle

Der Federation Master ist eine Komponente, welche in den Kommunikationsfluss bei der Nutzung von Fachdiensten der TI eingebunden ist. Zudem ist der Federation Master an notwendigen organisatorischen Prozesse beteiligt. Folgende Anwendungsfälle dienen der Beschreibung der Anforderungen an den Federation Master:

Tabelle 4: Übersicht über die Anwendungsfälle im Gesamtkontext Federation Master

Abbildung 4: Anwendungsfälle Federation Master

Tabelle 5: Anwendungsfälle Federation Master

Die technischen Anwendungsfälle des Federation Master werden hier im Detail beschrieben. Details zu den organisatorischen Anwendungsfällen des Federation Master finden sich in Kapitel 4.2 Organisatorische Prozesse am Federation Master . Die Ausprägung der Anwendungsfälle anderer Komponenten spielt im Rahmen dieser Spezifikation keine Rolle.

3.2 Anwendungsfall - IDP-Liste bereitstellen

Abbildung 5:  Aktivitätsdiagramm  "Auswahl sektorale Identity Provider"

AF_10100-01 - Bereitstellung Liste registrierter Identity Provider

Tabelle 6: Anwendungsfall "Bereitstellung Liste registrierter Identity Provider"

Attribute	Bemerkung
Beschreibung	Ein Anwender möchte einen in der TI registrierten Fachdienst nutzen. Der Fachdienst muss sicherstellen, dass der Anwender zur Nutzung des Dienstes berechtigt ist. Um die Berechtigung sicherzustellen, MUSS der Fachdienst die Authentifizierung des Anwenders gegenüber einem sektoralen Identity Provider veranlassen. Dazu benötigt der Fachdienst die Information vom Anwender, gegen welchen sektoralen Identity Provider er sich identifiziert hat. Der Fachdienst MUSS in seinem Frontend dem Anwender eine Liste, der in der TI registrierten, sektoralen Identity Provider anzeigen. Diese Liste MUSS sich der Fachdienst vom Federation Master erfragen. Der Federation Master MUSS eine API-Schnittstelle bereitstellen, über die ein Fachdienst die Liste, der in der TI registrierten, sektoralen Identity Provider abfragen kann. Jeder Listeneintrag MUSS mindestens diese Informationen enthalten: eindeutige issuer-id des sektoralen Identity Provider in der TI-Föderation Name des sektoralen Identity Provider in lesbarer Form Logo des sektoralen Identity Provider (wenn vorhanden). Information, ob es sich um einen sektoralen Identity Provider einer gesetzlichen oder privaten KrankekasseKrankenkasse handelt Der Anwender des Fachdienstes MUSS genau einen sektoralen Identity Provider aus der Liste auswählen. Der Fachdienst kann sich die Zuordnung eines Anwenders zu seinem sektoralen Identity Provider speichern, so dass die Abfrage der Liste beim Federation Master nicht bei jeder Anmeldung des Anwenders wiederholt werden muss.
Akteur	Anwender der Fachanwendung
Auslöser	Ein Anwender möchte eine Gesundheitsanwendung der TI (Fachdienst) nutzen. Als Voraussetzung für die Authentifizierung des Anwenders muss dieser auswählen, bei welchem Identity Provider er registriert ist (bei Versicherten - Auswahl der Krankenkasse).
Komponenten	Fachdienst der TI Federation Master
Vorbedingung	Der Fachdienst ist in der TI-Föderation registriert, sein Schlüssel ist dem Federation Master bekannt. Es gibt eine Liste in der TI-Föderation registrierter (sektoraler) Identity Provider, deren Schlüssel sind dem Federation Master bekannt. Der Anwender ist durch einen der (sektoraler) Identity Provider identifiziert worden. Das Entity Statement des Federation Master steht zur Verfügung und die unter dem Attribut idp_list_endpoint benannte URL MUSS aus dem Internet erreichbar sein.  Der Federartion Master hat die Entity Statements aller registrierten (sektoraler) Identity Provider innerhalb der letzten 24h aktualisiert
Ablauf	Im Ablauf der Nutzung eines Fachdienstes (siehe Abbildung  - Aktivitätsdiagramm  "Auswahl sektoraler Identity Provider") findet eine Verzweigung zum Federation Master in dem Fall statt, wenn der Fachdienst die Zuordnung des Anwenders zu seinem IDP nicht kennt. Der Fachdienst sendet einen Request an die URL, welche im Entity Statement des Federation Master unter dem Attribut idp_list_endpoint benannt ist. Der Federation Master nimmt den Request entgegen. Der Federation Master erstellt eine Liste aller registrierten sektoralen Identity Provider. Die Liste MUSS zu jedem sektoralen Identity Provider diese Attribute enthalten: Name der Organisation URI (iss) des sektoralen Identity Provider Logo der Organisation Unterstützte Anwendertypen Information, ob es sich um den sektoralen Identity Provider einer gesetzlichen oder privaten KrankekasseKrankenkasse handelt Der Federation Master MUSS als Response auf die Anfrage des Fachdienstes ein signiertes JSON Web Token senden. Die Header- und Payload-Attribute des JWS MÜSSEN mindestens die in den Tabellen "Liste sektorale Identity Provider - Payload-Attribute des signierten JSON-Web-Token" und "Liste sektorale Identity Provider - Headerattribute des signierten JSON-Web-Token" aufgeführten Attribute enthalten.
Ergebnis	Der Anwender hat aus der Liste, der in der TI registrierten (sektoralen) Identity Provider denjenigen ausgewählt, gegenüber dem er sich zuvor identifiziert hat. Der Fachdienst hat alle Informationen, um die Authentifizierung und Autorisierung durchzuführen.
Akzeptanzkriterien	,
Alternativen	Die Fachanwendung kennt (z.B. aus früheren Sitzungen) den sektoralen Identity Provider des Anwenders. In diesem Fall KANN der Anwendungsfall ausgeführt werden.

 

Tabelle 7: Liste sektorale Identity Provider - Payload-Attribute des signierten JSON-Web-Token

Folgende Werte müssen Bestandteil des Header der vom Federation Master signierten IDP-Liste sein:

Tabelle 8: Liste sektorale Identity Provider - Headerattribute des signierten JSON-Web-Token

[<=]

3.2.1 Akzeptanzkriterien - IDP-Liste bereitstellen

ML-128409 - AF_10100 - Unter idp_list_endpoint benannte URL ist erreichbar und liefert signiertes JWS als Response

Der Request vom Fachdienst an URL, welche im Entity Statement des Federation Master unter dem Attribut idp_list_endpoint benannt ist, wird entgegengenommen und gibt als Response ein signiertes JWS zurück. Das Token ist mit dem privaten Schlüssel des Federation Master signiert und kann vom Fachdienst mit dem öffentlichen Schlüssel des Federation Master verifiziert werden. [<=]

ML-143019 - AF_10100 - Payload des JWS-Token enthält Informationen zu jedem registrierten sektoralen Identity Provider der Föderation

Der Payload des JWS-Token enthält zu jedem in der Föderation registrierten sektoralen Identity Provider die Informationen:

• Organisationsname
• URL, unter welcher das Logo der Organisation abrufbar ist
• URI des sektoralen Identity Provider, welcher dem Identifier (iss) des sektoralen Identity Provider entspricht
• Liste der supporteten Usertype
• Information darüber ob der sektoralen Identity Provider für gesetzliche oder privatversicherte Patienten verwendet wird

[<=]

3.3 Anwendungsfall - Entity Statement bereitstellen

Abbildung 6: Federation Master im Authorization-Flow

Tabelle 9: Federation Master im Authorization-Flow

Hinweis: Eine detaillierte Beschreibung der Verwendung des OAuth- und OIDC-Standards ist nicht Teil dieser Spezifikation. Die diesbezüglichen Schritte im Flow werden nicht weiter erläutert.

AF_10101-01 - Bereitstellung von Informationen zu Teilnehmern der Föderation durch den Federation Master

Tabelle 10: Anwendungsfall "Bereitstellung von Informationen zu Teilnehmern der Föderation durch den Federation Master"

 

Tabelle 11: Teilnehmer Validierung Abfrage - Request-Parameter

Tabelle 12: Teilnehmer Validierung Abfrage  - Response-Payload-Attribute des signierten JSON-Web-Token

Folgende Werte müssen Bestandteil des Header der vom Federation Master signierten Informationen zu Teilnehmern der Föderation sein:
 

Tabelle 13: Teilnehmer Validierung - Response-Header-Attribute des signierten JSON-Web-Token

[<=]

3.3.1 Akzeptanzkriterien - Entity Statement bereitstellen

ML-136402 - AF_10101 - Request von Teilnehmern an die federation_fetch_endpoint benannte URL des Federation Master

Der Request eines in der Föderation registrierten Teilnehmers an die im Entity Statement des Federation Master unter dem claim federation_fetch_endpoint benannte URL SOLL die in der Tabelle "Teilnehmer Validierung Abfrage - Request-Parameter" aufgeführten claims enthalten.  Ist der aud-Parameter im Fetch Entity-Statement-Request des anfragenden Teilnehmers nicht gesetzt, so SOLL die Member-ID als User-Agent im Request Header gesetzt sein. Ist weder der aud-Parameter noch der user-agent gesetzt MUSS trotzdem ein Entity Statement zum angefragten Teilnehmer vom Federation Master zurück geliefert werden. [<=]

ML-128451 - AF_10101 - Unter federation_fetch_endpoint benannte URL ist erreichbar und liefert signiertes JWS als Response

Der Request eines Teilnehmers der Föderation an die URL, welche im Entity Statement des Federation Master unter dem Attribut federation_fetch_endpoint benannt ist, wird entgegengenommen und gibt als Response ein signiertes JWS zurück. Das Token ist mit dem privaten Schlüssel des Federation Master signiert und kann vom Fachdienst mit dem öffentlichen Schlüssel des Federation Master verifiziert werden. [<=]

Hinweis: Für den Fetch Entity Request gelten die Festlegung im Standard [OpenID Connect Federation1.0] Kapitel 7.1.1. 

ML-128452152179 - AF_10101 - Payload des JWS-Token enthält Informationen zum angefragten Teilnehmer der Föderation

Der Payload des JWS-Token enthält diese Informationen bezüglich des angefragten Teilnehmers der Föderation (siehe auch ):

• iss = URL - Identifier Federation Master
• sub = URL - Identifier des angefragten Teilnehmers
• iat = long Wert - Ausstellungszeitpunkt des Abrufs (Alle time-Werte in Sekunden seit 1970)
• exp = long Wert - Ablaufzeitpunkt der Gültigkeit des Abrufs (Alle time-Werte in Sekunden seit 1970)
• jwks = JWKS Objekt - öffentlicher Schlüssel des angefragten Teilnehmers.
• aud = URL - Identifier des anfragenden Teilnehmers. Wenn der aud-Parameter im Fetch Entity-Statement-Request des anfragenden Teilnehmers vorhanden ist, MUSS der aud Parameter in der Fetch Entity-Statement-Response vorhanden sein und genau diesen Wert annehmen.   

[<=]Für registrierte Relying Parties (Fachdienste) MÜSSEN zusätzlich diese Informationen im Payload des JWS-Token enthalten sein: 

• scopes = scopes, die bei der Registrierung der Relying Party beim Federation Master angegeben wurden
• claims = claims, die bei der Registrierung der Relying Party beim Federation Master angegeben wurden
• redirect_uris = redirect_uris, die bei der Registrierung der Relying Party beim Federation Master angegeben wurden

[<=]

Hinweis: Will eine Relying Party den Umfang der vom sektoralen IDP anforderbaren scopes oder claims erweitern oder redirect_uris ändern, so müssen diese Änderungen über den organisatorischen Registrierungsprozess laufen.

3.4 Anwendungsfall - Schlüssel verwalten

AF_10110 - Monitoring der TLS- Zertifikate der VAU

 

Abbildung 7: Prüfung der TLS-Zertifikate eines sektoralen Identity Provider am Federation Master

 

Tabelle 14: Anwendungsfall "Monitoring der TLS-Zertifikate der VAU"

[<=]

3.4.1 Akzeptanzkriterien - Schlüssel verwalten

ML-132625 - AF_10110 - Ablage der TLS-Schlüssel im Federation Master

Wurde ein sektoraler Identity Provider erstmalig beim Federation Master registriert, so MÜSSEN die öffentlichen Schlüssel aller TLS-Zertifikate zu den second-level, third-level bzw. higher-level domain des sektoralen Identity Provider welche in der VAU terminieren beim Federation Master zum sektoraler Identity Provider hinterlegt sein.
Wurde eine TLS-Zertifikat zu einer second-level, third-level bzw. higher-level domain eines sektoralen Identity Provider, welcher in der VAU terminiert, hinzugefügt oder aktualisiert, so MUSS der öffentliche Schlüssel des hinzugefügten oder aktualisierten TLS-Zertifikats zur Domäne des sektoralen Identity Provider beim Federation Master zum sektoralen Identity Provider hinterlegt sein. [<=]

ML-132627 - AF_10110 - TLS-Schlüsselprüfung durch den Federation Master nicht erfolgreich

Gibt es mindestens ein TLS-Zertifikat zu einer second-level, third-level bzw. higher-level domain eines sektoralen Identity Provider, der in der VAU terminiert und dessen öffentlicher Schlüssel nicht oder falsch beim Federation Master registriert ist, so ist die Prüfung nicht erfolgreich. Der Betreiber des Federation Master hat Schritte zur Problemklärung (gemäß A_22968) eingeleitet. [<=]

4 Anforderungen an den Produkttyp

4.1 Aufbau und Inhalt des Federation Master Entity Statement

Der Federation Master bildet den Vertrauensanker der Föderation.  Ebenso ist der Federation Master eine Entität innerhalb der Föderation. Gemäß dem verwendeten Standard OpenID Connect mit OAuth 2.0 kommen JSON Web Token (JWT), JSON Web Encryption (JWE), JSON Web Signature (JWS) und JSON Web Key (JWK) zum Einsatz.

Um nutzenden Anwendungen eine einheitliche Bezugsquelle für die Adressierung von Schnittstellen zu schaffen, werden die für alle Akteure grundlegenden Schnittstellen im sogenannten Entity Statement zusammengefasst und dort unter der ".well-known/openid-federation" gemäß [OpenID Connect Federation 1.0#rfc.section.6] veröffentlicht.

Alle Akteure der Föderation sind angehalten, das Entity Statement herunterzuladen und den Inhalt in den geplanten Betrieb einzubeziehen. Die Teilnehmer der Föderation benötigen das Entity Statement des Federation Master zur: 

• Validierung der Vertrauenskette in der Kommunikation zwischen Fachdiensten und sektoralem Identity Provider
• Validierung anderer Kommunikationsteilnehmer in der Föderation
• Ermittlung des API-Endpunktes des Federation Master
• Ermittlung der Liste aller in der Föderation registrieren sektoralen Identity Provider.

 

A_22947 - Aktualisierungszyklen für die Liste der registrierten sektoralen Identity Provider

Der Federation Master MUSS die Liste der registrierten sektoralen Identity Provider täglich aktualisieren. Darüber hinaus MUSS der Federation Master die Liste bei Neuregistrierung oder Löschung von sektoralen Identity Providern aktualisieren. [<=]

A_22948 - Aktualisierungszyklen der Entity Statements Federation Master

Der Federation Master MUSS sein Entity Statement täglich aktualisieren. Darüber hinaus MUSS der Federation Master sein Entity Statement bei jeder Änderung, welche sich auf das Entity Statement auswirkt, aktualisieren. [<=]

A_22949 - Aktualisierungszyklen der Entity Statements zu Teilnehmern der Föderation

Der Federation Master MUSS seine Entity Statements zu den Teilnehmern der Föderation täglich aktualisieren. Darüber hinaus MUSS der Federation Master sein Entity Statement zu einem Teilnehmern bei jeder Änderung, welche sich auf das Entity Statement zum Teilnehmer auswirkt, aktualisieren. [<=]

Hinweis: Ist ein sektoraler IDP ggf. temporär nicht erreichbar, so sollte das Herunterladen des Entity Statements über den Federation Master weiter (z.B. stündlich) versucht werden.

A_25414 - Prüfung der Entity Statements von Fachdiensten

Der Anbieter des Federation Master MUSS einen Prozess etablieren, in dem der Anbieter des Federation Master mindestens täglich die Entity Statements der Fachdienste abfragt und die Werte der in Tabelle "Prüfung der Entity Statements von Fachdiensten" aufgeführten Attribute hinsichtlich der bei der Registrierung hinterlegten Werte prüft. Stimmen die Werte nicht überein, so MUSS der Federation Master die in der Tabelle aufgeführten Maßnahmen treffen. 

Tabelle 15 : Prüfung der Entity Statements von Fachdiensten

Attribut	Abweichung	Auswirkung	Maßnahme
jwks	Schlüssel, mit der Fachdienst sein Entity Statement signiert, hat sich geändert.	Der im Federation Master hinterlegte Schlüssel ist nicht mehr korrekt, der Vertrauensraum ist ggf. gefährdet.	Einstellen eines Incident und Sperren des Teilnehmers in der Föderation
authority_hints	Die Vertrauenskette hat sich geändert.	Als Vertrauensanker ist nicht mehr der Federation Master eingetragen. Vertrauensraum ist ggf. gefährdet.	Einstellen eines Incident und Sperren des Teilnehmers in der Föderation
scopes	Der Umfang der vom Fachdienst anfragbaren scopes hat sich geändert.	Hat sich der Umfang, der anfragbaren scopes erweitert, so besteht die Gefahr des unberechtigten Zugriffs auf Identitätsdaten. Eine Veringerung des Umfangs der anfragbaren scopes hat keine negativen Auswirkungen.	Einstellen eines Incident und Sperren des Teilnehmers in der Föderation
claims	Der Umfang der vom Fachdienst anfragbaren claims hat sich geändert.	Hat sich der Umfang, der anfragbaren claims erweitert, so besteht die Gefahr des unberechtigten Zugriffs auf Identitätsdaten. Eine Veringerung des Umfangs der anfragbaren claims hat keine negativen Auswirkungen.	Einstellen eines Incident und Sperren des Teilnehmers in der Föderation
redirect_uris	Der Inhalt der Liste der URLs, an den die vom IDP ausgestellten Identitätsinformationen geschickt werden, hat sich geändert.	Die vom IDP ausgestellten Identitätsinformationen können ggf. an unberechtigte Endpunkte verschickt werden, so besteht die Gefahr des unberechtigten Zugriffs auf Identitätsdaten.	Einstellen eines Incident und Sperren des Teilnehmers in der Föderation
metadata.openid_relying_party.organization_name	Der Name der Organisation hat sich geändert.	Die Änderung kann zu Anzeigeproblemen bei den Nutzern führen.	Einstellen eines Incident
metadata.openid_relying_party.client_name	Der Name des Fachdienstes (redundant zu metadata:federation_entity:name) hat sich geändert.	Die Änderung kann zu Anzeigeproblemen bei den Nutzern führen.	Einstellen eines Incident
metadata.federation_entity.name	Der Name des Fachdienstes (redundant zu metadata:openid_relying_party:client_name) hat sich geändert.	Die Änderung kann zu Anzeigeproblemen bei den Nutzern führen.	Einstellen eines Incident

[<=]

Hinweis 1: Das Sperren eines Fachdienstes bedeutet technisch den Ausschluss aus der Föderation. Fragt ein sektoraler IDP die Teilnehmerauskunft zu einem gesperrten Fachdienst beim Federation Master ab, so antwortet dieser gemäß https://openid.net/specs/openid-federation-1_0.html#error_response mit Error Code HTTP-401 invalid_client.

Hinweis 2: Zum Entsperren muss der Fachdienst die Abweichungen in seinem Entity Statement korrigieren oder im Fall gewollter Änderungen zur Aktualisierung den organisatorischen Registrierungsprozess erneut durchlaufen.

A_25415 - Entsperren eines gesperrten Fachdienstes in der TI-Föderation

Hat der Anbieter des Federation Master aufgrund von A_25414 einen Fachdienst in der TI-Föderation gesperrt, so SOLL der Anbieter des Federation Master den Fachdienst ohne weitere Maßnahmen wieder zulassen, wenn dieser die Abweichungen im Entity Statement korrigiert hat. [<=]

Hinweis: Die Anforderung ist als SOLL formuliert. Von dieser Anforderung kann abgewichen werden, wenn es begründete Bedenken (z.B. weitere Incidents) gegen die Zulassung des Fachdienstes gibt.

A_22604 - Verwendung eindeutiger URI

Der Federation Master MUSS alle verwendeten Adressen in Form von URL gemäß [RFC1738 ] angeben und in einem Entity Statement gemäß [OpenID Connect Federation 1.0#rfc.section.3.1] im Internet veröffentlichen. [<=]

A_22605 - Entity Statement Veröffentlichung

Der Federation Master MUSS sein Entity Statement im Internet gemäß [OpenID Connect Federation 1.0#rfc.section.6] unter ".well-known/openid-federation" veröffentlichen. [<=]

A_22606 - Entity Statement - Prüfung der angebotenen URL

Der Anbieter des Federation Master MUSS alle von ihm im Entity Statement angebotenen URL ständig auf bloße Erreichbarkeit prüfen. [<=]

A_22607 - Inhalte des Federation Master Entity Statement

Der Federation Master MUSS im Entity Statement gemäß [OpenID Connect Federation 1.0#rfc.section.6.2 ] mindestens die folgenden Attribute angeben:

Tabelle 1516: Attribute Entity Statement Federation Master

[<=]

A_22608 - Inhalte des Metadata Federation API-Endpunkt im Federation Master Entity Statement

Der Federation Master MUSS im Entity Statement gemäß [OpenID Connect Federation 1.0#rfc.section.4.6 ] mindestens die folgenden Attribute als metadata/federation_entity angeben:
 

Tabelle 1617: Attribut "Federation API Endpoint"

[<=]

A_22609 - Inhalte des Federation Master Entity Statement Metadata IDP-Liste

Der Federation Master MUSS im Entity Statement mindestens das folgende Attribut als metadata/federation_entity angeben:
 

Tabelle 1718: Attribut "IDP List Endpoint"

[<=]

A_23087 - Entity Statements gelöschter Teilnehmer

Der Federation Master MUSS sicherstellen,  dass der Abruf des Entity Statement gelöschter Teilnehmer über das Federation Master API zu einer Fehlermeldung unter Berücksichtigung des Standards [OpenID Connect Federation 1.0#rfc.section.7.5] führt. [<=]

4.2 Organisatorische Prozesse am Federation Master

A_22675-01 - Teilnehmerregistrierung am Federation Master

Der Anbieter des Federation Master MUSS einen organisatorischen Prozess für die Registrierung von Teilnehmern an der Föderation etablieren. Alle Teilnehmer der Föderation MÜSSEN über diesen Prozess ihre öffentlichen Schlüssel beim Federation Master hinterlegen. Fachdienste MÜSSEN zusätzlich die für ihre Anwendungsfälle notwendigen scopes bzw. claims hinterlegen. Der Anbieter des Federation Master MUSS vorsehen, dass die gematik in den organisatorischen Ablauf eingebunden ist und die Möglichkeit der Prüfung der vom Fachdienst eingereichten scopes und claims erhält.
[<=]

Hinweis 1: Der Aufbau und die Verwendung der hierarchischen Vertrauensbeziehung (Trust Chain)  ist im Standard [OpenID Connect Federation 1.0] festgelegt und wird darüber hinaus hier nicht weiter spezifiziert.

Hinweis 2: Die Registrierung MUSS für jede Betriebsumgebung separat erfolgen. Betriebsumgebungen sind Test-Umgebung (TU), Referenz-Umgebung (RU) und die Produktiv-Umgebung (PU). Die Registrierung für die Produktiv-Umgebung erfolgt erst nach Zulassung oder Bestätigung.

Fachdienste sollten nur genau die scopes beanspruchen, die für die Ausführung ihrer Anwendungsfälle unbedingt notwendig sind. Eine differenziertere Unterscheidung in verpflichtenden Attribute (essential claims, ohne die eine Diensterbringung gar nicht möglich ist) und freiwillige Attribute (voluntary claims, ohne die eine Diensterbringung in eingeschränktem Umfang möglich ist) wird durch die Verwendung von claims ermöglicht.

A_22741-01 - Prüfung "scope" von Fachdiensten

Der Anbieter des Federation Master MUSS einen Prozess etablieren, in dem der Anbieter des Federation Master mindestens täglich die Entity Statements der Fachdienste abfragt und die dort aufgeführten scopes und claims hinsichtlich der bei der Registrierung hinterlegten scopes und claims prüft. Ist die Prüfung nicht erfolgreich, MUSS der Anbieter des Federation Master organisatorische und/oder technische Prozesse mit geeigneten Maßnahmen zur Problembeseitigung etablieren.
[<=]

Hinweis 1: Geeignete Maßnahmen können je nach Analyseergebnis z.B. das Einstellen von Security-Bugs beim Betreiber des Fachdienstes, die Einstellung eines sicherheitsrelevanten Notfalls gegen den Anbieter des entsprechenden Fachdienstes durch den Federation Master im TI-ITSM (für TI-ITSM Teilnehmer), aber auch das Löschen des betroffenen Fachdienstes sein.

Hinweis 2: Ist ein sektoraler IDP ggf. temporär nicht erreichbar, so sollte das Herunterladen des Entity Statements über den sektoralen IDP weiter (z.B. stündlich) versucht werden.

A_22677 - Teilnehmer am Federation Master löschen

Der Anbieter des Federation Master MUSS einen organisatorischen Prozess mit 4-Augen-Prinzip zur Erteilung von Löschaufträgen und einen technischen Prozess zum eigentlichen Löschen von Teilnehmern aus der Föderation etablieren.  [<=]

Hinweise 1:  Die Abwicklung kann über Service Request durch gematik. oder durch definierte Trigger im Rahmen eines Sicherheitsvorfalls erfolgen.

Hinweis 2: Beim Löschen eines sektoralen Identity Providers aus der Föderation wird zusätzlich die Sperrung der Signaturzertifikate in der Komponenten-PKI veranlasst, welche dieser zur Signatur seiner ID_TOKEN verwendet. Dies geschieht selbstständig durch den Anbieter des IDP oder bei "Wegfall der Voraussetzung für den Betrieb" durch die gematik.

A_22945 - Schlüssel für Certificate Transparency TLS-Zertifikate übergeben

Der Anbieter des Federation Master MUSS einen organisatorischen Prozess etablieren, über den die Übergabe der öffentlichen Schlüssel von TLS-Zertifikaten zu Domänen eines sektoraler Identity Provider, welche in der VAU terminieren, vom Anbieter des sektoralen IDP an den Federation Master erfolgt. [<=]

Hinweis: Für den Ablauf der Schlüsselprüfungen siehe 3.4-1 Monitoring der TLS- Zertifikate der VAU 

A_22968 - Maßnahmen bei nicht erfolgreicher TLS-Zertifikatsprüfung durch den Federation Master

Gibt es mindestens ein TLS-Zertifikat der Domäne/Unterdomäne eines sektoralen Identity Provider, das in der VAU terminiert und dessen öffentlicher Schlüssel nicht oder falsch beim Federation Master registriert ist, so ist die Prüfung nicht erfolgreich. Für diesen Fall MUSS der Anbieter des Federation Master organisatorische und technische Prozesse mit geeigneten Maßnahmen zur Analyse und Problembeseitigung etablieren. [<=]

Hinweis: Geeignete Maßnahmen können je nach Analyseergebnis z.B. das Einstellen von Security-Bugs beim Betreiber des sektoralen Identity Provider, die Einstellung eines sicherheitsrelevanten Notfalls gegen den Anbieter des entsprechenden sektoralen IDP durch den Federation Master im ITSM, aber auch das Löschen des betroffenen sektoralen IDP sein.

4.3 Allgemeine Sicherheitsanforderungen

A_22678 - Schützenswerte Objekte

Der Anbieter des Federation Master MUSS die folgenden kryptographischen Objekte als schützenswerte Objekte in seinem Sicherheitskonzept berücksichtigen:

• Privater Schlüssel und öffentlicher Schlüssel des Federation Master
• Öffentliche Schlüssel von registrierten Clients
• Authentisierungsinformationen von Löschberechtigten
• Dokumentation über beauftragte und durchgeführte Löschungen
• Statusinformationen
• Authentisierungsinformationen zur Authentisierung von internen Akteuren bzw. Rollen
• Protokolldaten
• Konfigurationsdaten.

[<=]

A_22601 - Federation Master - Berücksichtigung OWASP-Top-10-Risiken

Der Anbieter des Federation Master MUSS Maßnahmen zum Schutz sowohl vor den zum Zulassungszeitpunkt aktuellen OWASP-Top-10-Risiken umsetzen, als auch die nach dem Zulassungszeitpunkt jeweils aktuellen OWASP-Top-10-Risiken berücksichtigen. [<=]

4.4 Sicherheit der Netzübergänge

A_22591 - Federation Master – Sicherung zum Transportnetz Internet durch Paketfilter

Der Anbieter des Federation Master MUSS dafür sorgen, dass das Transportnetz Internet durch einen Paketfilter (ACL) gesichert wird und ausschließlich die erforderlichen Protokolle weiterleitet. Der Anbieter des Federation Master MUSS dafür sorgen, dass  der Paketfilter des Federation Master frei konfigurierbar auf der Grundlage von Informationen aus OSI-Layer 3 und 4 ist (Quell- und Zieladresse, IP-Protokoll sowie Quell- und Zielport). [<=]

A_22592 - Federation Master – Platzierung des Paketfilters Internet

Der Anbieter des Federation Master DARF den Paketfilter des Federation Master zum Schutz in Richtung Transportnetz Internet  NICHT physisch auf dem vorgeschalteten TLS-terminierenden Load Balancer implementieren. [<=]

A_22593 - Federation Master-Anbieter – Richtlinien für den Paketfilter zum Internet

Der Anbieter des Federation Master MUSS beim Paketfilter die Weiterleitung von IP-Paketen an der Schnittstelle zum Internet auf das HTTPS-Protokoll beschränken. [<=]

A_22594 - Federation Master – Verhalten bei Vollauslastung

Der Anbieter des Federation Master MUSS den Paketfilter des Federation Master so konfigurieren, dass bei Vollauslastung der Systemressourcen im Federation Master keine weiteren Verbindungen angenommen werden. [<=]

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

A_22589 - Richtlinien zum TLS-Verbindungsaufbau

Der Anbieter des Federation Master MUSS dafür sorgen, dass der Eingangspunkt des Federation Master sich beim TLS-Verbindungsaufbau über das Transportnetz gegenüber dem Client mit einem TLS-Zertifikat eines Herausgebers gemäß [CAB-Forum] authentisiert.
Der Anbieter des Federation Master MUSS die TLS-Zertifikate aus einer CA beziehen, welche Certificate Transparency gemäß RFC 6962 / RFC 9162 unterstützt und täglich prüfen und sicherstellen, dass für seine Domänen keine unbekannten Zertifikate im Certificate Transparency Log gelistet werden.
Der Anbieter des Federation Master MUSS für seine TLS-Zertifikate Certification Authority Authorization (CAA) DNS Resource Records nach RFC 6844 bereitstellen, welche die Validität der ausstellenden CA verifizieren. [<=]

4.5 Fehlermeldungen

A_22595 - Format der Fehlermeldungen

Der Federation Master MUSS für die verschiedenen Teilfunktionen geeignete Fehlermeldungen erzeugen und diese an den jeweiligen Aufrufer übergeben. Die Festlegungen im Standard [OpenID Connect Federation 1.0#rfc.section.7.5] MÜSSEN bei der Definition der Meldungsinhalte berücksichtigt werden.<= [<=]

A_22596 - Nutzung von eindeutigen Error-Codes bei der Erstellung von Fehlermeldungen

Der Federation Master MUSS Fehler durch eine eindeutige Nummer erkennbar machen und der gematik eine Liste der Error-Codes zur Verfügung stellen, damit die Ursachenklärung vereinfacht möglich wird. Die Festlegungen im Standard [OpenID Connect Federation 1.0#rfc.section.7.5] MÜSSEN bei der Definition der Fehlercodes berücksichtigt werden.  [<=]

A_22597 - Verwendung eines einheitlichen Schemas für die Aufbereitung von Fehlermeldungen

Der Federation Master MUSS alle ausgeworfenen Fehlermeldungen zur Weiterverarbeitung in einem einheitlichen Schema aufbereiten und bereitstellen. Zeitstempel MÜSSEN auf der UTC basieren. [<=]

A_22598 - Formulierung der Fehlermeldungen

Der Federation Master MUSS Fehlermeldungen, welche dem Nutzer angezeigt werden, in der Art ausformulieren, dass es dem Nutzer möglich ist, eigenes Fehlverhalten anhand der Fehlermeldung abzustellen. [<=]

A_22599 - Nutzung einer eindeutigen Beschreibung beim Aufbau von Fehlermeldungen

Der Federation Master MUSS jedem Fehler eine eindeutige eigene Beschreibung zukommen lassen, sodass eine Fehlermeldung nicht für unterschiedliche Fehlerursachen zur Anwendung kommt. [<=]

A_22600 - Ausgabe der Fehlermeldungen in umgekehrter Reihenfolge des Auftretens

Der Federation Master MUSS aufeinander aufbauende Fehlermeldungen in der umgekehrten Reihenfolge ihres Auftretens "Traceback (most recent call last)" ausgeben. [<=]

5 Anhang – Verzeichnisse

5.1 Abkürzungen

Tabelle 1819: Abkürzungen

5.2 Glossar

Tabelle 1920: Glossar

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

5.3 Abbildungsverzeichnis

Abbildung 1: Überblick TI-Föderation

Abbildung 2: Systemkontext

Abbildung 3: Übersichtsschaubild OIDC Federation

Abbildung 4: Anwendungsfälle Federation Master

Abbildung 5:  Aktivitätsdiagramm  "Auswahl sektorale Identity Provider"

Abbildung 6: Federation Master im Authorization-Flow

Abbildung 7: Prüfung der TLS-Zertifikate eines sektoralen Identity Provider am Federation Master

5.4 Tabellenverzeichnis

Tabelle 1: Request zur Teilnehmerabfrage an den Federation Master

Tabelle 2: Akteure und Rollen

Tabelle 3: Attributbeschreibung

Tabelle 4: Übersicht über die Anwendungsfälle im Gesamtkontext Federation Master

Tabelle 5: Anwendungsfälle Federation Master

Tabelle 6: Anwendungsfall "Bereitstellung Liste registrierter Identity Provider"

Tabelle 7: Liste sektorale Identity Provider - Payload-Attribute des signierten JSON-Web-Token

Tabelle 8: Liste sektorale Identity Provider - Headerattribute des signierten JSON-Web-Token

Tabelle 9: Federation Master im Authorization-Flow

Tabelle 10: Anwendungsfall "Bereitstellung von Informationen zu Teilnehmern der Föderation durch den Federation Master"

Tabelle 11: Teilnehmer Validierung Abfrage - Request-Parameter

Tabelle 12: Teilnehmer Validierung Abfrage  - Response-Payload-Attribute des signierten JSON-Web-Token

Tabelle 13: Teilnehmer Validierung - Response-Header-Attribute des signierten JSON-Web-Token

Tabelle 14: Anwendungsfall "Monitoring der TLS-Zertifikate der VAU"

Tabelle 15: Attribute : Prüfung der Entity Statement Federation MasterStatements von Fachdiensten

Tabelle 16: Attribut "Federation API Endpoint"Attribute Entity Statement Federation Master

Tabelle 17: Attribut "IDP ListFederation API Endpoint"

Tabelle 18: AbkürzungenAttribut "IDP List Endpoint"

Tabelle 19: GlossarAbkürzungen

Tabelle 20: QuellenGlossar

Tabelle 21: Weitere DokumenteQuellen

Tabelle 22: Weitere Dokumente

5.5 Referenzierte Dokumente

5.5.1 Dokumente der gematik

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

Tabelle 2021: Quellen

5.5.2 Weitere Dokumente

Tabelle 2122: Weitere Dokumente