C_12327_Anlage_V1.0.0


C_12327_Anlage

Inhaltsverzeichnis

1 Änderungsbeschreibung

Im Rahmen der Umsetzung von A_25239 (eGK-Gast-Login) ist vorgesehen, dass das Authenticator Modul die eGK des Versicherten ausliest, dieser die PIN eingibt und die so erhaltenen und signierten Daten an das IDP Backend gegeben werden.
Aktuell lässt die Anforderung Interpretationsspielraum zu, so dass bei unpassender Implementierung Sicherheitslücken entstehen können.
Die Anforderung muss entsprechend präzisiert werden. Die Umsetzung muss durch ein Produktgutachten nachgewiesen werden.

Aktuell kann aus den Rohdaten nicht ermittelt werden, ob ein Gast-Login nach A_25239* durchgeführt wurde. Um das Monitoring durch die gematik zu ermöglichen müssen A_22833-01 und A_22825-02 um einen weiteren Use Case IDP.UC_35 erweitert werden.

2 Änderung in gemSpec_IDP_Sek

4.3.2 Authentifizierungsverfahren

Alt:

A_25239 - Authentifizierung mit eGK+PIN ohne Prüfung Gerätebindung (Gastzugang)

Der sektorale IDP MUSS über sein Authenticator-Modul die Authentifizierung eines Nutzers mit eGK+PIN ohne Prüfung oder Anlegen einer Gerätebindung unterstützen, wenn eine Relying Party eine Nutzer Authentifizierung urn:telematik:auth:guest:eGK beim sektoralen IDP anfordert. In diesem Fall MUSS der sektorale IDP die Gültigkeit des AUT-Zertifikats der eGK prüfen und die Zertifikatsattribute für die Erstellung des ID_TOKEN verwenden. 

Hinweis 1: Ist der Nutzer bei der Krankenkasse versichert, bei dessen sektoralen IDP die Authentifizierung durchgeführt wird, so kann der sektorale IDP einen Nutzeraccount zu diesem Nutzer anlegen, wenn dieser noch nicht existiert.

Hinweis 2: Ist der Nutzer bei einer anderen Krankenkasse versichert als der, bei deren sektoralen IDP die Authentifizierung durchgeführt wird, so kann der sektorale IDP im ausgestellten ID_TOKEN nur Scopes/Claims bestätigen, die aus dem Zertifikat der eGK ermittelt, werden können.

[<=]



Neu:

A_25239-01 - Authentifizierung mit eGK+PIN ohne Prüfung Gerätebindung (Gastzugang)
Der sektorale IDP MUSS über sein Authenticator-Modul die Authentifizierung eines Nutzers mit eGK+PIN ohne Prüfung oder Anlegen einer Gerätebindung unterstützen, wenn eine Relying Party eine Nutzer Authentifizierung urn:telematik:auth:guest:eGK beim sektoralen IDP anfordert. In diesem Fall MUSS der sektorale IDP die Gültigkeit des AUT-Zertifikats der eGK prüfen und die Zertifikatsattribute für die Erstellung des ID_TOKEN verwenden. ,nach Übertragung des Zertifikates durch das Authenticator-Modul an den sektoralen IDP, dieser:

  • die Gültigkeit und Signatur des AUT-Zertifikats der eGK prüfen
  • das Authentisierungsverfahren gegen Replay-Angriffe schützen
  • mittels Signaturanforderung das Vorliegen der korrekten PIN sicherstellen
  • sicherstellen, dass der öffentliche Schlüssel des AUT-Zertifikats dem öffentlichen Schlüssel aus der angeforderten Signatur entspricht
  • die Attribute des AUT-Zertifikats für die Erstellung des ID_TOKEN verwenden. 

Hinweis 1: Ist der Nutzer bei der Krankenkasse versichert, bei dessen sektoralen IDP die Authentifizierung durchgeführt wird, so kann der sektorale IDP einen Nutzeraccount zu diesem Nutzer anlegen, wenn dieser noch nicht existiert.

Hinweis 2: Ist der Nutzer bei einer anderen Krankenkasse versichert als der, bei deren sektoralen IDP die Authentifizierung durchgeführt wird, so kann der sektorale IDP im ausgestellten ID_TOKEN nur Scopes/Claims bestätigen, die aus dem Zertifikat der eGK ermittelt, werden können.

<=, IDP-Sek, funkt. Eignung: Test Produkt/FA Sich.techn. Eignung: Produktgutachten

3 Änderung in gemSpec_Perf

3.1.1.3 Performancevorgaben Identity Provider

Alt:

A_22833-01 - Performance - Anbieter Sektoraler Identity Provider Kostenträger - Bearbeitungszeiten unter Last

Der Anbieter Sektoraler Identity Provider Kostenträger MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_sektoraler_IDP erfüllen.
Es wird davon ausgegangen, dass der sektorale Identity Provider eingeschwungen ist und z. B. Lokalisierungsanfragen lokal zwischengespeichert sind, sowie Verbindungen nicht neu ausgehandelt werden.
MA ist der Marktanteil des Anbieters gemäß A_22225.
Im Fall der Authorization Requests zählt die Zeit von der Anfrage des Authenticator-Moduls bis zum Eintreffen der Antwort nicht zur Bearbeitungszeit und muss gemäß A_22944* separat als "backendduration" mitgeteilt werden.

