gemSpec_Authentisierung_Vers_V1.5.0_Aend

 

 

 

 

Elektronische Gesundheitskarte und Telematikinfrastruktur

 

 

 

Spezifikation Authentisierung des Versicherten ePA

 

 

 

   

   

Version	1.45.10
Revision	548770
Stand	02.06.202131.01.2022
Status	freigegeben
Klassifizierung	öffentlich
Referenzierung	gemSpec_Authentisierung_Vers

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

DokumentinformationenDokumentinformationen

InhaltsverzeichnisInhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

1.2 Zielgruppe

1.3 Geltungsbereich

1.4 Abgrenzungen

1.5 Methodik

2 Systemkontext

3 Zerlegung der Komponente

4 Übergreifende Festlegungen

4.1 Datenschutz und Datensicherheit

4.2 Verwendete Standards

4.3 Fehlerbehandlung

4.4 Protokollierung

4.5 Nicht-Funktionale Anforderungen

4.6 Identifikation der Akteure

5 Funktionsmerkmale

5.1 Authentisierung

5.1.1 Schnittstellen

5.1.1.1 Schnittstelle I_Authentication_Insurant

5.1.1.1.1 Operation login

5.1.1.1.2 Operation renew

5.1.1.1.3 Operation logout

5.1.1.1.4 Operation getAuditEvents

5.1.1.1.5 Operation getSignedAuditEvents

5.1.2 Umsetzung

5.1.2.1 Schnittstelle I_Authentication_Insurant

5.1.2.1.1 Operation login

5.1.2.1.2 Operation Renew

5.1.2.1.3 Operation Logout

5.1.2.1.4 Operation getAuditEvents

5.1.2.1.5 Operation getSignedAuditEvents

5.1.3 Lebensdauer der Authentifizierungsbestätigung

6 Informationsmodell

7 Verteilungssicht

8 Anhang A – Verzeichnisse

8.1 Abkürzungen

8.2 Glossar

8.3 Abbildungsverzeichnis

8.4 Tabellenverzeichnis

8.5 Referenzierte Dokumente

8.5.1 Dokumente der gematik

8.5.2 Weitere Dokumente

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen an die Teilkomponente "Authentisierung Versicherter" der Komponente "Zugangsgateway" (s.a. [gemSpec_Zugangsgateway_Vers]) des Produkttyps ePA-Aktensystem (s.a. [gemSpec_Aktensystem]).

Die Teilkomponente "Authentisierung Versicherter" ist zuständig für die Authentisierung von Versicherten und deren Vertretern innerhalb der Fachanwendung ePA (s.a. [gemSysL_ePA]).

1.2 Zielgruppe

Das Dokument ist maßgeblich für Anbieter und Hersteller des Produkttyps ePA-Aktensystem sowie für Anbieter und Hersteller von Produkten, die die Schnittstellen der Teilkomponente "Authentisierung Versicherter" nutzen.

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) fest­gelegt 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

Spezifiziert werden in dem Dokument die von dem Produkttyp bereitgestellten (angebotenen) Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert (siehe auch Kapitel 8.5).

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

1.5 Methodik

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Anforderungen werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche zwischen Afo-ID und Textmarke [<=]  angeführten Inhalte.

2 Systemkontext

Die Teilkomponente "Authentisierung Versicherter" der Komponente "Zugangsgateway" des ePA-Aktensystems ist Teil des Produkttyps ePA. Der Systemüberblick ist in [gemSysL_ePA] dargestellt.

Von der dezentralen Fachlogik im "ePA-Frontend des Versicherten" und dem Fachmodul ePA wird die Komponente verwendet, um die Authentifizierung von Versicherten und deren berechtigten Vertretern zu bestätigen.

Auf Anwendungsebene findet dabei ein Dialog zwischen aufrufendem Client (C) und der Komponente "Authentisierung Versicherter" (S) statt:

• C fordert S auf, einen Authentisierungs-Token zu erstellen.
• S antwortet C mit der Aufforderung (Challenge), eine Zufallszahl zu signieren, um sicherzustellen, dass die nachfolgende Authentisierungsnachricht frisch erzeugt wird.
• C antwortet auf die Challenge mit einer Signatur für die Zufallszahl aus der Challenge. Die Signatur erzeugt er mittels der Authentisierungsidentität ID.CH.AUT der eGK oder der alternativen Versichertenidentität ID.CH.AUT_ALT.  
• S authentifiziert C durch Prüfung der Signatur.
  S stellt eine Authentifizierungsbestätigung aus und sendet sie an C.

Um Prüfungen durchzuführen, greift die Komponente auf Dienste der TI-Plattform zentral zurück.

3 Zerlegung der Komponente

Eine weitere Untergliederung der Aufbaustruktur der Komponente ist nicht erforderlich.

4 Übergreifende Festlegungen

