gemSpec_Authentisierung_Vers_V1.1.0_Aend

 

 

 

 

 

Elektronische Gesundheitskarte und Telematikinfrastruktur

 

 

 

 

Spezifikation Authentisierung des Versicherten ePA 

 

 

 

   

   

Version	1.01.0
Revision	548770
Stand	18.12.201815.05.2019
Status	in BearbeitungFreigegeben für interne QS
Klassifizierung	öffentlich
Referenzierung	gemSpec_Authentisierung_Vers

Dokumentinformationen

Änderungen zur Vorversion

Es handelt sich um die Erstversion des Dokuments.Einarbeitung Änderungsliste P18.1

Dokumentenhistorie

Version	Stand	Kap./ Seite	Grund der Änderung, besondere Hinweise	Bearbeitung
0.1.0	13.09.18		initiale Erstellung	gematik
1.0.0	18.12.18		freigegeben	gematik
			Einarbeitung Änderungsliste P18.1
1.1.0	15.05.2019		freigegeben	gematik

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 getAuditEventsrenew

5.1.2 Umsetzung5.1.1.1.3 Operation logout

5.1.2.1 Schnittstelle I_Authentication_Insurant5.1.1.1.4 Operation getAuditEvents

5.1.2.1.1 Operation login5.1.2 Umsetzung

5.1.2.1.2 Operation getAuditEvents5.1.2.1 Schnittstelle I_Authentication_Insurant

6 Informationsmodell5.1.2.1.1 Operation login

7 Verteilungssicht5.1.2.1.2 Operation Renew

8 Anhang A – Verzeichnisse5.1.2.1.3 Operation Logout

8.1 Abkürzungen5.1.2.1.4 Operation getAuditEvents

8.2 Glossar5.1.3 Lebensdauer der Authentifizierungsbestätigung

8.3 Abbildungsverzeichnis6 Informationsmodell

8.4 Tabellenverzeichnis7 Verteilungssicht

8.5 Referenzierte Dokumente8 Anhang A – Verzeichnisse

8.5.1 Dokumente der gematik8.1 Abkürzungen

8.5.2 Weitere Dokumente8.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_Fachanwendung_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 Anhang A5Kapitel 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_Fachanwendung_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 im Rahmen der Prüfung des Signaturzertifikats von erhaltenen Authentifizierungsbestätigungen (gem. gemSpec_TBAuth#A_15557) die folgenden Schritte ausführen:

•   Extraktion des verwendeten Signaturzertifikats und Zertifikatsprüfung durch Aufruf von TUC_PKI_018 [gemSpec_PKI] mit den Parametern:

Tabelle 1: Tab_Auth_Vers_001 - Aufrufparameter von TUC_PKI_018 zur Prüfung des Signaturzertifikats von Authentifizierungsbestätigungen

Parameter	Belegung
Zertifikat	Signaturzertifikat (eingebettet in Authentifizierungsbestätigung)
PolicyList	oid_fd_sig
intendedKeyUsage	digitalSignature
intendedExtendedKeyUsage	(leer)
OCSP-Graceperiod	60 Minuten
Offline-Modus	ja
Prüfmodus	nicht relevant

•   Prüfung der von TUC_PKI_018 zurückgelieferten Rolle auf den Wert "oid_epa_authn" gem. [gemSpec_OID]

[<=]  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 - InhaltsprüfungAussteller 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 - 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 406 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 - 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.4 [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 21: Tab_Auth_Vers_002 - Verwendete Namensräume und Präfixe

Präfix	Namensraum	Referenz
phra	http://ws.gematik.de/fd/phrs/AuthInsurantService/v1.0I_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 32:  Tab_Auth_Vers_003 - Zuordnung Fehlercodes zu Fehlernamen

[<=]

4.4 Protokollierung

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

A_13877 - Komponente Authentisierung Versicherter - Verwaltungsprotokollierung

Die Komponente "Authentisierung Versicherter" MUSS beim Aufruf einer der in [] aufgelisteten Operationen der Schnittstelle I_Authentication_Insurant je einen Eintrag im Verwaltungsprotokoll für den Versicherten bzw. seinen Vertreter gemäß [] vornehmen und die Parameterwerte dabei wie folgt setzen:

Tabelle 43: Tab_Auth_Vers_004 - Operationsabhängige Parameter des Verwaltungsprotokolls

Protokoll-parameter	Parameterwerte gemäß aufgerufener Operation
UserID	KVNR (im SubjectDN des bestätigten C.CH.AUT bzw. C.CH.AUT_ALT Zertifikats enthalten, s. Kap. 4.6).
UserName	subjectDN des als Parameter der Operation übergebenen C.CH.AUT Zertifikats. bzw. C.CH.AUT_ALT Zertifikats.
ObjectID	[nicht belegt]
ObjectName	[nicht belegt]
DeviceID	[nicht belegt]
übrige Protokolldaten	s. []

Die nicht aufgelisteten Operationen der Schnittstelle I_Authentication_Insurant werden nicht protokolliert. 

[<=]

A_13878 - Komponente Authentisierung Versicherter - Löschen von Protokolleinträgen

Die Komponente "Authentisierung Versicherter" MUSS sicherstellen, dass Protokolleinträge für jede bekannte UserID - außer den 50 jüngsten Protokolleinträgen - am Ende des auf ihre Generierung folgenden Kalenderjahres gelöscht werden. [<=]

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

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_Fachanwendung_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 eGK-den Zertifikaten entnommen und zur Identifikation herangezogen werden.

5 Funktionsmerkmale

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

Tabelle 54: 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 65: 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_Fachanwendung_ePA] definierte Schnittstelle bereit.

A_14228 - Komponente Authentisierung Versicherter - I_Authentication_Insurant:login/renew/logout nach WS-Trust

Die Komponente "Authentisierung Versicherter" MUSS einen Webservice-Endpunkt AuthInsurantService bereitstellen, welcher die logischen Schnittstellen I_Authentication_Insurant:login, I_Authentication_Insurant:renew und I_Authentication_Insurant:logout durch die folgenden angebotenen Operationen realisiert:

Tabelle 6: 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 1205 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).

