gemSpec_Authentisierung_Vers_V1.3.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation Authentisierung des Versicherten ePA

    

     

      
Version
      
1.3.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
30.06.2020
     
     

      
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

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

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]).

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.

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

4.2 Verwendete Standards

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

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

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].

4.4 Protokollierung

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

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_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 4: 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 5: 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.

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_18985-02-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>

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>

5.1.1.1.4 Operation getAuditEvents

5.1.2 Umsetzung

5.1.2.1 Schnittstelle I_Authentication_Insurant

5.1.2.1.1 Operation login

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: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>

5.1.2.1.2 Operation Renew

5.1.2.1.3 Operation Logout

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.

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.

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

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