Die Komponente "Authentisierung Versicherter" stellt eine X-User Assertion (XUA) gemäß [IHE#ITI-40] aus.

4.1 Datenschutz und Datensicherheit

A_14773 - Komponente Authentisierung Versicherter - Authentisierungsschlüssel

Die Komponente "Authentisierung Versicherter" MUSS die erstellten Authentifizierungsbestätigungen mit dem privaten Schlüssel der Ausstelleridentität ID.FD.SIG signieren. Das zugehörige Zertifikat C.FD.SIG MUSS die Rolle "oid_epa_authn" enthalten. [<=]

Hinweis: Da die Identität ID.FD.SIG nur durch das Aktensystem selbst verwendet wird ist dafür die Schlüsselgeneration ECDSA zu verwenden (s. [gemSpec_Krypt]).

A_15091 - Komponente Authentisierung Versicherter - Verwendung eines HSM

Die Komponente "Authentisierung Versicherter" MUSS das private Schlüsselmaterial der Ausstelleridentität C.FD.SIG und der TLS-Server-Identität C.FD.TLS-S in einem HSM speichern. [<=]

Zur Absicherung der Schnittstelle muss der Transport der SOAP-Nachrichten mittels HTTPS erfolgen. Dabei sind die Vorgaben zu TLS gem. [gemSpec_Krypt#3.3.2] und [gemSpec_PKI#8.4.1] umzusetzen.

Die Verbindung zum ePA-Frontend des Versicherten wird auf Transportebene mit TLS abgesichert. Auf dieser Ebene erfolgt eine serverseitige Authentisierung durch die Komponente "Authentisierung Versicherter" wie in [gemSpec_Zugangsgateway_Vers#Kapitel4.2] beschrieben.

Verbindungen innerhalb der TI werden ebenfalls auf Transportebene mit TLS abgesichert. Dabei werden Zertifikate der TI verwendet.

A_14227 - Komponente Authentisierung Versicherter - TLS-Authentisierung innerhalb der TI

Die Komponente "Authentisierung Versicherter" MUSS für alle innerhalb der TI zur Verfügung gestellten Schnittstellen ausschließlich Verbindungen mit TLS akzeptieren und dabei die einseitige Serverauthentisierung unter Nutzung des X.509-Komponentenzertifikats für TLS C.FD.TLS-S  und der Rolle "oid_epa_authn" umsetzen. [<=]

A_14801 - Komponente Authentisierung Versicherter - XML Schema-Validierung für SOAP-Eingangsnachrichten

Die Komponente "Authentisierung Versicherter" MUSS vor einer Weiterverarbeitung sämtliche SOAP 1.2-Eingangsnachrichten einer XML Schema-Validierung unterziehen und gemäß [SOAP] verarbeiten. Sind Nachrichten nicht wohlgeformt oder gültig, MUSS die Komponente "Authentisierung Versicherter" die Nachricht mit einem HTTP-Statuscode 400 gemäß [RFC7231] quittieren. [<=]

A_14777 - Komponente Authentisierung Versicherter - Prüfung des Signaturzertifikats von Authentifizierungsbestätigungen

Die Komponente "Authentisierung Versicherter" MUSS sicherstellen, dass Authentifizierungsbestätigungen nur akzeptiert werden, wenn das zugehörige Signaturzertifikat zeitlich gültig ist, nicht gesperrt wurde und nach dem Zertifikatsprofil C.FD.SIG für  die Identität der Komponente Authentisierung Versicherter selbst ausgestellt wurde.  
Dies kann durch eine aktuell gehaltene Konfiguration vertrauenswürdiger Zertifikate umgesetzt werden und ersetzt eine detaillierte Prüfung des Signaturzertifikats gem. [gemSpec_TBAuth#A_15557].
[<=]

A_14780 - Komponente Authentisierung Versicherter - Aussteller von Authentifizierungsbestätigungen

Die Komponente "Authentisierung Versicherter" MUSS sicherstellen, dass die Authentifizierungsbestätigung von der Komponente "Authentisierung Versicherter" selbst ausgestellt wurde (s.a. [gemSpec_TBAuth#GS-A_5494]). 
[<=]

A_15605-01 - Komponente Authentisierung Versicherter - Ablehnung von SOAP 1.2-Nachrichten ohne UTF-8 Enkodierung

Die Komponente "Authentisierung Versicherter" MUSS SOAP 1.2-Nachrichten mit einem HTTP-Statuscode 415 gemäß [RFC7231] quittieren, sofern die Zeichenkodierung im HTTP Header nicht UTF-8 benennt (Content-Type: charset=utf-8). [<=]

Diese Festlegungen zur UTF-8-Enkodierung überschreibt die Festlegungen aus [WSIBP].

A_15613 - Komponente Authentisierung Versicherter – Erkennung von Denial-of-Service-Angriffen hinsichtlich dem Parsen von SOAP 1.2-Nachricht

Die Komponente "Authentisierung Versicherter" MUSS die folgenden Angriffstypen in eingehenden SOAP 1.2-Nachrichten erkennen und mit einem HTTP-Statuscode 400 gemäß [RFC7231] quittieren:

• XML Injection
• XPath Query Tampering
• XML External Entity Injection

[<=]

4.2 Verwendete Standards

Für die Übertragung von Nachrichten an den Schnittstellen der Komponente "Authentisierung Versicherter" wird SOAP in Verbindung mit HTTP verwendet.

A_14352-01 - Komponente Authentisierung Versicherter - Grundlegende Standards

Die Komponente "Authentisierung Versicherter" MUSS folgende Standards umsetzen, soweit diese im Rahmen der zu implementierenden Operationen verwendet werden und sofern sie nicht durch konkrete Anforderungen überschrieben werden: 
 

• IHE ITI-40 Transaction "Provide X-User Assertion" [IHE#ITI-40]
• HTTP/1.1 [RFC7231]
• SOAP 1.2 [SOAP]
• WSDL 1.1 [WSDL]
• WSDL 1.1 Binding Extension for SOAP 1.2 [WSDL11SOAP12]
• WS-Trust 1.43 [WS-Trust]
• WS-I Basic Profile V2.0 [WSIBP]
• WS Security SAML Token Profile 1.1 [WSS-SAML]
• XSPA Profile of SAML for Healthcare v2.0 [XSPA-SAML]
• SAML V2.0 [SAML2.0]
• WS Security [WSS]

[<=]

Generell ist [gemSpec_Krypt] für alle Algorithmen und sonstigen kryptographischen Vorgaben zu beachten.

Für die Schnittstellen der Komponente "Authentisierung Versicherter" werden die in der folgenden Tabelle definierten XML-Präfixe verwendet.

Tabelle 1: Tab_Auth_Vers_002 - Verwendete Namensräume und Präfixe

Präfix	Namensraum	Referenz
phra	http://ws.gematik.de/fd/phrs/I_Authentication_Insurant/v1.1
phr	http://ws.gematik.de/fa/phr/v1.0
xs	http://www.w3.org/2001/XMLSchema
saml	urn:oasis:names:tc:SAML:2.0:assertion	SAML 2.0 [SAML2.0]
soap	http://www.w3.org/2003/05/soap-envelope	SOAP 1.2 [SOAP]
wsoap12	http://schemas.xmlsoap.org/wsdl/soap12/	[WSDL11SOAP12]
wsdl	http://schemas.xmlsoap.org/wsdl/	WSDL 1.1 [WSDL]
ds	http://www.w3.org/2000/09/xmldsig#
xenc	http://www.w3.org/2001/04/xmlenc#
wst	http://docs.oasis-open.org/ws-sx/ws-trust/200512	WS-Trust 1.4 [WS-Trust]
wsu	http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
wsaw	http://www.w3.org/2006/05/addressing/wsdl
tel	http://ws.gematik.de/tel/error/v2.0

A_15604 - Komponente Authentisierung Versicherter - Kodierung in UTF-8

Die Komponente "Authentisierung Versicherter" MUSS bei der Erstellung von XML-Fragmenten das Encoding UTF-8 verwenden. [<=]

4.3 Fehlerbehandlung

Bei Fehlern in der internen Verarbeitung oder bei fachlichen Fehlern in der Nutzung der bereitgestellten Schnittstellen liefert die Komponente "Authentisierung Versicherter" Fehlermeldungen zurück. Deren Struktur hängt davon ab, ob der Meldungsablauf auf [WS-Trust] basiert oder nicht.

Aufrufe mit Meldungen nach [WS-Trust] werden entsprechend auch mit Fehlermeldungen gemäß dem Standard beantwortet.

Andere Aufrufe werden als SOAP-Fault gemäß [gemSpec_OM] strukturiert und enthalten die in den Schnittstellendefinitionen angegebenen Fehlermeldungsinhalte innerhalb einer GERROR-Struktur gemäß [TelematikError.xsd].

A_14415 - Komponente Authentisierung Versicherter - Verwendung von Webservice-Fehlern

Die Komponente "Authentisierung Versicherter" MUSS an der Schnittstelle  I_Authentication_Insurant:login den in [WS-Trust#Kapitel11] festgelegten SOAP-Fault-Mechanismus umsetzen.
[<=]

A_15138 - Komponente Authentisierung Versicherter - Inhalte der Fehlermeldungen

Die Komponente "Authentisierung Versicherter" MUSS in einer GERROR-Fehlermeldung gemäß [TelematikError.xsd] die Felder wie folgt mit den Fehlermeldungsinhalten der Schnittstellenbeschreibung befüllen:

• Fehlername Name: tel:Error/tel:Trace/tel:EventID
• Fehlerdetailtext Fehlertext: tel:Error/tel:Trace/tel:ErrorText
• Fehlercode: in tel:Error/tel:Trace/tel:Code entsprechend dem Fehlernamen gem. folgender Tabelle:

Tabelle 2:  Tab_Auth_Vers_003 - Zuordnung Fehlercodes zu Fehlernamen

[<=]

4.4 Protokollierung

Die Anforderungen an die Protokollierung für die Komponente leiten sich aus [gemSysL_ePA#2.5.5] ab.

A_13877-01 - Komponente Authentisierung Versicherter - Verwaltungsprotokollierung

Die Komponente "Authentisierung Versicherter" MUSS beim Aufruf einer der in [] aufgelisteten Operationen der Schnittstelle I_Authentication_Insurant unter der Voraussetzung, dass der Aufruf erfolgreich war, je einen Eintrag im Verwaltungsprotokoll für den Versicherten gemäß [] vornehmen und die Parameterwerte dabei wie folgt setzen:

Tabelle 3: Tab_Auth_Vers_004 - Operationsabhängige Parameter des Verwaltungsprotokolls

 

Die nicht in [ ] aufgelisteten Operationen der Schnittstelle I_Authentication_Insurant werden nicht protokolliert. 

[<=]

A_21104 - Komponente Authentisierung Versicherter - Verwaltungsprotokollierung, wenn loginCreateToken fehlschlägt

Falls der Aufruf der Operation loginCreateToken fehl schlägt, MUSS die Komponente "Authentisierung Versicherter" einen Eintrag im Verwaltungsprotokoll für den Versicherten bzw. seinen Vertreter gemäß [] vornehmen und zusätzlich zu den Vorgaben von A_13877 die Parameterwerte wie in Tab_Auth_Vers_0016 setzen. Es wird die Geamtanzahl der fehlgeschlagenen Aufrufe der Operation loginCreateToken jeweils für eGK und al.vi gezählt und genau ein Protokolleintrag je Datumstag geschrieben.

Tabelle 4 : Tab_Auth_Vers_0016- Operationsabhängige Parameter des Verwaltungsprotokolls bei fehlerhaftem Aufruf der Operation loginCreateToken

[<=] 

Zur Protokollierung sind auch die Vorgaben in [gemSpec_Aktensystem#5.2] zu beachten.Zur Protokollierung sind auch die Vorgaben in [gemSpec_Aktensystem#5.2] zu beachten.

A_21104-01 - Komponente Authentisierung Versicherter - Verwaltungsprotokollierung, wenn loginCreateToken fehlschlägt

Falls der Aufruf der Operation loginCreateToken fehl schlägt, MUSS die Komponente "Authentisierung Versicherter" einen Eintrag im Verwaltungsprotokoll für den Versicherten bzw. seinen Vertreter gemäß [] vornehmen und zusätzlich zu den Vorgaben von A_13877 die Parameterwerte wie in Tab_Auth_Vers_0016 setzen. Es wird die Gesamtanzahl der fehlgeschlagenen Aufrufe der Operation loginCreateToken jeweils für eGK und al.vi gezählt und genau ein Protokolleintrag je Datumstag geschrieben.
 

Tabelle 4: Tab_Auth_Vers_0016- Operationsabhängige Parameter des Verwaltungsprotokolls bei fehlerhaftem Aufruf der Operation loginCreateToken

[<=]

4.5 Nicht-Funktionale Anforderungen

Die die Komponente "Authentisierung Versicherter" betreffenden Anforderungen zu Skalierbarkeit, Performance und Mengengerüst sind in [gemSpec_Perf] zu finden.

4.6 Identifikation der Akteure

Der Versicherte bzw. der von ihm berechtigte Vertreter im Sinne der Fachanwendung ePA werden über ihre Krankenversichertennummer (KVNR) eindeutig identifiziert (vgl. [gemSysL_ePA#2.4.1]. Die KVNR besteht aus einem unveränderlichen Teil (Versicherten-ID) und einem veränderlichen Teil. In diesem Dokument ist mit der Abkürzung KVNR immer nur der unveränderliche Teil (Versicherten-ID) gemeint.

In den Zertifikaten einer eGK bzw. einer alternativen Versichertenidentität ist der unveränderliche Teil der KVNR in einem Feld organizationalUnitName des SubjectDN enthalten (s. [gemSpec_PKI#5.1]). Dabei ist zu beachten, dass das Feld organizationalUnitName im SubjectDN in zwei Ausprägungen auftritt (s. [gemSpec_PKI#4.2]):

• das zehnstellige alphanumerische Feld organizationalUnitName beinhaltet den unveränderlichen Teil der KVNR
• das neunstellige numerische Feld organizationalUnitName beinhaltet das Institutionskennzeichen (Kassenzugehörigkeit)

Demzufolge muss für Versicherte bzw. deren berechtigte Vertreter der unveränderliche Teil der KVNR aus dem zehnstelligen alphanumerischen Feld organizationalUnitName von den Zertifikaten entnommen und zur Identifikation herangezogen werden.

5 Funktionsmerkmale

Die Komponente Authentisierung Versicherter realisiert ein Funktionsmerkmal über eine Schnittstelle:

Tabelle 5: Tab_Auth_Vers_005 - Schnittstellenübersicht der Komponente Authentisierung des Versicherten

Die Operation 'login' wird sowohl zur initialen Erstellung der Authentifizierungsbestätigung als auch nach Ablauf der Gültigkeit der ursprünglichen Authentifizierungsbestätigung zur Erstellung einer neuen Authentifizierungsbestätigung aufgerufen.
Die Operation 'renew' erstellt eine neue Authentifizierungsbestätigung, wenn eine gültige Authentifizierungsbestätigung vorgelegt wird, zu der noch kein 'logout' stattgefunden hat.
Die Operation 'logout' beendet die Erneuerbarkeit einer Authentifizierungsbestätigung.

Die Komponente "Authentisierung Versicherter" nutzt die in der folgenden Tabelle aufgeführten Schnittstellen der Telematikinfrastruktur.

Tabelle 6: Tab_Auth_Vers_006 - Benutzte Schnittstellen der TI

5.1 Authentisierung

5.1.1 Schnittstellen

5.1.1.1 Schnittstelle I_Authentication_Insurant

Das Interface I_Authentication_Insurant stellt die in [gemSysL_ePA] definierte Schnittstelle bereit.

A_14228-01 - Komponente Authentisierung Versicherter - I_Authentication_Insurant

Die Komponente "Authentisierung Versicherter" MUSS einen Webservice-Endpunkt I_Authentication_Insurant bereitstellen, welcher die logischen Schnittstellen I_Authentication_Insurant:login, I_Authentication_Insurant:renew und I_Authentication_Insurant:logout nach WS-Trust und die Schnittstellen I_Authentication_Insurant:getAuditEvents und I_Authentication_Insurant:getSignedAuditEvents zum Abruf von Protokolldaten durch die folgenden angebotenen Operationen realisiert:

Tabelle 7: Tab_Auth_Vers_007 - Schnittstellenübersicht der Authentisierung des Versicherten

Die als SAML-Assertion zurückgelieferte Authentifizierungsbestätigung ist zur Vorlage bei den im Element Audience (s. Kap. 5.1.2.1.1) angegeben Webservices bestimmt und kann durch den Aufrufer als opakes Token behandelt werden. Es ist mit der Identität der Komponente "Authentisierung Versicherter" signiert. [<=]

5.1.1.1.1 Operation login

Die Operation dient der Ausstellung von Authentifizierungsbestätigungen für Versicherte auf der Basis des Zertifikats C.CH.AUT oder C.CH.AUT_ALT des Versicherten.

Die Authentifizierungsbestätigung hat folgende wesentlichen Eigenschaften:

• Sie enthält das Zertifikat des Versicherten C.CH.AUT bzw. C.CH.AUT_ALT .
  Der Subject-DN aus diesem Zertifikat ist in ihr als Subjekt aufgeführt und enthält in einem der Felder OrganizationalUnitName die KVNR (s. Kap. 4.6).
• Der Authentication-Kontext im Feld saml2:AuthnContextClassRef der erzeugten Authentifizierungsbestätigung hängt vom Typ des übergebenen Zertifikats (C.CH.AUT oder C.CH.AUT_ALT) ab.
• Sie enthält in einem Attribut die aus dem Zertifikat extrahierte KVNR separat.
• Sie wird mit einer Gültigkeit von 5 Minuten ausgestellt.
• Sie legt als Methode zur SubjectConfirmation "Bearer" fest.

Voraussetzung für den Dialog auf Anwendungsebene ist eine etablierte TLS-Verbindung auf Transportebene.

Analog zu [WS-Trust#8] wird auf Anwendungsebene ein Signature Challenge Dialog implementiert. Abweichend von  [WS-Trust#8.2] bzw. [WS-Trust#Appendix B] liegt der Endpunkt auch für den Austausch der Signaturchallenge auf der Seite der Komponente "Authentisierung Versicherter", d.h. der Meldungsablauf ist in zwei durch den Aufrufer initiierte Meldungspaare aufgeteilt, deren Inhalte gemäß [WS-Trust] strukturiert sind.

Die logische Operation Login setzt sich daher auf Ebene der Webservices aus einer Abfolge der zwei Operationen LoginCreateChallenge und LoginCreateToken zusammen.

Die Fehlerbehandlung für diese beiden Operationen wird gemäß [WS-Trust#11] durchgeführt (vgl. Kap. 4.3).

Im Request zur Operation LoginCreateToken wird die Signatur des Versicherten über die von der Komponente "Authentisierung Versicherter" erstellten Challenge übertragen. Diese Übertragung erfolgt per WS-Security im SOAP-Header.

Die Bestückung der Nachrichtenfelder wird an einem Beispiel illustriert und dann normativ festgelegt.

Beispiel Dialog

LoginCreateChallenge, Request:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Header>
    <Action xmlns="http://www.w3.org/2005/08/addressing">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue</Action>
    <To xmlns="http://www.w3.org/2005/08/addressing">https://localhost:9094/authn</To>
  </soap:Header>
  <soap:Body>
    <RequestSecurityToken xmlns="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
      <TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</TokenType>
      <RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</RequestType>
    </RequestSecurityToken>
  </soap:Body>
</soap:Envelope>

LoginCreateChallenge, Response:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Header>
    <Action xmlns="http://www.w3.org/2005/08/addressing">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/Challenge</Action>
    <To xmlns="http://www.w3.org/2005/08/addressing">http://www.w3.org/2005/08/addressing/anonymous</To>
  </soap:Header>

  <soap:Body>
    <RequestSecurityTokenResponse xmlns="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
      <SignChallenge>
        <Challenge>JemuBWS...</Challenge>
      </SignChallenge>
    </RequestSecurityTokenResponse>
  </soap:Body>
</soap:Envelope>

LoginCreateToken, Request:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Header>
    <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" soap:mustUnderstand="true">
      <wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="X509-c3b3a51c-a22b-4682-85a2-5537d56ba5e2">MIIEzTCCA7WgA...</wsse:BinarySecurityToken>
      <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="SIG-f1f0472f-2f0d-468d-b425-0b1f5c78cc5a">
        <ds:SignedInfo>
          <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
            <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="soap"/>
          </ds:CanonicalizationMethod>
          <ds:SignatureMethod Algorithm="http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1"/>
          <ds:Reference URI="#id-6c68f4bd-153d-42fb-a640-890c5cc14771">
            <ds:Transforms>
              <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            </ds:Transforms>
            <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
            <ds:DigestValue>9Et/DvvJ1Sb0Z1SEequKHmOYTEizKYCKZlAEiDILGFU=</ds:DigestValue>
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>P21t+FT2tA...</ds:SignatureValue>
        <ds:KeyInfo Id="KI-bd93fc63-8828-46ad-8a6c-df08acabe5ce">
          <wsse:SecurityTokenReference xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="STR-d16144ef-1a31-45b8-b061-537a93fbd515">
            <wsse:Reference URI="#X509-c3b3a51c-a22b-4682-85a2-5537d56ba5e2" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
          </wsse:SecurityTokenReference>
        </ds:KeyInfo>
      </ds:Signature>
    </wsse:Security>

    <Action xmlns="http://www.w3.org/2005/08/addressing">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/ChallengeFinal</Action>
    <To xmlns="http://www.w3.org/2005/08/addressing">https://localhost:9094/authn</To>
  </soap:Header>
  <soap:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="id-6c68f4bd-153d-42fb-a640-890c5cc14771"> 

    <RequestSecurityTokenResponse xmlns="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
      <SignChallengeResponse>
        <Challenge>JemuBWS-...</Challenge>
      </SignChallengeResponse>
    </RequestSecurityTokenResponse>
  </soap:Body>
</soap:Envelope>

LoginCreateToken, Response:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Header>
    <Action xmlns="http://www.w3.org/2005/08/addressing">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal</Action>
    <To xmlns="http://www.w3.org/2005/08/addressing">http://www.w3.org/2005/08/addressing/anonymous</To>
  </soap:Header>

  <soap:Body>
    <RequestSecurityTokenResponseCollection xmlns="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
      <RequestSecurityTokenResponse>
        <RequestedSecurityToken>
          <saml2:Assertion ...> ...        
          </saml2:Assertion>
        </RequestedSecurityToken>
      </RequestSecurityTokenResponse>
    </RequestSecurityTokenResponseCollection>
  </soap:Body>
</soap:Envelope>

Normative Festlegung zum Dialog

A_14053 - Komponente Authentisierung Versicherter - I_Authentication_Insurant:login nach WS-Trust, LoginCreateChallenge

Die Komponente "Authentisierung Versicherter" MUSS die Operation LoginCreateChallenge wie folgt anbieten:

Tabelle 8: Tab_Auth_Vers_008 - Signatur der Schnittstelle I_Authentication_Insurant:loginCreateChallenge 

​​

[<=]

A_14059 - Komponente Authentisierung Versicherter - I_Authentication_Insurant:login nach WS-Trust, LoginCreateToken

Die Komponente "Authentisierung Versicherter" MUSS die Operation LoginCreateToken wie folgt anbieten:

Tabelle 9:  Tab_Auth_Vers_009 - Signatur der Schnittstelle I_Authentication_Insurant:loginCreateToken

[<=]

A_14350 - Komponente Authentisierung Versicherter - I_Authentication_Insurant:login, Challenge Response Prüfung

Die Komponente "Authentisierung Versicherter" MUSS sicherstellen, dass die in der SignChallengeResponse verwendete Challenge folgende Eigenschaften hat:

• der Wert in der Challenge im Request der Operation LoginCreateToken muss identisch dem Wert aus der Challenge in der Response der Operation LoginCreateChallenge sein.
• der Zeitraum zwischen Erzeugung des Zufallswertes in der Challenge und dem Eintreffen der Nachricht Request der Operation LoginCreateToken darf nicht größer als 1 Minute sein.

[<=]

A_18985-03 - ePA-Client: Prüfen der AuthenticationAssertion

Ein ePA-Client (ePA-Frontend des Versicherten, ePA FM etc.) MUSS beim Erhalt des Authenticationtokens (AuthenticationAssertion) vergleichen, ob sich die KVNR als eineindeutiges Merkmal des Nutzers, welcher sich gegenüber dem Aktensystem authentifiziert hat, in den Behauptungen mit saml2:Attribute Name="urn:gematik:subject:subject-id" wiederfindet (vgl. A_18985-Beispiel-1).

Falls die Prüfung ein negatives Ergebnis liefert, so MUSS der ePA-Client den Vorgang (Einloggen ins Aktensystem) abbrechen. 

[<=]

A_18985-Beispiel-1:

<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ID="_3886aa57-deb8-422d-b0f8-54ff207d089a" IssueInstant="2020-05-11T16:59:53.420Z" Version="2.0" xsi:type="saml2:AssertionType">
    <saml2:Issuer>https://aktor-gateway.gematik.de/authn</saml2:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      …
    </ds:Signature>
    <saml2:Subject>
        <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">CN=Dr. Emilio von BurgundTEST-ONLY, T=Dr., GIVENNAME=Emilio von, SURNAME=Burgund, OU=109500969, OU=X110474929, O=Test GKV-SVNOT-VALID, C=DE</saml2:NameID>
        <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/>
    </saml2:Subject>
    <saml2:Conditions NotBefore="2020-05-11T16:59:53.420Z" NotOnOrAfter="2020-05-11T17:04:53.420Z">
        <saml2:AudienceRestriction>
            <saml2:Audience>https://aktor-gateway.gematik.de</saml2:Audience>
        </saml2:AudienceRestriction>
    </saml2:Conditions>
    <saml2:AuthnStatement AuthnInstant="2020-05-11T16:53:53.322Z">
        <saml2:AuthnContext>
            <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI</saml2:AuthnContextClassRef>
        </saml2:AuthnContext>
    </saml2:AuthnStatement>
    <saml2:AttributeStatement>
        <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml2:AttributeValue xsi:type="xsd:string">Dr. Emilio von BurgundTEST-ONLY</saml2:AttributeValue>
        </saml2:Attribute>
        <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml2:AttributeValue xsi:type="xsd:string">Emilio von</saml2:AttributeValue>
        </saml2:Attribute>
        <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml2:AttributeValue xsi:type="xsd:string">Burgund</saml2:AttributeValue>
        </saml2:Attribute>
        <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml2:AttributeValue xsi:type="xsd:string">DE</saml2:AttributeValue>
        </saml2:Attribute>
        <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml2:AttributeValue xsi:type="xsd:string">X110474929</saml2:AttributeValue>
        </saml2:Attribute>
        <saml2:Attribute Name="urn:gematik:subject:subject-id" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml2:AttributeValue>
                <InstanceIdentifier xmlns="urn:hl7-org:v3" extension="X110474929" root="1.2.276.0.76.4.8"/>
            </saml2:AttributeValue>
        </saml2:Attribute>
    </saml2:AttributeStatement>
</saml2:Assertion>
 

5.1.1.1.2 Operation renew

Die Operation dient der Erneuerung einer Authentifizierungsbestätigung.

Die Bestückung der Nachrichtenfelder wird an einem Beispiel illustriert und dann normativ festgelegt.

Beispiel Dialog

RenewToken, Request:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Header>
    <Action xmlns="http://www.w3.org/2005/08/addressing"> http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Renew</Action>
    <To xmlns="http://www.w3.org/2005/08/addressing">...</To>
  </soap:Header>

<soap:Body>
    <RequestSecurityToken xmlns="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
      <TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</TokenType>
      <RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Renew</RequestType>
      <RenewTarget>... the token to be renewed ...</RenewTarget>
    </RequestSecurityToken>
  </soap:Body>
</soap:Envelope>

RenewToken, Response:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">

  <soap:Header>
    <Action xmlns="http://www.w3.org/2005/08/addressing"> http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/RenewFinal</Action>
    <To xmlns="http://www.w3.org/2005/08/addressing">...</To>
  </soap:Header>

  <soap:Body>
    <RequestSecurityTokenResponse xmlns="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
      <RequestedSecurityToken> ... the new token ... </RequestedSecurityToken>
    </RequestSecurityTokenResponse>
  </soap:Body>
</soap:Envelope>

A_17392-01 - Komponente Authentisierung Versicherter - I_Authentication_Insurant:renew nach WS-Trust, RenewToken

Die Komponente "Authentisierung Versicherter" MUSS die Operation renew wie folgt anbieten: 

[<=]

5.1.1.1.3 Operation logout

Die Operation beendet die Erneuerbarkeit einer Authentifizierungsbestätigung.

Die Bestückung der Nachrichtenfelder wird an einem Beispiel illustriert und dann normativ festgelegt.

Beispiel Dialog

LogoutToken, Request:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Header>
    <Action xmlns="http://www.w3.org/2005/08/addressing"> http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Cancel</Action>
    <To xmlns="http://www.w3.org/2005/08/addressing">...</To>
  </soap:Header>

  <soap:Body>
    <RequestSecurityToken xmlns="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
      <RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Cancel</RequestType>
      <CancelTarget>... the token to be cancelled ...</CancelTarget>
    </RequestSecurityToken>
  </soap:Body>
</soap:Envelope>

LogoutToken, Response:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">

  <soap:Header>
    <Action xmlns="http://www.w3.org/2005/08/addressing">...</Action>
    <To xmlns="http://www.w3.org/2005/08/addressing"> http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/CancelFinal</To>
  </soap:Header>

  <soap:Body>
    <RequestSecurityTokenResponse xmlns="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
      <RequestedTokenCancelled/>
    </RequestSecurityTokenResponse>
  </soap:Body>
</soap:Envelope>

A_17393-01 - Komponente Authentisierung Versicherter - I_Authentication_Insurant:Logout nach WS-Trust, LogoutToken

Die Komponente "Authentisierung Versicherter" MUSS die Operation Logout wie folgt anbieten: 

[<=]

5.1.1.1.4 Operation getAuditEvents

A_14477-02 - Komponente Authentisierung Versicherter - I_Authentication_Insurant::getAuditEvents

Die Komponente "Authentisierung Versicherter" MUSS die Operation I_Authentication_Insurant::getAuditEvents gemäß der folgenden Tabelle implementieren:
 

Tabelle 10: Tab_Auth_Vers_010 - Signatur der Schnittstelle I_Authentication_Insurant::getAuditEvents

[<=]

5.1.1.1.5 Operation getSignedAuditEvents

A_21162-0102 - Komponente Authentisierung Versicherter - I_Authentication_Insurant::getSignedAuditEvents

Die Komponente "Authentisierung Versicherter" MUSS die Operation I_Authentication_Insurant::getSignedAuditEvents gemäß der folgenden Tabelle implementieren:
 

Tabelle 11: Tab_Auth_Vers_016 - Signatur der Schnittstelle I_Authentication_Insurant::getSignedAuditEvents 

[<=]

5.1.2 Umsetzung

5.1.2.1 Schnittstelle I_Authentication_Insurant

5.1.2.1.1 Operation login

A_15052 - Komponente Authentisierung Versicherter - loginCreateChallenge, Ablauf

Die Komponente "Authentisierung Versicherter" MUSS beim Aufruf der Operation loginCreateChallenge die folgenden Aktionen ausführen und bei den genannten Fehlerbedingungen die Fehlermeldungen (vgl. Kap. 5.1.1.1.1) entsprechend setzen:

Tabelle 12: Tab_Auth_Vers_011 - Ablauf von loginCreateChallenge

 

[<=]

A_14229 - Komponente Authentisierung Versicherter - loginCreateToken, Ablauf

Das Komponente "Authentisierung Versicherter" MUSS beim Aufruf der Operation loginCreateToken die folgenden Aktionen ausführen und bei den genannten Fehlerbedingungen die Fehlermeldungen (vgl. Kap. 5.1.1.1.1) entsprechend setzen:

Tabelle 13: Tab_Auth_Vers_012 - Ablauf von loginCreateToken

Aktion	Fehlerbedingung	Fehlermeldung
Validierung der Eingangsnachricht gegen die WSDL und die zugehörigen Schemadateien	Fehler bei der Validierung.	wst:InvalidRequest oder allgemeiner SOAP Fault
Prüfung WS-Security Header	Das Signaturzertifikat ist nicht vorhanden oder das Signaturverfahren entspricht nicht den Vorgaben von [gemSpec_Krypt].	wst:InvalidRequest
Prüfung mathematische Korrektheit der Signatur	Signatur nicht korrekt.	wst:InvalidRequest
Das Signaturzertifikat muss gemäß [gemSpec_PKI#TUC_PKI_018] geprüft werden. Parameter: PolicyList: oid_egk_aut, oid_egk_aut_alt intendedKeyUsage: digitalSignature intendedExtendedKeyUsage: (leer) OCSP-Graceperiod: 60 Minuten Offline-Modus: nein Prüfmodus: OCSP Eine Prüfung der vom TUC zurückgelieferten Rollen-OID ist nicht erforderlich.	Fehlermeldung des aufgerufenen TUC.	wst:InvalidSecurityToken
Eingangsparameter des SOAP Body entsprechend A_14059 prüfen	Fehlende Elemente oder falsche Inhalte oder andere Fehler.	wst:InvalidRequest
Challenge Element mit abgesendeter Challenge in Response zu loginCreateChallenge vergleichen	Challenges verschieden.	wst:InvalidRequest
AuthenticationAssertion (Token) gem. A_14109 erstellen und in Whitelist für Erneuerung aufnehmen (s. Kap. 5.1.3#A_17395)	Fehler in der  internen Verarbeitung.	wst:RequestFailed

[<=]

Die Bestückung der Authentifizierungsbestätigung wird an einem Beispiel illustriert und dann normativ festgelegt.

Beispiel Authentifizierungsbestätigung

<?xml version="1.0" encoding="UTF-8"?>
<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ID="_108c30ac-bbcb-42c9-b306-a61c39a6d890" IssueInstant="2018-09-20T11:29:19.858Z" Version="2.0" xsi:type="saml2:AssertionType">
    <saml2:Issuer>https://[ePA_TI_FQDN]/authn</saml2:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1"/>
            <ds:Reference URI="#_108c30ac-bbcb-42c9-b306-a61c39a6d890">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                        <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="xsd"/>
                    </ds:Transform>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>TDtN2nJ05NUB1n18GL7AalUyuMVvrIHlEklGKXLho2o=</ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>        <ds:SignatureValue>aA4mAz3W2j7YWTKZmSXH2erR5MtfzzOroWRLsy0wVwZdSsaK3MXW5pTnVjXE87Wq2dYJ3OFhu1QGGPWwz1qNxnmynBiWlfu21UZNuroQycQCIojHqw+wguYkZJQAA7exfyDAQYG8lgQbg4YiaIHWvy7l/VPu8fKaU/BgGObbnYyLuXwg2DrTilD1XbunBpj25Hps4z6cS5zJZPPIIx8ZqOQ/keyz4Z+gcykj9Djv87lb/UZciBqtNR7nWv9PhDwvFti9VvD3KbNixgoyNozGbgAdlc9qo4gLgmDXuMhZLrOADzVwDOlmdx3/6rp+4vyMODdZGtIMA97EqPAm+QF0DQ==</ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>MIID...zA==</ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <saml2:Subject>
        <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName" NameQualifier="http://cxf.apache.org/sts">CN=Harald Graf HünschTEST-ONLY,2.5.4.42=#0c0b486172616c642047726166,2.5.4.4=#0c0748c3bc6e736368,OU=999567890,OU=X110446869,O=gematik Musterkasse1GKVNOT-VALID,C=DE</saml2:NameID>
        <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/>
    </saml2:Subject>
    <saml2:Conditions NotBefore="2018-09-20T11:29:19.884Z" NotOnOrAfter="2018-09-20T11:44:19.884Z">
        <saml2:AudienceRestriction>
            <saml2:Audience>[ePA_TI_FQDN_autn]</saml2:Audience>
            <saml2:Audience>[ePA_TI_FQDN_autz]</saml2:Audience>
            <saml2:Audience>[ePA_TI_FQDN_dokv]</saml2:Audience>
        </saml2:AudienceRestriction>
    </saml2:Conditions>
    <saml2:AuthnStatement AuthnInstant="2018-09-20T11:29:19.878Z">
        <saml2:AuthnContext>

            <saml2:AuthnContextClassRef>

                urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI

            </saml2:AuthnContextClassRef>
        </saml2:AuthnContext>
    </saml2:AuthnStatement>
    <saml2:AttributeStatement>

                  ...
        <saml2:Attribute Name="urn:gematik:subject:subject-id" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
            <saml2:AttributeValue>

               <InstanceIdentifier xmlns="urn:hl7-org:v3" extension="G995030566" root="1.2.276.0.76.4.8"/>

            </saml2:AttributeValue>
        </saml2:Attribute>
    </saml2:AttributeStatement>
</saml2:Assertion>
 

A_14109-02 - Komponente Authentisierung Versicherter - Befüllung der Authentifizierungsbestätigung bei Login

Die Komponente "Authentisierung Versicherter" MUSS die für die Operation loginCreateToken erzeugte Authentifizierungsbestätigung  als SAML2-Assertion gemäß [gemSpec_TBAuth#TAB_TBAuth_03] umsetzen und dabei folgende Vorgaben beachten:

• Das Issuer-Element muss als Aussteller des Token $ePA_TI_FQDN/authn enthalten, wobei $ePA_TI_FQDN der anbieterspezifische FQDN in der TI ist.
• Die eingebettete Signatur ds:Signature wird mit der Identität der Komponente Authentisierung Versicherter erstellt und das Element ds:Signature/ds:KeyInfo/ds:X509Data/ds:X509Certificate muss das zugehörige C.FD.SIG Zertifikat enthalten.
• Das Element saml2:Subject/saml2:NameID muss mit dem Subject-DN des C.CH.AUT-  bzw. C.CH.AUT_ALT-Zertifikats befüllt werden.
• Das Attribut saml2:Subject/saml2:SubjectConfirmation/@Method muss auf den Wert "urn:oasis:names:tc:SAML:2.0:cm:bearer" gesetzt werden.
• Das Attribut saml2:Conditions/@NotBefore muss auf die Systemzeit gesetzt werden.
• Das Attribut saml2:Conditions/@NotOnOrAfter muss auf (Systemzeit + 5 Minuten) gesetzt werden.
• Das Element saml2:Conditions/saml2:AudienceRestriction muss mit der Liste der aller Server, für die das Token ausgestellt wird, befüllt werden. Das Element /saml2:Audience enthält jeweils einen Empfänger des Tokens mit FQDN des ePA-Aktensystems gemäß gemSpec_Aktensystem Kapitel . 
  Bei der Befüllung von AudienceRestriction muss eine Unterscheidung erfolgen, ob der Aufruf zur Erstellung der Authentifizierungsbestätigung TI-seitig oder Internet-seitig erfolgt.
• Das Element saml2:AuthnStatement/saml2: AuthnContext/saml2:AuthnContextClassRef muss
  im Falle eines C.CH.AUT-Zertifikats auf den Wert "urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI" und
  im Falle eines C.CH.AUT_ALT-Zertifikats auf den Wert "urn:oasis:names:tc:SAML:2.0:ac:classes:X509" 
  gesetzt werden

[<=]

A_15631 - Komponente Authentisierung Versicherter - Behauptungen in der Authentifizierungsbestätigung

Die Komponente "Authentisierung Versicherter" MUSS die für die Operation loginCreateToken erzeugte Authentifizierungsbestätigung im Element AttributeStatement mit den Behauptungen gemäß [gemSpec_TBAuth#TAB_TBAuth_02_2] befüllen und dabei folgende Vorgaben beachten:

• Die Behauptungen müssen auf Basis des C.CH.AUT bzw. C.CH.AUT_ALT Zertifikats gebildet werden.
• Die Behauptung "urn:gematik:subject:subject-id" muss enthalten sein und basierend auf  dem unveränderlichen Anteil der KVNR gebildet werden. Das Attribut Attribute/@NameFormat muss dabei den Wert "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" haben.
• Die Behauptung "urn:gematik:subject:authreference" muss mit der Seriennummer des C.CH.AUT-  bzw. C.CH.AUT_ALT-Zertifikats gebildet werden.

[<=]

5.1.2.1.2 Operation Renew

A_17398 - Komponente Authentisierung Versicherter - RenewToken

Die Komponente "Authentisierung Versicherter" MUSS beim Aufruf der Operation RenewToken die folgenden Aktionen ausführen und bei den genannten Fehlerbedingungen die Fehlermeldungen (vgl. Kap. 5.1.1.1.2) entsprechend setzen:

Tabelle 14: Tab_Auth_Vers_015 - Ablauf von RenewToken

[<=]

A_17793 - Komponente Authentisierung Versicherter - Befüllung der Authentifizierungsbestätigung bei Renew

Die Komponente "Authentisierung Versicherter" MUSS die für die Operation RenewToken erzeugte Authentifizierungsbestätigung  als SAML2-Assertion gemäß [gemSpec_TBAuth#TAB_TBAuth_03] umsetzen und dabei folgende Vorgaben beachten:

• Das Attribut saml2:Conditions/@NotBefore muss auf die Systemzeit gesetzt werden.
• Das Attribut saml2:Conditions/@NotOnOrAfter muss auf (Systemzeit+5 Minuten) gesetzt werden.
• Alle anderen Attribute werden aus der zu verlängernden Authentifizierungsbestätigung aus der Whitelist (s. Kap. 5.1.3 übernommen). Insbesondere betrifft dies auch das Element saml2:AuthnStatement mit dem Attribut AuthnInstant.  
• Die eingebettete Signatur ds:Signature wird mit der Identität der Komponente Authentisierung Versicherter erstellt und das Element ds:Signature/ds:KeyInfo/ds:X509Data/ds:X509Certificate muss das zugehörige C.FD.SIG Zertifikat enthalten.

[<=]

5.1.2.1.3 Operation Logout

A_17412 - Komponente Authentisierung Versicherter - LogoutToken

Die Komponente "Authentisierung Versicherter" MUSS beim Aufruf der Operation LogoutToken die folgenden Aktionen ausführen und bei den genannten Fehlerbedingungen die Fehlermeldungen (vgl. Kap. 5.1.1.1.3) entsprechend setzen:

Tabelle 15: Tab_Auth_Vers_015 - Ablauf von RenewToken

[<=]

5.1.2.1.4 Operation getAuditEvents

Die Vorgaben zur Erstellung der Protokolleinträge sind in Kap. 4.4 beschrieben. Zur Prüfung der Berechtigung des Abrufs des Protokolls wird die übergebene Authentifizierungsbestätigung geprüft.

A_14781 - Komponente Authentisierung Versicherter - getAuditEvents, Prüfschritte

Die Komponente "Authentisierung Versicherter" MUSS beim Aufruf der Operation getAuditEvents die Prüfschritte für Authentifizierungsbestätigungen gem. Kap. 4.2 mit der als Eingangsparameter übergebenen Authentifizierungsbestätigung ausführen und die Fehlermeldung (vgl. Kap. 5.1.1.1.2) wie folgt setzen:

Tabelle 16: Tab_Auth_Vers_013 - Prüfschritte bei getAuditEvents

[<=]

A_14803 - Komponente Authentisierung Versicherter - Umsetzung getAuditEvents

Die Komponente "Authentisierung Versicherter" MUSS beim Aufruf der Operation getAuditEvents die Liste aller Verwaltungsprotokolleinträge gemäß [] zurückliefern, die der Identität in der übergebenen Authentifizierungsbestätigung entsprechen.
​​

[<=]

5.1.2.1.5 Operation getSignedAuditEvents

Die Vorgaben zur Erstellung der Protokolleinträge sind in Kap. 4.4 beschrieben. Zur Prüfung der Berechtigung des Abrufs des Protokolls wird die übergebene Authentifizierungsbestätigung geprüft.

A_21163 - Komponente Authentisierung Versicherter - getSignedAuditEvents, Prüfschritte

Die Komponente "Authentisierung Versicherter" MUSS beim Aufruf der Operation getSignedAuditEvents die Prüfschritte für Authentifizierungsbestätigungen gem. Kap. 4.2 mit der als Eingangsparameter übergebenen Authentifizierungsbestätigung ausführen und die Fehlermeldung (vgl. Kap. 5.1.1.1.2) wie folgt setzen:

Tabelle 17: Tab_Auth_Vers_017 - Prüfschritte bei getSignedAuditEvents

[<=]

A_21164-02 - Komponente Authentisierung Versicherter - Umsetzung getSignedAuditEvents

Die Komponente "Authentisierung Versicherter" MUSS beim Aufruf der Operation getSignedAuditEvents ein signiertes Dokument  zurückliefern, welches alle Verwaltungsprotokolleinträge gemäß [gemSpec_DM_ePA#A_14471] enthält, die der Identität in der übergebenen Authentifizierungsbestätigung entsprechen, wobei für die Signatur der Liste der private Schlüssel der Ausstelleridentität ID.FD.SIG genutzt wird, dessen zugehöriges Zertifikat C.FD.SIG die Rolle "oid_epa_logging" enthält. [<=]

Es wird das gesamte Dokument bzw. Dokumente signiert. Das Format soll dem der AuditEvents entsprechen.

5.1.3 Lebensdauer der Authentifizierungsbestätigung

Die Authentifizierungsbestätigung (Token) wird mit einer kurzen Lebensdauer erstellt. Innerhalb dieser Lebensdauer kann über die Operation Renew ein neuer Token wieder mit einer kurzen Lebensdauer ausgestellt werden. Durch Aufruf der Logout Operation wird die Möglichkeit eines erneuten Renew unterbunden. Die Gesamtlebensdauer, über die ein Renew erfolgen kann, wird beschränkt.

A_17395 - Komponente Authentisierung Versicherter - Whitelist

Die Komponente "Authentisierung Versicherter" MUSS eine Whitelist der aktiven Authentifizierungsbestätigungen (Token) mit folgenden Eigenschaften führen:

• Authentifizierungsbestätigungen (Token), die als Ergebnis von Login oder Renew zurückgeliefert werden, werden in die Whitelist eingetragen, sofern die Zeit im Attribut saml2:Conditions/@NotOnOrAfter weniger als 120 Minuten später liegt als die Zeit im Attribut saml2:AuthnStatement@AuthnInstant.
• Authentifizierungsbestätigungen (Token), die als Eingangsparameter von Renew verlängert werden sollen oder deren Verlängerbarkeit als Eingangsparameter von Logout beendet wird, werden aus der Whitelist entfernt
• Authentifizierungsbestätigungen (Token), die zeitlich abgelaufen sind (d.h. die aktuelle Systemzeit liegt später als saml2:Conditions/@NotOnOrAfter) werden aus der Whitelist entfernt

[<=]

Die Whitelist wirkt somit ausschließlich als Einschränkung für die Operation Renew:

• Token, die nicht auf der Whitelist stehen, werden nicht verlängert und 
• Token, für die der Authentifizierungszeitpunkt länger als die gegebene Zeitspanne zurückliegt, werden ebenfalls nicht verlängert.

Für die konkrete Ausgestaltung der Aktualisierung der Whitelist werden keine Vorgaben gemacht. Die Anforderungen in dieser Spezifikation stellen nur das logische Modell des Verhaltens der Whitelist dar. Umsetzungen sind spezifikationskonform, sofern dieses Verhalten an der Schnittstelle der Komponente reproduziert wird.

6 Informationsmodell

Ein gesondertes Informationsmodell der durch den Produkttypen verarbeiteten Daten wird nicht benötigt.

7 Verteilungssicht

Eine Darstellung der hardwareseitigen Verteilung des Produkttyps bzw. seiner Teilsysteme und der Einbettung in die physikalische Umgebung wird nicht benötigt.

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

Tabelle 1: Tab_Auth_Vers_002 - Verwendete Namensräume und Präfixe

Tabelle 2:  Tab_Auth_Vers_003 - Zuordnung Fehlercodes zu Fehlernamen

Tabelle 3: Tab_Auth_Vers_004 - Operationsabhängige Parameter des Verwaltungsprotokolls

Tabelle 4 : Tab_Auth_Vers_0016- Operationsabhängige Parameter des Verwaltungsprotokolls bei fehlerhaftem Aufruf der Operation loginCreateToken

Tabelle 5: Tab_Auth_Vers_005 - Schnittstellenübersicht der Komponente Authentisierung des Versicherten

Tabelle 6: Tab_Auth_Vers_006 - Benutzte Schnittstellen der TI

Tabelle 7: Tab_Auth_Vers_007 - Schnittstellenübersicht der Authentisierung des Versicherten

Tabelle 8: Tab_Auth_Vers_008 - Signatur der Schnittstelle I_Authentication_Insurant:loginCreateChallenge

Tabelle 9:  Tab_Auth_Vers_009 - Signatur der Schnittstelle I_Authentication_Insurant:loginCreateToken

Tabelle 10: Tab_Auth_Vers_010 - Signatur der Schnittstelle I_Authentication_Insurant::getAuditEvents

Tabelle 11: Tab_Auth_Vers_016 - Signatur der Schnittstelle I_Authentication_Insurant::getSignedAuditEvents

Tabelle 12: Tab_Auth_Vers_011 - Ablauf von loginCreateChallenge

Tabelle 13: Tab_Auth_Vers_012 - Ablauf von loginCreateToken

Tabelle 14: Tab_Auth_Vers_015 - Ablauf von RenewToken

Tabelle 15: Tab_Auth_Vers_015 - Ablauf von RenewToken

Tabelle 16: Tab_Auth_Vers_013 - Prüfschritte bei getAuditEvents

Tabelle 17: Tab_Auth_Vers_017 - Prüfschritte bei getSignedAuditEvents

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 passende jeweils gültige Versionsnummer ist in der aktuellen, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

8.5.2 Weitere Dokumente