C_12327_Anlage_V1.0.0
Prereleases:
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. |