Tabelle 1: Tab_gemSpec_Perf_sektoraler_IDP: Bearbeitungszeitvorgaben

ID
Anwendungsfälle Lastvorgaben
Bearbeitungszeitvorgaben
Spitzenlast
[1/s]
Maximalwert
[ms]

IDP.UC_30 Processing of Pushed Authorization Requests  10 + (450 x MA) 800
IDP.UC_31
Processing of Authorization Requests
(alle Authentisierungsverfahren)
10 + (450 x MA) 500
IDP.UC_32,
IDP.UC_33
IDP.UC_34
Response of Authorization Requests (mit online Ausweisfunktion)
Response of Authorization Requests (mit eGK und PIN)
Response of Authorization Requests (alternatives Authentisierungsverfahren)
10 + (450 x MA) 100
IDP.UC_39 Token Requests 10 + (450 x MA) 800

Hinweis:  Im Falle der Verwendung von fremdbetriebenen Drittsystemen zur Implementierung von Authentisierungsverfahren, 
(z.B. OCSP-Responder der PKI, eID-Provider) darf der Anbieter  die Verarbeitungszeit in diesen Drittsystemen als Backend Duration gemäß A_22944* für das  jeweilige Authentisierungsverfahren gesondert ausweisen. [<=]

Neu:

A_22833-012 - Performance - Anbieter Sektoraler Identity Provider Kostenträger - Bearbeitungszeiten unter Last
Der Anbieter sektoraler Identity Provider Kostenträger MUSS die Bearbeitungszeitvorgaben unter Last aus Tab_gemSpec_Perf_sektoraler_IDP erfüllen.
Es wird davon ausgegangen, dass der sektorale Identity Provider eingeschwungen ist und z. B. Lokalisierungsanfragen lokal zwischengespeichert sind, sowie Verbindungen nicht neu ausgehandelt werden.
MA ist der Marktanteil des Anbieters gemäß A_22225.
Im Fall der Authorization Requests zählt die Zeit von der Anfrage des Authenticator-Moduls bis zum Eintreffen der Antwort nicht zur Bearbeitungszeit und muss gemäß A_22944* separat als "backendduration" mitgeteilt werden.

Tabelle 2: Tab_gemSpec_Perf_sektoraler_IDP: Bearbeitungszeitvorgaben

ID
Anwendungsfälle Lastvorgaben
Bearbeitungszeitvorgaben
Spitzenlast
[1/s]
Maximalwert
[ms]

IDP.UC_30 Processing of Pushed Authorization Requests  10 + (450 x MA) 800
IDP.UC_31
Processing of Authorization Requests
(alle Authentisierungsverfahren)
10 + (450 x MA) 500
IDP.UC_32,
IDP.UC_33
IDP.UC_34

Response of Authorization Requests (mit online Ausweisfunktion)
Response of Authorization Requests (mit eGK und PIN)
Response of Authorization Requests (alternatives Authentisierungsverfahren)
10 + (450 x MA) 100
IDP.UC_35 Response of Authorization Requests (Gast-Login mit eGK und PIN) 10 + (450 x MA) 100
IDP.UC_39 Token Requests 10 + (450 x MA) 800


Hinweis:  Im Falle der Verwendung von fremdbetriebenen Drittsystemen zur Implementierung von Authentisierungsverfahren, 
(z.B. OCSP-Responder der PKI, eID-Provider) darf der Anbieter  die Verarbeitungszeit in diesen Drittsystemen als Backend Duration gemäß A_22944* für das jeweilige Authentisierungsverfahren gesondert ausweisen
.

3.1.2 Betriebsdatenerfassung v2 Spezifika Identity Provider

Alt:

A_22825-02 - Performance - Betriebsdatenlieferung v2 - Spezifika Anbieter Sektoraler Identity Provider Kostenträger - Operation/Duration

Der sektorale Identity Provider MUSS bei Betriebsdatenlieferungen bzgl. der Felder "operation" und "duration_in_ms" die Angaben aus der Tabelle Tab_gemSpec_Perf_Berichtsformat_sektoraler_IDP in der Spalte "$IDP-Operation" und der Spalte "$Duration" berücksichtigen.
Schnittstelle: Internet

Tabelle 3: Tab_gemSpec_Perf_Berichtsformat_sektoraler_IDP

