Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation Konnektor

Basisdienst tokenbasierte Authentisierung

    

     

      
Version
      
1.4.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
15.05.2019
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_Kon_TBAuth
     
    

Dokumentinformationen

Änderungen zur Vorversion

Die Änderungen zur Vorversion sind gelb markiert.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Dieses Dokument enthält die Anforderungen an den Basisdienst tokenbasierte Authentisierung (BD-TBAuth), welches einen Teil des Produkttyps Konnektor darstellt. Der BD-TBAuth ist eine „Komfortfunktion“ im Rahmen der Authentisierung lokaler Benutzer. Dazu stellt er Identitätsbestätigungen aus, die mit der SM-B signiert werden. Dadurch müssen die Bestätigungen nicht vom Clientsystem selbst erzeugt werden. Der Konnektor gewährleistet dabei aber nicht, dass die behauptete Identität in der Identitätsbestätigung korrekt ist, bietet also keine zusätzliche Sicherheit an. Die Bestätigungen können für die Authentisierung gegenüber Gesundheitsdatendiensten in der TI genutzt werden.

1.2 Zielgruppe

Das Dokument richtet sich an Konnektorhersteller sowie Hersteller und Anbieter von Produkttypen und anderen Systemen, die mit dem BD-TBAuth (als Teil des Konnektors) interagieren. Letzteres betrifft sowohl Systemhersteller, die eine direkte Schnittstelle zum BD-TBAuth anbieten (z. B. Primärsysteme, Client, lokaler IDP), als auch Systemhersteller, die indirekt mit dem BD-TBAuth interagieren (z. B. Dienste).

1.3 Geltungsbereich

Dieses Dokument enthält normative Anforderungen und Festlegungen, die von Herstellern und Betreibern von Komponenten und Diensten im Rahmen der Projekte der Neuausrichtung zur Einführung der elektronischen Gesundheitskarte und der Telematik Infrastruktur des Deutschen Gesundheitswesens zu beachten sind.

Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung im Zulassungs- und Bestätigungsverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt 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 Arbeitsgrundlagen

Grundlagen für die Ausführung dieses Dokumentes sind insbesondere:

• Übergreifende Spezifikation tokenbasierte Authentisierung [gemSpec_TBAuth]
• Konzept Architektur der TI-Plattform [gemKPT_Arch_TIP]
• Konnektor-Spezifikation [gemSpec_Kon]
• OASIS WS-SecurityPolicy Spezifikation [WS-SecurityPolicy1.3]
• OASIS WS-Trust Spezifikation [WS-Trust1.3] [WS-Trust1.4]
• OASIS WS-Federation [WS-Federation1.2]

1.5 Abgrenzung des Dokuments

Spezifiziert werden in dem Dokument die vom Basisdienst tokenbasierte Authentisierung bereitgestellten (angebotenen) Schnittstellen.

Festlegungen, die nicht ausschließlich für den Basisdienst, sondern auch für andere Systeme gelten, werden in [gemSpec_TBAuth] getroffen. Dies umfasst insbesondere den Systemüberblick und Informationsmodelle.

Die Außenschnittstellen des Basisdienstes tokenbasierte Authentisierung sind in [gemKPT_Arch_TIP] beschrieben, welches die fachlichen Anforderungen an die Plattform auf Systemebene umsetzt. Für das Verständnis dieser Spezifikation wird die Kenntnis von [gemKPT_Arch_TIP] vorausgesetzt.

Angrenzende Systeme, z. B. Dienste, Clients, in der dezentralen Umgebung der TI betriebene IDPs (sog. lokale IDPs) und IDPs, die in der Provider-Zone der TI betrieben werden, werden nicht durch die gematik zugelassen und auch nicht in diesem Dokument beschrieben.

1.6 Methodik

1.6.1 Anforderungen

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

Sie werden im Dokument wie folgt dargestellt:

<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

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

1.6.2 Dokumentenstruktur

Anders als andere Plattformfunktionen des Konnektors, werden die TBAuth-Funktionen des Konnektors nicht in [gemSpec_Kon] sondern im vorliegenden Dokument beschrieben. Diese Untergliederung in mehrere Dokumente erlaubt eine stärkere Strukturierung der Inhalte und einfachere Handhabung der Dokumente.

1.6.3 Detaillierungstiefe

Diese Spezifikation beschreibt detailliert die Außenschnittstellen sowie relevante interne Funktionalitäten. Auf eine Beschreibung zusätzlicher interner sowie implementierungsabhängiger Details wird verzichtet.

2 Systemüberblick

Abbildung 1: Systemzerlegung tokenbasierte Authentisierung