A_14228 - Komponente Authentisierung Versicherter - I_Authentication_Insurant:login nach WS-Trust

Die Komponente "Authentisierung Versicherter" MUSS einen Webservice-Endpunkt AuthInsurantService bereitstellen, welcher die logische Schnittstelle I_Authentication_Insurant:login 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. [<=] 

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>
        <RequestSecurityTokenRequestedSecurityToken>
          <saml2:Assertion ...> ...         

          </saml2:Assertion>
        </RequestSecurityTokenRequestedSecurityToken>
      </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 87: 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 98:  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.

[<=]

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 - 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 - 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 - Komponente Authentisierung Versicherter - I_Authentication_Insurant::getAuditEvents

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

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

[<=]

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 1110: 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 1211: 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]</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:oasis:names:tc:xacml:1.0gematik: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 - 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 auf Basis des C.CH.AUT  bzw. C.CH.AUT_ALT Zertifikats gebildet 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+120Systemzeit + 5 Minuten) gesetzt werden.
• Das Element saml2:Conditions/saml2:AudienceRestriction/saml2:Audience muss auf den FQDN des Anbieters des Aktensystems in der TI gesetzt werden.
• 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:oasis:names:tc:xacml:1.0gematik: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 (vgl. [XSPA-SAML#2.10]).
• 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 12: 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.23 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 13: 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 1314: 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.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_001 - Aufrufparameter von TUC_PKI_018 zur Prüfung des Signaturzertifikats von AuthentifizierungsbestätigungenTabelle 1: Tab_Auth_Vers_002 - Verwendete Namensräume und Präfixe

Tabelle 2: Tab_Auth_Vers_002 - Verwendete Namensräume und PräfixeTabelle 2:  Tab_Auth_Vers_003 - Zuordnung Fehlercodes zu Fehlernamen

Tabelle 3:  Tab_Auth_Vers_003 - Zuordnung Fehlercodes zu Fehlernamen004 - Operationsabhängige Parameter des Verwaltungsprotokolls

Tabelle 4: Tab_Auth_Vers_004 - Operationsabhängige Parameter des VerwaltungsprotokollsTabelle 4: Tab_Auth_Vers_005 - Schnittstellenübersicht der Komponente Authentisierung des Versicherten

Tabelle 5: Tab_Auth_Vers_005 - Schnittstellenübersicht der Komponente Authentisierung des VersichertenTabelle 5: Tab_Auth_Vers_006 - Benutzte Schnittstellen der TI

Tabelle 6: Tab_Auth_Vers_006 - Benutzte Schnittstellen der TITabelle 6: Tab_Auth_Vers_007 - Schnittstellenübersicht der Authentisierung des Versicherten

Tabelle 7: Tab_Auth_Vers_007 - Schnittstellenübersicht der Authentisierung des Versicherten008 - Signatur der Schnittstelle I_Authentication_Insurant:loginCreateChallenge

Tabelle 8:  Tab_Auth_Vers_008009 - Signatur der Schnittstelle I_Authentication_Insurant:loginCreateChallengeloginCreateToken

Tabelle 9:  Tab_Auth_Vers_009010 - Signatur der Schnittstelle I_Authentication_Insurant:loginCreateToken:getAuditEvents

Tabelle 10: Tab_Auth_Vers_010011 - Signatur der Schnittstelle I_Authentication_Insurant::getAuditEventsAblauf von loginCreateChallenge

Tabelle 11: Tab_Auth_Vers_011012 - Ablauf von loginCreateChallengeloginCreateToken

Tabelle 12: Tab_Auth_Vers_012015 - Ablauf von loginCreateTokenRenewToken

Tabelle 13: Tab_Auth_Vers_013 - Prüfschritte bei getAuditEvents015 - Ablauf von RenewToken

Tabelle 14: Tab_Auth_Vers_013 - Prüfschritte bei getAuditEvents

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