$IDP-Operation
Operation $Duration
IDP.UC_30
Processing of Pushed Authorization Requests
Die Duration beginnt mit der Annahme des Pushed Authorization Request (PAR) vom Authorization Server des Fachdienstes und endet mit der Übermittlung der "URI-PAR" zum Authorization Server des Fachdienstes.
Zeiten zwischen der optionalen Anfrage "Get Entity Statement RP" des sektoralen IDP an den Fachdienst und der Antwort "Entity Statement" sowie der optionalen Anfrage "Fetch Entity Statement RP" des sektoralen IDP an den Federation Master und Antwort "Entity Statement" sind in der Berechnung für den IDP.UC_30 nicht enthalten und gemäß A_22944* separat als "backendduration" mitzuteilen.
IDP.UC_31 Processing of Authorization Requests (alle Authentisierungsverfahren) Die Duration beginnt mit der Annahme des Authorization-Request (URI-PAR) und endet mit dem Absenden der Anfrage zur Authentifizierung.
IDP.UC_32 Response of Authorization Requests (mit online Ausweisfunktion) Die Duration beginnt mit der Annahme der Antwort auf die Anfrage zur Authentifizierung und endet mit der Übermittlung der Antwort zur redirect_url oder eines Fehlercodes an die Betriebsdatenerfassung (siehe A_22826).
IDP.UC_33 Response of Authorization Requests (mit eGK und PIN) Die Duration beginnt mit der Annahme der Antwort auf die Anfrage zur Authentifizierung und endet mit der Übermittlung der Antwort zur redirect_url oder eines Fehlercodes an die Betriebsdatenerfassung (siehe A_22826).
IDP.UC_34 Response of Authorization Requests (alternatives Authentisierungsverfahren) Die Duration beginnt mit der Annahme der Antwort auf die Anfrage zur Authentifizierung und endet mit der Übermittlung der Antwort zur redirect_url oder eines Fehlercodes an die Betriebsdatenerfassung (siehe A_22826).
IDP.UC_39 Token Requests Die Duration für IDP.UC_39 beginnt mit der Annahme des AUTH_CODE vom Authorization Server des Fachdienstes und endet mit der Übermittlung des ID_TOKEN (ACCESS_TOKEN) zum Authorization Server des Fachdienstes.
[<=]

Neu:

A_22825-023 - Performance - Betriebsdatenlieferung v2 - Spezifika Anbieter Sektoraler Identity Provider Kostenträger - Operation/Duration
Der sektorale Identity Provider MUSS bei Betriebsdatenlieferungen bzgl. der Felder "operation" und "duration_in_ms" die Angaben aus der Tabelle Tab_gemSpec_Perf_Berichtsformat_sektoraler_IDP in der Spalte "$IDP-Operation" und der Spalte "$Duration" berücksichtigen.
Schnittstelle: Internet

Tabelle 4: Tab_gemSpec_Perf_Berichtsformat_sektoraler_IDP

$IDP-Operation
Operation $Duration
IDP.UC_30
Processing of Pushed Authorization Requests
Die Duration beginnt mit der Annahme des Pushed Authorization Request (PAR) vom Authorization Server des Fachdienstes und endet mit der Übermittlung der "URI-PAR" zum Authorization Server des Fachdienstes.
Zeiten zwischen der optionalen Anfrage "Get Entity Statement RP" des sektoralen IDP an den Fachdienst und der Antwort "Entity Statement" sowie der optionalen Anfrage "Fetch Entity Statement RP" des sektoralen IDP an den Federation Master und Antwort "Entity Statement" sind in der Berechnung für den IDP.UC_30 nicht enthalten und gemäß A_22944* separat als "backendduration" mitzuteilen.
IDP.UC_31 Processing of Authorization Requests (alle Authentisierungsverfahren) Die Duration beginnt mit der Annahme des Authorization-Request (URI-PAR) und endet mit dem Absenden der Anfrage zur Authentifizierung.
IDP.UC_32 Response of Authorization Requests (mit online Ausweisfunktion) Die Duration beginnt mit der Annahme der Antwort auf die Anfrage zur Authentifizierung und endet mit der Übermittlung der Antwort zur redirect_url oder eines Fehlercodes an die Betriebsdatenerfassung (siehe A_22826).
IDP.UC_33 Response of Authorization Requests (mit eGK und PIN) Die Duration beginnt mit der Annahme der Antwort auf die Anfrage zur Authentifizierung und endet mit der Übermittlung der Antwort zur redirect_url oder eines Fehlercodes an die Betriebsdatenerfassung (siehe A_22826).
IDP.UC_34 Response of Authorization Requests (alternatives Authentisierungsverfahren) Die Duration beginnt mit der Annahme der Antwort auf die Anfrage zur Authentifizierung und endet mit der Übermittlung der Antwort zur redirect_url oder eines Fehlercodes an die Betriebsdatenerfassung (siehe A_22826).
IDP.UC_35 Response of Authorization Requests (mit eGK und PIN) Gast-Login Die Duration beginnt mit der Annahme der Antwort auf die Anfrage zur Authentifizierung und endet mit der Übermittlung der Antwort zur redirect_url oder eines Fehlercodes an die Betriebsdatenerfassung (siehe A_22826).
IDP.UC_39 Token Requests Die Duration für IDP.UC_39 beginnt mit der Annahme des AUTH_CODE vom Authorization Server des Fachdienstes und endet mit der Übermittlung des ID_TOKEN (ACCESS_TOKEN) zum Authorization Server des Fachdienstes.