Akteure, Rollen und Nachbarsysteme sind in [gemSpec_TBAuth#2] erläutert.

3 Übergreifende Festlegungen

3.1 Verwendete Identität der SM-B

Um die Authentifizierung und Autorisierung durchzuführen, müssen prüfende Dienste in der Lage sein, eindeutig zu erkennen, von welcher Institution eine Identitätsbestätigung ausgestellt wurde.

Der Konnektor prüft die Gültigkeit der SM-B regelmäßig und stellt somit sicher, dass die verwendete SM-B gültig ist.

3.2 Allgemein

Konfigurationsdaten werden über die Managementschnittstelle des Konnektors verwaltet.

3.3 Statusrückmeldung und Fehlerbehandlung

Für das Fehlermanagement gelten neben den hier aufgeführten spezifischen Anforderungen für den Basisdienst TBAuth die Anforderungen aus Kapitel 3 der übergreifenden Spezifikation [gemSpec_OM].

Da die Schnittstelle I_IDP_Auth_Passive_Client keine SOAP-Schnittstelle ist, gelten hierfür die Vorgaben aus [WS-Federation1.2] (siehe Kapitel 4.2).

3.4 Protokollierung

Die Protokollierung des Basisdienstes stützt sich auf das in [gemSpec_KON#4.1.10] definierte Funktionsmerkmal „Protokollierungsdienst“ des Konnektors. Zur Administration und Einsichtnahme in das Protokoll stellt der Konnektor dem Administrator eine Managementschnittstelle (s. [gemSpec_Kon#4.1.10.6]) zur Verfügung.

Laut [gemSpec_Kon#TIP1-A_4710] werden keine medizinischen und (außer bei Sicherheitsvorfällen) keine personenbezogenen Daten protokolliert.

Dem Administrator soll ermöglicht werden, aufgetretene Fehler jeglicher Art näher zu analysieren und erforderliche Maßnahmen zur Behebung abzuleiten.

3.5 Versionierung

Der Basisdienst TBAuth ist integraler Bestandteil des Konnektors und Teil von dessen Firmware-Version. Bezüglich der Selbstauskunft gelten die Festlegungen in [gemSpec_Kon#TIP1-A_4812].

3.6 Verwendete WS-Standards

Die Architektur des BD-TBAuth orientiert sich an der Elektronischen Fallakte (EFA) [EFA2.0] und basiert auf dazu kompatiblen Technologien und Standards. Trotzdem ist diese Schnittstelle nicht auf vollständige Kompatibilität zu EFA ausgelegt.

Die Fehlerbehandlung in [WS-Trust1.3#Kapitel11] und identisch [WS-Trust1.4#Kapitel11] legen den zu verwendenden SOAP-Fault-Mechanismus fest. Unter SOAP 1.1 wird ein Fehler über die Parameter faultcode und faultstring an den Aufrufer zurückgegeben. Es sind die [WS-Trust1.3#Kapitel11] bzw. [WS-Trust1.4#Kapitel11] per faultcode und faultstring angegebenen Fehler zu verwenden.

In sämtlichen Fehlernachrichten wird ein SOAPAction-Header verwendet. Das zu verwendende SOAPAction-Element für die WS-Trust Fehler gibt Tabelle TAB_BD_TBAuth_13 an.

Tabelle 1: TAB_BD_TBAuth_13 WS-Trust Fehler

Es ist im Sinne der Anforderung [TIP1-A_6883] das optionale Fault detail Element aus SOAP 1.1 in der Fehlernachricht nicht zu verwenden.

Zusätzlich zu den in [WS-Trust1.3#Kapitel11] bzw. [WS-Trust1.4#Kapitel11] definierten Fehlern werden ausschließlich die folgenden TI-spezifischen Fehler verwendet.

TI-spezifische Fehler sind immer einer Fehlerklasse zugeordnet, so dass festgelegt ist, welche dieser Fehler sicherheitsrelevant sind (ErrorType=Security).

4 Funktionsmerkmale

Folgend sind die Funktionsmerkmale des Basisdienstes TBAuth, seine Schnittstellen und Operationen definiert. Für jede Operation werden das an der Schnittstelle sichtbare und damit testbare Verhalten und die Berechtigungen normativ spezifiziert.

4.1 Schnittstelle I_IDP_Auth_Active_Client

Die Schnittstelle I_IDP_Auth_Active_Client stellt authentifizierten Aufrufern, mit nativen Clients in der dezentralen Umgebung der TI, Nutzeridentitätsbestätigungen gemäß [SAML2.0] aus und signiert diese mit der für tokenbasierte Authentisierung verwendeten Schlüssel auf der SM-B.

4.1.1 WSDL und Security Policy

4.1.2 SOAP-Envelope

4.1.3 Security Header

Da die Authentifizierung der Nutzer über die Mandanten-, Arbeitsplatz und Client-System-IDs umgesetzt wird, ist eine Signatur des Security Headers nicht erforderlich.

Beispiel

Mit Auslassungspunkten „…“ ausgewiesene Textstellen sind gekürzt.

<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=”1”>

    <wsu:Timestamp wsu:Id=“TS-e3fe5d9a-7940-4e95-9e5b-e550d3bbee01“>

        <wsu:Created>…</wsu:Created>

        <wsu:Expires>…</wsu:Expires>

    </wsu:Timestamp>

</wsse:Security>

4.1.4 Operation get_Metadata

Über diese Operation get_Metadata werden die Schnittstelle und Operationen publik gemacht, die durch aktive Clients verwendet werden können.

Beispiel:

Mit Auslassungspunkten „…“ ausgewiesene Textstellen sind gekürzt.

<soap:Envelope xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”>

    <soap:Header>

        <Action xmlns=”http://www.w3.org/2005/08/addressing”>http://schemas.xmlsoap.org/ws/2004/09/transfer/Get</Action>

        <MessageID xmlns=“http://www.w3.org/2005/08/addressing“>…</MessageID>

        <To xmlns=”http://www.w3.org/2005/08/addressing”>https://konnektor.konlan/sts/transport/mex</To>

        <ReplyTo xmlns=”http://www.w3.org/2005/08/addressing”>

            <Address>http://www.w3.org/2005/08/addressing/anonymous</Address>

        </ReplyTo>

    </soap:Header>

    <soap:Body/>

</soap:Envelope>

Beispiel:

Mit Auslassungspunkten „…“ ausgewiesene Textstellen sind gekürzt.

<soap:Envelope xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”>

    <soap:Header>

        <Action xmlns=”http://www.w3.org/2005/08/addressing”>http://schemas.xmlsoap.org/ws/2004/09/transfer/GetResponse</Action>

        <MessageID xmlns=“http://www.w3.org/2005/08/addressing“>…</MessageID>

        <To xmlns=”http://www.w3.org/2005/08/addressing”>http://www.w3.org/2005/08/addressing/anonymous</To>

        <RelatesTo xmlns=”http://www.w3.org/2005/08/addressing”>…</RelatesTo>

    </soap:Header>

    <soap:Body>

        <Metadata xmlns=”http://schemas.xmlsoap.org/ws/2004/09/mex”>

            <MetadataSection Dialect=”http://schemas.xmlsoap.org/wsdl/” Identifier=”http://docs.oasis-open.org/ws-sx/ws-trust/200512/”>

                …

        </Metadata>

    </soap:Body>

</soap:Envelope>

4.1.5 Operation issue_Identity_Assertion

4.1.5.1 Aufrufparameter issue_Identity_Assertion

Beispiel:

<wst:RequestSecurityToken xmlns:wst=”http://docs.oasis-open.org/ws-sx/ws-trust/200512”>

    <wsp:AppliesTo><saml2:Audience>urn:telematik:gesundheitsdatendienst:www:Instanz23</saml2:Audience></wsp:AppliesTo>

    <wst:Lifetime>

        <wsu:Created>2016-08-29T07:20:33.341Z</wsu:Created>

        <wsu:Expires>2016-08-29T07:50:33.341Z</wsu:Expires>

    </wst:Lifetime>

        <wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</wst:TokenType>

        <wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey</wst:KeyType>

    <wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>

    <wst:UseKey>

        <ds:KeyInfo xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”>

            <ds:KeyValue>

                <ds:RSAKeyValue>

                    <ds:Modulus>oh83Kp6+Pj5yoYml1uayO2UupCq69pZxWbhCco6Q7X4YaRQ+Zc3DGqKUU8U89
1/qt2hVe9yAjTe9btPKdC8gyidZi+/0Y+h19KGRA8GgrCbSQa8gMk/9FJqJF42CqSZAAOAb2Z/sAZOe4bCiO1D1i2KAC+
/cHUEy+RyX61ud7833GadG0JxjcVTHg+kIDTASC16r5KATsErPHmgjmFEamnCBRN9WTDymQxSGotQYFbdSgGTKtrPeoEl
I6McXOZN0VoqDQ+7G2OhGLxqyyA3gpT+js0j6j3jILdxTWGMBCeeKgq3kfoP2OqOwD0EIFQVnD2SamJham5O45n4tbr
GPxw==</ds:Modulus>

                    <ds:Exponent>AQAB</ds:Exponent>

                </ds:RSAKeyValue>

            </ds:KeyValue>

        </ds:KeyInfo>

    </wst:UseKey>

    <wst:Renewing/>

    <gem:workplaceId>a1</gem:workplaceId>

    <gem:mandantId>m1</gem:mandantId>

    <gem:clientSystemId>cs1</gem:clientSystemtId>

    <gem:iccsn>123456789123456789</gem:iccsn>

</wst:RequestSecurityToken>

4.1.5.2 Rückgabewerte issue_Identity_Assertion

4.1.6 Operation renew_Identity_Assertion

Diese Operation ermöglicht das Erneuern einer vorhandenen Identitätsbestätigung basierend auf WS-Trust, SAML 2.0 Assertions, und WS Federation für Active Requestor Profile. Die erneuerte Identitätsbestätigung wird grundsätzlich nicht verändert, sondern unterscheidet sich zur ursprünglichen Identitätsbestätigung im Wesentlichen durch eine aktualisierte Gültigkeitsdauer und eine aktualisierte Signatur.

Aufrufe der Operation renew_Identity_Assertion kann der BD-TBAuth anhand der Signatur des Aufrufs und anhand der Parameter /wst:RequestSecurityToken /gem:workplaceId und /wst:RequestSecurityToken /gem:mandantId dem Benutzer zuordnen.

4.1.6.1 Aufrufparameter renew_Identity_Assertion

Beispiel:

<wst:RequestSecurityToken xmlns:wst=”http://docs.oasis-open.org/ws-sx/ws-trust/200512”>

    <wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Renew</wst:RequestType>

    <wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</wst:TokenType>

    <wst:Lifetime xmlns:wsu=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd”>

        <wsu:Created>2016-10-12T17:27:02.768Z</wsu:Created>

        <wsu:Expires>2016-10-12T17:32:02.768Z</wsu:Expires>

    </wst:Lifetime>

    <wst:RenewTarget>

        <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=”_aa3a0632-aff2-4b3b-9d4e-2a3ede2b6410” IssueInstant=”2016-10-12T17:26:22.933Z” Version=”2.0” xsi:type=”saml2:AssertionType”>

            <saml2:Issuer>1-1a25sd-d529</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/2001/04/xmldsig-more#rsa-sha256”/>

                    <ds:Reference URI=”#_aa3a0632-aff2-4b3b-9d4e-2a3ede2b6410”>

                        <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>Yqu92UhpYiLIvb5EqxLPqnzS6FGU07ejILo4ED6qrts=</ds:DigestValue>

                    </ds:Reference>

                </ds:SignedInfo>

                <ds:SignatureValue>KFD7r91D6JXUQbW2IjjhfX0ziAmxjoUa/v6cnCyF0Io19IedbFUdd8sJDcOT0fEFbD
TmaRvsly+NH/22StRI1zx0WmtFQPLl4YhRyQ9PQtm1zC87F/jJksl2DW4iabHwEdsld8SxyV49MTHt7XsZ0GuKSsA5G7xSbazUzqp
GkOBLW6fhKNIc/i+vXP5edEtPrs3t1scxG/7HpfbISUV5dFojHKft1Vs20eN812gMpFpw1hiBuNBSh5r4VG1l+yEmott0V7L+LvgS
u+GGA9eIDvHWmU0xAlNgea57XZYGqSghGppGJUzRT/P1pY5kIjVE13ePb9WQrgkKwXG8mNiXXg==</ds:SignatureValue>

                <ds:KeyInfo>

                    <ds:X509Data>

                        <ds:X509Certificate>MIIFEzCCA/ugAwIBAgIHA8zEnhRtVTANBgkqhkiG9w0BAQsFADCBmTELMA
kGA1UEBhMCREUxHzAd BgNVBAoMFmdlbWF0aWsgR21iSCBOT1QtVkFMSUQxSDBGBgNVBAsMP0luc3RpdHV0aW9uIGRlcyBH ZXN1bmRoZWl0c3dlc2Vucy1DQSBkZXIgVGVsZW1hdGlraW5mcmFzdHJ1a3R1cjEfMB0GA1UEAwwW R0VNLlNNQ0ItQ0E3IFRFU1QtT05MWTAeFw0xNTA2MzAwMDAwMDBaFw0yMDA2MzAwMDAwMDBaMIHH MQswCQYDVQQGEwJERTEYMBYGA1UECAwPQmVpc3BpZWxzdO+/vWR0MRgwFgYDVQQHDA9CZWlz MQswCQYDVQQGEwJERTEYMBYGA1UECAwPQmVpc3BpZWxzdO+cGll bHN077+9ZHQxDjAMBgNVBBEMBTAxMjM0MRswGQYDVQQJDBJHZXN1bmRoZWl0c2dhc3NlIDMx bHN077+DzAN BgNVBAUTBjEwMDAwMTFGMEQGA1UEAww9S3JhbmtlbmhhdXMgQmVpc3BpZWxzdO+/vWR0Luts BgNVBAUTBjEwMDAwMTFGMEQGA1UEAww9S3JhbmtlbmhhdXMgQmVpc3BpZWxzdO+aW5p ayBm77+9ciBLYXJkaW9sb2dpZVRFU1QtT05MWTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC ayBm77+AqoC ggEBAL/uetzxukiQQ4yd9gVyK5ZtgCrxzAH5ZlPoJcKOKo+oKZ5i/NpgjkXCBQl25gXuQJACkEjN pa3E2JqOXLgwsLTZXVShc8v1b49DcbNPSDswWTnE7NwF7RemmnP9aKunqehFNUicRABfGa0j4Las 8eV3bqRg9y/+Cx6Y9GFr5OdfxLYs73HE7T1k7s9L7ufJtSfpm0FqZY5dkZk3a9jxbSJ3ovDBaL30 h3uKxTvBMU+przKZC/xf84Kjjxm1+PGD7I5/NTcCCX5w8uxKW/tNqQTFkhsArP4XdSIKiiyG h3uKxTvBMU+XrAM Yboa/oOlH/pF3LepfgHPXLfid5uOdT5+hpsoU/UkvBUCAwEAAaOCAS4wggEqMB0GA1UdDgQWBBQp 9vXBG9pPNsqBE1LNDe26RYztJzATBgNVHSUEDDAKBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMDoG BSskCAMDBDEwLzAtMCswKTAnMA0MC0tyYW5rZW5oYXVzMAkGByqCFABMBDUTCzUtMklLLTMxNDE1 MB8GA1UdIwQYMBaAFDw5CixOUpeco4wu+AhSBLSZD2rnMCwGA1UdIAQlMCMwCgYIKoIUAEwE MB8GA1UdIwQYMBaAFDw5CixOUpeco4wu+gSMw CQYHKoIUAEwETTAKBggqghQATASBKjAOBgNVHQ8Baf8EBAMCBaAwSwYIKwYBBQUHAQEEPzA9MDsG CCsGAQUFBzABhi9odHRwOi8vb2NzcC5wa2kudGVsZW1hdGlrLXRlc3Q6ODA4MC9DTU9DU1AvT0NT UDANBgkqhkiG9w0BAQsFAAOCAQEAC9tRPAgRoamvei0eX5IiHmj/mt4zX9kvhNRe3HMBUYMnvV10 J4h7EaT8/PeXBCtbari4xfqD+WDQhEayWYfsKL5GTFuzQXExgt0r5aZdH6V8kChXJ7JldKNiS7QH rt1ZohY7qPLpDdYqQS99Uy79h7Y+MsZh1sI/1wCSQ/Tl5uVgjTM8q+0xI49VHVzebsGHLRdW rt1ZohY7qPLpDdYqQS99Uy79h7Y+VAZa W7DibaeP30G7r36nBfc5LBJm9MghL88Wgi/JPd4l09gQWfxRV0yiUlp9LQ+yUlAM13BesZ3Niu3q vrHiTD0Y0QrOR2/AM4ETNPa0Kc/ClzkyBZhng/B3cwdTNcVuFWINmEDLGNmycyN0Pw==</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”>2.5.4.5=#130c313233343536373839303133,2.5.4.42=#0c0848
65696e72696368,2.5.4.4=#0c03466974,CN=Dr. med. Heinrich Fit\, Facharzt für Physikalische Therapie,C=DE</saml2:NameID>

                <saml2:SubjectConfirmation Method=”urn:oasis:names:tc:SAML:2.0:cm:holder-of-key”>

                    <saml2:SubjectConfirmationData xsi:type=”saml2:KeyInfoConfirmationDataType”>

                        <ds:KeyInfo xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”>

                            <ds:KeyValue>

                                <ds:RSAKeyValue>

                                    <ds:Modulus>oh83Kp6+Pj5yoYml1uayO2UupCq69pZxWbhCco6Q7X4YaRQ+Zc
3DGqKUU8U891/qt2hVe9yAjTe9btPKdC8gyidZi+/0Y+h19KGRA8GgrCbSQa8gMk/9FJqJF42CqSZAAOAb2Z/sAZOe4bCiO1D1
i2KAC+/cHUEy+RyX61ud7833GadG0JxjcVTHg+kIDTASC16r5KATsErPHmgjmFEamnCBRN9WTDymQxSGotQYFbdSgGTKtrPeoEl
I6McXOZN0VoqDQ+7G2OhGLxqyyA3gpT+js0j6j3jILdxTWGMBCeeKgq3kfoP2OqOwD0EIFQVnD2SamJham5O45n4tbrGPx
w==</ds:Modulus>

                                    <ds:Exponent>AQAB</ds:Exponent>

                                </ds:RSAKeyValue>

                            </ds:KeyValue>

                        </ds:KeyInfo>

                    </saml2:SubjectConfirmationData>

                </saml2:SubjectConfirmation>

            </saml2:Subject>

            <saml2:Conditions NotBefore=”2016-10-12T17:26:22.933Z” NotOnOrAfter=”2016-10-12T17:56:22.933Z”/>

            <saml2:AuthnStatement AuthnInstant=”2016-10-12T17:26:22.933Z”>

                <saml2:AuthnContext>

                    <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Smartcard
</saml2:AuthnContextClassRef>

                </saml2:AuthnContext>

            </saml2:AuthnStatement>

            <saml2:AttributeStatement>

                <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">

                    <saml2:AttributeValue>Heinz Müller</saml2:AttributeValue>

                </saml2:Attribute>

                <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">

                    <saml2:AttributeValue>Heinz</saml2:AttributeValue>

                </saml2:Attribute>

                <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">

                    <saml2:AttributeValue>Müller</saml2:AttributeValue>

                </saml2:Attribute>

                <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country">

                    <saml2:AttributeValue>Deutschland</saml2:AttributeValue>

                </saml2:Attribute>

                <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">

                    <saml2:AttributeValue>test@example.com</saml2:AttributeValue>

                </saml2:Attribute>

                <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier">

                    <saml2:AttributeValue>1-1a25sd-d529</saml2:AttributeValue>

                </saml2:Attribute>

            </saml2:AttributeStatement>

        </saml2:Assertion>

    </wst:RenewTarget>

    <wst:Renewing Allow=”true”/>

    <gem:workplaceId>a1</gem:workplaceId>
   <gem:mandantId>m1</gem:mandantId>
   <gem:clientSystemId>cs1</gem:clientSystemtId>

</wst:RequestSecurityToken>

4.1.6.2 Rückgabewerte renew_Identity_Assertion

Beispiel:

<ns2:RequestSecurityTokenResponse xmlns=”http://docs.oasis-open.org/ws-sx/ws-trust/200802” xmlns:ns2=”http://docs.oasis-open.org/ws-sx/ws-trust/200512” xmlns:ns3=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd” xmlns:ns4=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd” xmlns:ns5=”http://www.w3.org/2005/08/addressing”>

    <ns2:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0</ns2:TokenType>

    <ns2:RequestedSecurityToken>

        <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=”_a714bd3a-4c94-40fb-87fb-3db5964c1623” IssueInstant=”2016-10-12T17:26:23.397Z” Version=”2.0” xsi:type=”saml2:AssertionType”>

            <saml2:Issuer>1-1a25sd-d529</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/2001/04/xmldsig-more#rsa-sha256”/>

                    <ds:Reference URI=”#_a714bd3a-4c94-40fb-87fb-3db5964c1623”>

                        <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>xLswm3sg5aSXxwiL+CMQkgrGnkoO9x1PMz+eSnSjlB8=</ds:DigestValue>

                    </ds:Reference>

                </ds:SignedInfo>

                <ds:SignatureValue>NFNQkpgfBRxToA1QCb02K/4AwRTH9Kgdy0vb1d1qVBSypoRuWTenVmQ/+O9e+tsCMb
8cH4U6A6Qv7fwWkB21xrrQ4x/4uAFH3DP5/wMuqp3CyD6+rdiDcnz85Hw1a2G4R6vcfm/mZvUniCSkT7p/+7AvgZwnAqyCVakVH24
VaMutl1lCm17f8wVEaUVW1dO/Cz7sciGBxlxZmAG+E/CIY7oEr2maHJc+/H4OFHjJxO6zauzNtGwmEUfqMda7SPf55O52jlhbX2ES
GyEBQS2P6SJEMyVHLrwkFPeyE07bSk57WkM5++y8uqpl4RrXa4LyffnD9z6l0i0zvzYgCCjkJA==</ds:SignatureValue>

                <ds:KeyInfo>

                    <ds:X509Data>

                        <ds:X509Certificate>MIIFEzCCA/ugAwIBAgIHA8zEnhRtVTANBgkqhkiG9w0BAQsFADCBmTELMA
kGA1UEBhMCREUxHzAd BgNVBAoMFmdlbWF0aWsgR21iSCBOT1QtVkFMSUQxSDBGBgNVBAsMP0luc3RpdHV0aW9uIGRlcyBH ZXN1bmRoZWl0c3dlc2Vucy1DQSBkZXIgVGVsZW1hdGlraW5mcmFzdHJ1a3R1cjEfMB0GA1UEAwwW R0VNLlNNQ0ItQ0E3IFRFU1QtT05MWTAeFw0xNTA2MzAwMDAwMDBaFw0yMDA2MzAwMDAwMDBaMIHH MQswCQYDVQQGEwJERTEYMBYGA1UECAwPQmVpc3BpZWxzdO+/vWR0MRgwFgYDVQQHDA9CZWlz MQswCQYDVQQGEwJERTEYMBYGA1UECAwPQmVpc3BpZWxzdO+cGll bHN077+9ZHQxDjAMBgNVBBEMBTAxMjM0MRswGQYDVQQJDBJHZXN1bmRoZWl0c2dhc3NlIDMx bHN077+DzAN BgNVBAUTBjEwMDAwMTFGMEQGA1UEAww9S3JhbmtlbmhhdXMgQmVpc3BpZWxzdO+/vWR0Luts BgNVBAUTBjEwMDAwMTFGMEQGA1UEAww9S3JhbmtlbmhhdXMgQmVpc3BpZWxzdO+aW5p ayBm77+9ciBLYXJkaW9sb2dpZVRFU1QtT05MWTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC ayBm77+AqoC ggEBAL/uetzxukiQQ4yd9gVyK5ZtgCrxzAH5ZlPoJcKOKo+oKZ5i/NpgjkXCBQl25gXuQJACkEjN pa3E2JqOXLgwsLTZXVShc8v1b49DcbNPSDswWTnE7NwF7RemmnP9aKunqehFNUicRABfGa0j4Las 8eV3bqRg9y/+Cx6Y9GFr5OdfxLYs73HE7T1k7s9L7ufJtSfpm0FqZY5dkZk3a9jxbSJ3ovDBaL30 h3uKxTvBMU+przKZC/xf84Kjjxm1+PGD7I5/NTcCCX5w8uxKW/tNqQTFkhsArP4XdSIKiiyG h3uKxTvBMU+XrAM Yboa/oOlH/pF3LepfgHPXLfid5uOdT5+hpsoU/UkvBUCAwEAAaOCAS4wggEqMB0GA1UdDgQWBBQp 9vXBG9pPNsqBE1LNDe26RYztJzATBgNVHSUEDDAKBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMDoG BSskCAMDBDEwLzAtMCswKTAnMA0MC0tyYW5rZW5oYXVzMAkGByqCFABMBDUTCzUtMklLLTMxNDE1 MB8GA1UdIwQYMBaAFDw5CixOUpeco4wu+AhSBLSZD2rnMCwGA1UdIAQlMCMwCgYIKoIUAEwE MB8GA1UdIwQYMBaAFDw5CixOUpeco4wu+gSMw CQYHKoIUAEwETTAKBggqghQATASBKjAOBgNVHQ8Baf8EBAMCBaAwSwYIKwYBBQUHAQEEPzA9MDsG CCsGAQUFBzABhi9odHRwOi8vb2NzcC5wa2kudGVsZW1hdGlrLXRlc3Q6ODA4MC9DTU9DU1AvT0NT UDANBgkqhkiG9w0BAQsFAAOCAQEAC9tRPAgRoamvei0eX5IiHmj/mt4zX9kvhNRe3HMBUYMnvV10 J4h7EaT8/PeXBCtbari4xfqD+WDQhEayWYfsKL5GTFuzQXExgt0r5aZdH6V8kChXJ7JldKNiS7QH rt1ZohY7qPLpDdYqQS99Uy79h7Y+MsZh1sI/1wCSQ/Tl5uVgjTM8q+0xI49VHVzebsGHLRdW rt1ZohY7qPLpDdYqQS99Uy79h7Y+VAZa W7DibaeP30G7r36nBfc5LBJm9MghL88Wgi/JPd4l09gQWfxRV0yiUlp9LQ+yUlAM13BesZ3Niu3q vrHiTD0Y0QrOR2/AM4ETNPa0Kc/ClzkyBZhng/B3cwdTNcVuFWINmEDLGNmycyN0Pw==</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”>2.5.4.5=#130c313233343536373839303133,2.5.4.42=#0c084865696e
72696368,2.5.4.4=#0c03466974,CN=Dr. med. Heinrich Fit\, Facharzt für Physikalische Therapie,C=DE</saml2:NameID>

                <saml2:SubjectConfirmation Method=”urn:oasis:names:tc:SAML:2.0:cm:holder-of-key”>

                    <saml2:SubjectConfirmationData xsi:type=”saml2:KeyInfoConfirmationDataType”>

                        <ds:KeyInfo xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”>

                            <ds:KeyValue>

                                <ds:RSAKeyValue>

                                    <ds:Modulus>oh83Kp6+Pj5yoYml1uayO2UupCq69pZxWbhCco6Q7X4YaRQ+Zc3DGq
KUU8U891/qt2hVe9yAjTe9btPKdC8gyidZi+/0Y+h19KGRA8GgrCbSQa8gMk/9FJqJF42CqSZAAOAb2Z/sAZOe4bCiO1D1i2KAC+/c
HUEy+RyX61ud7833GadG0JxjcVTHg+kIDTASC16r5KATsErPHmgjmFEamnCBRN9WTDymQxSGotQYFbdSgGTKtrPeoElI6McXOZN0Vo
qDQ+7G2OhGLxqyyA3gpT+js0j6j3jILdxTWGMBCeeKgq3kfoP2OqOwD0EIFQVnD2SamJham5O45n4tbrGPxw==</ds:Modulus>

                                    <ds:Exponent>AQAB</ds:Exponent>

                                </ds:RSAKeyValue>

                            </ds:KeyValue>

                        </ds:KeyInfo>

                    </saml2:SubjectConfirmationData>

                </saml2:SubjectConfirmation>

            </saml2:Subject>

            <saml2:Conditions NotBefore=”2016-10-12T17:27:02.768Z” NotOnOrAfter=”2016-10-12T17:32:02.768Z”/>

            <saml2:AuthnStatement AuthnInstant=”2016-10-12T17:26:22.933Z”>

                <saml2:AuthnContext>

                    <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Smartcard<
/saml2:AuthnContextClassRef>

                </saml2:AuthnContext>

            </saml2:AuthnStatement>

            <saml2:AttributeStatement>

                <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">

                    <saml2:AttributeValue>Heinz Müller</saml2:AttributeValue>

                </saml2:Attribute>

                <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">

                    <saml2:AttributeValue>Heinz</saml2:AttributeValue>

                </saml2:Attribute>

                <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">

                    <saml2:AttributeValue>Müller</saml2:AttributeValue>

                </saml2:Attribute>

                <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country">

                    <saml2:AttributeValue>Deutschland</saml2:AttributeValue>

                </saml2:Attribute>

                <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">

                    <saml2:AttributeValue>test@example.com</saml2:AttributeValue>

                </saml2:Attribute>

                <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier">

                    <saml2:AttributeValue>1-1a25sd-d529</saml2:AttributeValue>

                </saml2:Attribute>

            </saml2:AttributeStatement>

        </saml2:Assertion>

    </ns2:RequestedSecurityToken>

    <ns2:RequestedAttachedReference>

        <ns4:SecurityTokenReference xmlns:wsse11=”http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd” wsse11:TokenType=”http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0”>

            <ns4:KeyIdentifier ValueType=”http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID”>_a714bd3a-4c94-40fb-87fb-3db5964c1623</ns4:KeyIdentifier>

        </ns4:SecurityTokenReference>

    </ns2:RequestedAttachedReference>

    <ns2:RequestedUnattachedReference>

        <ns4:SecurityTokenReference xmlns:wsse11=”http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd” wsse11:TokenType=”http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0”>

            <ns4:KeyIdentifier ValueType=”http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID”>_a714bd3a-4c94-40fb-87fb-3db5964c1623</ns4:KeyIdentifier>

        </ns4:SecurityTokenReference>

    </ns2:RequestedUnattachedReference>

    <ns2:Lifetime>

        <ns3:Created>2016-10-12T17:27:02.768Z</ns3:Created>

        <ns3:Expires>2016-10-12T17:32:02.768Z</ns3:Expires>

    </ns2:Lifetime>

</ns2:RequestSecurityTokenResponse>

4.1.7 Operation cancel_Identity_Assertion

Die Operation erlaubt das Annullieren bestehender Identitätsbestätigungen. Die Reichweite der Annullierung beschränkt sich jedoch auf den Konnektor, wodurch die Erneuerung bestehender Identitätsbestätigungen unterbunden wird. Bestehende Sitzungen und die Verwendung bereits ausgestellter Identitätsbestätigungen gegenüber etwaigen anderen Systemen werden hierdurch nicht berührt.

Aufrufe der Operation renew_Identity_Assertion kann der BD-TBAuth anhand der Signatur des Aufrufs und anhand der Parameter /wst:RequestSecurityToken /gem:workplaceId und /wst:RequestSecurityToken /gem:mandantId dem Benutzer zuordnen.

4.1.7.1 Aufrufparameter cancel_Identity_Assertion

Beispiel:

<wst:RequestSecurityToken xmlns:wst=”http://docs.oasis-open.org/ws-sx/ws-trust/200512”>

    <wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Cancel</wst:RequestType>

    <wst:CancelTarget>

        <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=”_e5dcb3a4-64be-4255-8d25-18fe477ff2ad” IssueInstant=”2016-10-21T13:36:55.544Z” Version=”2.0” xsi:type=”saml2:AssertionType”>

            <saml2:Issuer>1-1a25sd-d529</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/2001/04/xmldsig-more#rsa-sha256”/>

                    <ds:Reference URI=”#_e5dcb3a4-64be-4255-8d25-18fe477ff2ad”>

                        <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>gipJOTYEnBwZMptZL7EzhQV47Y/ucoI0r6tC/sqQIgQ=</ds:DigestValue>

                    </ds:Reference>

                </ds:SignedInfo>

                <ds:SignatureValue>p9FO92d48/5thTpEpAl3ALF1ltukpbR6TM+qqprzoqqUKRf6Cmbt9MApIcULG4PfIA7
gYsjxyOVUrGYT+YepBji/M5TPjLMCqykuEBlrLuH5meSH1BtTLVBfrDDSs5lPT9F/qYCkpp48VukVlI3t7V+6QfTKA0wJqORwgjpES
k+8lCoa93Ty1u7FBl7sSF5bZe3N0yNWSWgrNWyTfF7B8VAMSyGDa2PQ1nZgv7b1HV+texouluiKfmexokoVDftYzXNpvxsppqv6keh
seybtVpvi1djb1CFG1ZjKkObGmlRU6RMNuIPbZqq9PF1SUFdPo1FjpAidDvmAFbfget6Ezw==</ds:SignatureValue>

                <ds:KeyInfo>

                    <ds:X509Data>

                        <ds:X509Certificate>MIIFEzCCA/ugAwIBAgIHA8zEnhRtVTANBgkqhkiG9w0BAQsFADCBmTELMAk
GA1UEBhMCREUxHzAd
    BgNVBAoMFmdlbWF0aWsgR21iSCBOT1QtVkFMSUQxSDBGBgNVBAsMP0luc3RpdHV0aW9uIGRlcyBH

    ZXN1bmRoZWl0c3dlc2Vucy1DQSBkZXIgVGVsZW1hdGlraW5mcmFzdHJ1a3R1cjEfMB0GA1UEAwwW

    R0VNLlNNQ0ItQ0E3IFRFU1QtT05MWTAeFw0xNTA2MzAwMDAwMDBaFw0yMDA2MzAwMDAwMDBaMIHH

    MQswCQYDVQQGEwJERTEYMBYGA1UECAwPQmVpc3BpZWxzdO+/vWR0MRgwFgYDVQQHDA9CZWlzcGll

    bHN077+9ZHQxDjAMBgNVBBEMBTAxMjM0MRswGQYDVQQJDBJHZXN1bmRoZWl0c2dhc3NlIDMxDzAN

    BgNVBAUTBjEwMDAwMTFGMEQGA1UEAww9S3JhbmtlbmhhdXMgQmVpc3BpZWxzdO+/vWR0LutsaW5p

    ayBm77+9ciBLYXJkaW9sb2dpZVRFU1QtT05MWTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC

    ggEBAL/uetzxukiQQ4yd9gVyK5ZtgCrxzAH5ZlPoJcKOKo+oKZ5i/NpgjkXCBQl25gXuQJACkEjN

    pa3E2JqOXLgwsLTZXVShc8v1b49DcbNPSDswWTnE7NwF7RemmnP9aKunqehFNUicRABfGa0j4Las

    8eV3bqRg9y/+Cx6Y9GFr5OdfxLYs73HE7T1k7s9L7ufJtSfpm0FqZY5dkZk3a9jxbSJ3ovDBaL30

    h3uKxTvBMU+przKZC/xf84Kjjxm1+PGD7I5/NTcCCX5w8uxKW/tNqQTFkhsArP4XdSIKiiyGXrAM

    Yboa/oOlH/pF3LepfgHPXLfid5uOdT5+hpsoU/UkvBUCAwEAAaOCAS4wggEqMB0GA1UdDgQWBBQp

    9vXBG9pPNsqBE1LNDe26RYztJzATBgNVHSUEDDAKBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMDoG

    BSskCAMDBDEwLzAtMCswKTAnMA0MC0tyYW5rZW5oYXVzMAkGByqCFABMBDUTCzUtMklLLTMxNDE1

    MB8GA1UdIwQYMBaAFDw5CixOUpeco4wu+AhSBLSZD2rnMCwGA1UdIAQlMCMwCgYIKoIUAEwEgSMw

    CQYHKoIUAEwETTAKBggqghQATASBKjAOBgNVHQ8Baf8EBAMCBaAwSwYIKwYBBQUHAQEEPzA9MDsG

    CCsGAQUFBzABhi9odHRwOi8vb2NzcC5wa2kudGVsZW1hdGlrLXRlc3Q6ODA4MC9DTU9DU1AvT0NT

    UDANBgkqhkiG9w0BAQsFAAOCAQEAC9tRPAgRoamvei0eX5IiHmj/mt4zX9kvhNRe3HMBUYMnvV10

    J4h7EaT8/PeXBCtbari4xfqD+WDQhEayWYfsKL5GTFuzQXExgt0r5aZdH6V8kChXJ7JldKNiS7QH

    rt1ZohY7qPLpDdYqQS99Uy79h7Y+MsZh1sI/1wCSQ/Tl5uVgjTM8q+0xI49VHVzebsGHLRdWVAZa

    W7DibaeP30G7r36nBfc5LBJm9MghL88Wgi/JPd4l09gQWfxRV0yiUlp9LQ+yUlAM13BesZ3Niu3q

    vrHiTD0Y0QrOR2/AM4ETNPa0Kc/ClzkyBZhng/B3cwdTNcVuFWINmEDLGNmycyN0Pw==</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”>2.5.4.5=#130c313233343536373839303133,2.5.4.42=#0c08486
5696e72696368,2.5.4.4=#0c03466974,CN=Dr. med. Heinrich Fit\, Facharzt f³r Physikalische Therapie,C=DE</saml2:NameID>

                <saml2:SubjectConfirmation Method=”urn:oasis:names:tc:SAML:2.0:cm:holder-of-key”>

                    <saml2:SubjectConfirmationData xsi:type=”saml2:KeyInfoConfirmationDataType”>

                        <ds:KeyInfo xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”>

                            <ds:KeyValue>

                                <ds:RSAKeyValue>

                                    <ds:Modulus>oh83Kp6+Pj5yoYml1uayO2UupCq69pZxWbhCco6Q7X4YaRQ+Zc
3DGqKUU8U891/qt2hVe9yAjTe9btPKdC8gyidZi+/0Y+h19KGRA8GgrCbSQa8gMk/9FJqJF42CqSZAAOAb2Z/sAZOe4bCiO1D1
i2KAC+/cHUEy+RyX61ud7833GadG0JxjcVTHg+kIDTASC16r5KATsErPHmgjmFEamnCBRN9WTDymQxSGotQYFbdSgGTKtrPeoE
lI6McXOZN0VoqDQ+7G2OhGLxqyyA3gpT+js0j6j3jILdxTWGMBCeeKgq3kfoP2OqOwD0EIFQVnD2SamJham5O45n4tbrGPxw==
</ds:Modulus>

                                    <ds:Exponent>AQAB</ds:Exponent>

                                </ds:RSAKeyValue>

                            </ds:KeyValue>

                        </ds:KeyInfo>

                    </saml2:SubjectConfirmationData>

                </saml2:SubjectConfirmation>

            </saml2:Subject>

            <saml2:Conditions NotBefore=”2016-10-21T13:36:55.544Z” NotOnOrAfter=”2016-10-21T14:06:55.544Z”/>

            <saml2:AuthnStatement AuthnInstant=”2016-10-21T13:36:55.544Z”>

                <saml2:AuthnContext>

                    <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Smartcard
</saml2:AuthnContextClassRef>

                </saml2:AuthnContext>

            </saml2:AuthnStatement>

            <saml2:AttributeStatement>

                <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">

                    <saml2:AttributeValue>Heinz Müller</saml2:AttributeValue>

                </saml2:Attribute>

                <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">

                    <saml2:AttributeValue>Heinz</saml2:AttributeValue>

                </saml2:Attribute>

                <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">

                    <saml2:AttributeValue>Müller</saml2:AttributeValue>

                </saml2:Attribute>

                <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country">

                    <saml2:AttributeValue>Deutschland</saml2:AttributeValue>

                </saml2:Attribute>

                <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">

                    <saml2:AttributeValue>test@example.com</saml2:AttributeValue>

                </saml2:Attribute>

                <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier">

                    <saml2:AttributeValue>1-1a25sd-d529</saml2:AttributeValue>

                </saml2:Attribute>

            </saml2:AttributeStatement>

        </saml2:Assertion>

    </wst:CancelTarget>

</wst:RequestSecurityToken>

4.1.7.2 Rückgabewerte cancel_Identity_Assertion

Beispiel:

<wst:RequestSecurityTokenResponse>

    <wst:RequestedTokenCancelled/>

</wst:RequestSecurityTokenResponse>

4.2 Schnittstelle I_IDP_Auth_Passive_Client

Die Schnittstelle I_IDP_Auth_Passive_Client realisiert Operationen für Webbrowser zur Erzeugung und Annullierung von Identitätsbestätigungen.

4.2.1 Operation signIn

Es soll ermöglicht werden, dass entsprechende persistente Cookies auf Arbeitsplatzsystemen möglichst einfach vorinstalliert werden können, wofür auch die Entwicklung entsprechender Software-Tools hilfreich sein kann. Daher sollen die im persistenten Cookie hinterlegten Daten durch Dritte, z. B. Leistungserbringerinstitutionen, Administratoren und Softwarehersteller, verändert werden können.

Für ein Beispiel siehe Anhang C1.

4.2.2 Operation signOut

Diese Operation ermöglicht das Abmelden basierend auf [WS-Federation1.2] für Passive Requestor Profile. Mit Aufruf dieser Operation loggen sich Nutzer beim Basisdienst TBAuth aus und die Sitzung sowie der ggf. zugehörige Session-Cookie im Browser werden gelöscht.

Da über I_IDP_Auth_Passive_Client ausgestellte Identitätsbestätigungen grundsätzlich auch über I_IDP_Auth_Active_Client::renew_Identity_Assertion erneuert werden können, ist diese Operation signOut auch für I_IDP_Auth_Passive_Client nötig.

Sitzungsinformationen könnten die Identitätsbestätigung oder eine Referenz auf diese enthalten, sind aber letzten Endes implementierungsabhängig. Je nach Implementierung des Basisdienstes, könnte dieser Sitzungsinformationen temporär speichern oder auch in einem Session-Cookie im Webbrowser des Nutzers ablegen.

Nach der Bestätigung durch den Benutzer kann die eigentliche Annullierung mittels der Operation signoutCleanup [WS-Federation1.2] ausgeführt werden. Um zu verhindern, dass sich Nutzer unabsichtlich abmelden – sei es aufgrund eines technischen Fehlers oder als Opfer eines boshaften Angriffs – wird die Operation signoutCleanup nicht separat (ohne Bestätigung) angeboten

Für ein Beispiel siehe Anhang C2.

4.3 Schnittstelle I_Local_IDP_Service

Der Basisdienst TBAuth bietet diese Schnittstelle, zur Ausstellung von Identitätsbestätigungen, für lokale IDPs in der Leistungserbringerumgebung an. Als Aufrufparameter wird eine durch den lokalen IDP erstellte und signierte Identitätsbestätigung übergeben. Der BD-TBAuth übernimmt die Inhalte dieser übergebenen Identitätsbestätigung unverändert und signiert diese mit der für tokenbasierte Authentisierung verwendeten Identität. Die neu signierte Identitätsbestätigung wird als Ergebnis der Operation zurück geliefert.

Als Herausgeber der Identitätsbestätigung wird ein vom Aufrufer vorgegebener Wert verwendet. Der BD-TBAuth stellt jedoch sicher, dass dieses von dem Wert „IDP TI-Plattform“ abweicht. Dadurch können Systeme, die die Identitätsbestätigung prüfen, erkennen, dass die Inhalte der Identitätsbestätigung nicht vom BD-TBAuth, sondern von einem lokalen IDP stammen.

4.3.1 SOAP-Envelope

Um Standard-konform zu sein wird die zu signierende Identitätsbestätigung nicht als Teil des RST sondern im Security-Header des SOAP-Envelopes übergeben.

4.3.2 Sicherheit

4.3.3 Operation sign_Token

4.3.3.1 Aufrufparameter sign_Token

Um standardkonform zu sein, wird die zu signierende Identitätsbestätigung nicht als Teil des RST, sondern im Security-Header des SOAP-Envelopes übergeben.

Beispiel:

Mit Auslassungspunkten (…) ausgewiesene Textstellen sind gekürzt.

<wst:RequestSecurityToken xmlns:wst=”http://docs.oasis-open.org/ws-sx/ws-trust/200512”>

    <wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>

    <gem:mandantId>…</gem:mandantId>

    <gem:clientSystemId>…</gem:clientSystemId>

    <gem:iccsn>123456789123456789</gem:iccsn>

</wst:RequestSecurityToken>

4.3.3.2 Rückgabewerte von sign_Token

5 Informationsmodell

Die relevanten Informationsmodelle sind in [gemSpec_TBAuth] spezifiziert.

6 Anhang A – Verzeichnisse

6.1 Abkürzungen

6.2 Glossar

Das Glossar erläutert Begriffe dieser Spezifikation, welche nicht in [gemKPT_Arch_TIP], [gemSpec_TBAuth] oder [gemGlossar] erläutert sind.

6.3 Abbildungsverzeichnis

6.4 Tabellenverzeichnis

6.5 Referenzierte Dokumente

6.5.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematik Infrastruktur. 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.

6.5.2 Weitere Dokumente

7 Anhang B – Verwendete Schnittstellenversionen

Tabelle 12: TAB_BD_TBAuth_16 Schnittstellenversionen

8 Anhang C

8.1 C1 – Beispiel I_IDP_Auth_Passive_Client::signIn

Dieser Ablauf ist beispielhaft und kann im Detail von der Spezifikation abweichen (z.B. Präfixe). Zudem stellt dieses Beispiel eine mögliche Umsetzungsvariante dar, die sich außerhalb des Spezifikationsbereichs befindet. Konkrete Implementierungen können z.B. mehrere Request-Response-Sequenzen verwenden, wohingegen hier lediglich der initiale Request und die finale Response dargestellt sind.

In der Antwort wird HTML verwendet, um den Webbrowser mittels HTTP POST auf einen anderen Endpunkt umzuleiten.

Mit Auslassungspunkten „…“ ausgewiesene Textstellen sind gekürzt.

1) Initialer Request

GET https://konnektor.konlan/idp?wa=wsignin1.0 &wreply=https%3A%2F%2Fwww.gesundheitsdatendienst.telematik/&wtrealm=urn:telematik:gesundheitsdatendienst:www:Instanz23&wct
x=32b4bca8-f80e-4a1d-950d-0b88e54cc508

Parameter:

wa: “wsignin1.0”

wtrealm: “urn:telematik:gesundheitsdatendienst:www:Instanz23”

wreply: “https://www.gesundheitsdatendienst.telematik/”

wctx: „32b4bca8-f80e-4a1d-950d-0b88e54cc508“

2) Response mit Identitätsbestätigung

HTTP/1.1 200 OK

Set-Cookie:

JSESSIONID=C06EC2B344F516B512E917390DCBF820
Domain=konnektor.konlan
Path=/idp
Secure
HttpOnly

Content:
<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3.org/TR/html4/loose.dtd”>

<html>

    <head>

        <title>IDP SignIn Response Form</title>

    </head>

    <body>

        <form id=”signinresponseform” name=”signinresponseform” action=”https://www.gesundheitsdatendienst.telematik/” method=”POST”>

            <input type=”hidden” name=”wa” value=”wsignin1.0” />

            <br />

            <input type=”hidden” name=”wresult” value=”&lt;RequestSecurityTokenResponseCollection xmlns=&quot;http://docs.oasis-open.org/ws-sx/ws-trust/200512&quot; xmlns:ns2=&quot;http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd&quot; xmlns:ns3=&quot;http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd&quot; xmlns:ns4=&quot;http://www.w3.org/2005/08/addressing&quot; xmlns:ns5=&quot;http://docs.oasis-open.org/ws-sx/ws-trust/200802&quot;&gt;&lt;RequestSecurityTokenResponse&gt;&lt;TokenType&gt;http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0&lt;/TokenType&gt;…/>

            <br />

            <input type=”hidden” name=”wctx” value=”32b4bca8-f80e-4a1d-950d-0b88e54cc508” />

            <br />

            <input type=”hidden” name=”wtrealm” value=”urn:telematik:gesundheitsdatendienst:www:Instanz23” />

            <br />

            <noscript>

                <p>Script is disabled. Click Submit to continue.</p>

                <input type=”submit” name=”_eventId_submit” value=”Submit” />

                <br />

            </noscript>

        </form>

        <script language=”javascript”>window.setTimeout(‘document.forms[0].submit()’,0);</script>

    </body>

</html>

8.2 C2 – Beispiel I_IDP_Auth_Passive_Client::signOut

1) Request signOut

GET https://konnektor.konlan/idp?wa=wsignout1.0

Cookies:

JSESSIONID=292C6AE65855DAFA6853DFB660374A2E FEDIZ_HOME_REALM=”urn:telematik:gesundheitsdatendienst:www:Instanz23”

Parameter:

wa:”wsignout1.0”

2) Response signOut

HTTP/1.1 200 OK

<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3.org/TR/html4/loose.dtd”>

<html>

    <head>

        <title>IDP SignOut Confirmation Response Page</title>

    </head>

    <body>

        <h1>Logout from the following Applications?</h1>

        <div>Fedizhelloworld<br/>

        </div>

        <br/>

        <br/>

        <form id=”signoutconfirmationresponseform” name=”signoutconfirmationresponseform” action=”/fediz-idp/federation?wa=wsignout1.0” method=”POST”>

            <input type=”hidden” name=”wa” value=”wsignout1.0” />

            <input type=”hidden” id=”execution” name=”execution” value=”e4s1” />

            <input type=”submit” name=”_eventId_submit” value=”Logout” />

        </form>

    </body>

</html>

3) Request signOut

POST https://konnektor.konlan/idp?wa=wsignout1.0

Cookie:

JSESSIONID=292C6AE65855DAFA6853DFB660374A2E FEDIZ_HOME_REALM=”urn:telematik:gesundheitsdatendienst:www:Instanz23”

Content:

wa=wsignout1.0

execution=e4s1

_eventId_submit=Logout

4) Response signOut

HTTP/1.1 200 OK

Set-Cookie:

JSESSIONID=DD2396E6AFC47E6A9A7874DDDD356147

FEDIZ_HOME_REALM=””

Content:

<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3.org/TR/html4/loose.dtd”>

<html>

    <head>

        <title>IDP SignOut Response Page</title>

    </head>

    <body>

        <h1>CXF Fediz IDP successful logout.</h1><p>Fedizhelloworld<img src=”https://www.gesundheitsdatendienst.telematik/fedservlet?wa=wsignoutcleanup1.0”/>

            <br/>

        </p>

    </body>

</html>

5) Request signoutCleanup

GET https://www.gesundheitsdatendienst.telematik/fedservlet?wa=wsignoutcleanup1.0

Cookie:

JSESSIONID= 1D0E8AD4CC4B8D7D8DD7A5996496945E

Parameter:

wa:wsignoutcleanup1.0

6) Response signoutCleanup

HTTP/1.1 200 OK

Set-Cookie:

JSESSIONID=DD2396E6AFC47E6A9A7874DDDD356147

FEDIZ_HOME_REALM=””

Content:

<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3.org/TR/html4/loose.dtd”>

<html>

    <head>

        <title>IDP SignOut Confirmed</title>

    </head>

    <body>

        <h1>IDP SignOut Confirmed</h1>

    </body>

</html>