Authentisierung über von DEMIS herausgegebene Zertifikate und mTLS

Dieses Verfahren steht nur Gesundheitsämtern sowie Krankenhäusern und Laboren zur Verfügung.

Weitere Informationen erhalten Sie unter Beantragung eines DEMIS-Zertifikats zur Authentisierung.

Ablauf:

Tokenausstellung

[01] Der DEMIS Client initiiert den Aufbau einer beidseitig authentisierten TLS-Verbindung. Die Übertragung der Informationen zwischen dem DEMIS Client und den Diensten der DEMIS-Infrastruktur erfolgt somit grundsätzlich transportverschlüsselt und integritätsgeschützt. Ein Aufruf von Operationen am DEMIS Token Provider ist somit nur für nutzende Personen mit einem validen Zertifikat möglich.

[02] Der DEMIS Client sendet einen POST Request an den Token Endpoint des DEMIS Token Provider. Der Request beinhaltet für die Ausstellung des Token relevante Informationen.

[03] Der DEMIS Token Provider validiert die übergebenen Parameter gegen die interne Konfiguration. Inkorrekte Kombinationen werden durch eine Fehlermeldung quittiert.

[04] Der DEMIS Token Provider prüft nun den Status des identifizierten Accounts. Für den Fall, dass der Account deaktiviert ist oder andere Anmeldevoraussetzungen nicht erfüllt werden, wird die Anfrage mit einer entsprechenden Fehlermeldung quittiert. Sind die Voraussetzungen für eine Anmeldung erfüllt, lädt der Token Provider alle relevanten Nutzerinformationen aus der Datenbank. Dazu gehören u.a. Identitätsattribute, wie z.B. sprechende Organisationsbezeichnungen aber auch die Zuordnung zu bestimmten Anwendungsrollen.

[05] Der DEMIS Token Provider bettet nun einen vorkonfigurierten Satz von Identitätsattributen (vgl. [04]) in eine JSON-Datenstruktur ein, versieht diese mit einer Gültigkeitsdauer und signiert sie.

[06] Die ausgestellten Token werden nun eingebettet in eine JSON-Datenstruktur an den aufrufenden DEMIS Client zurückgegeben. Das enthaltene Access Token kann für den Zeitraum seiner Gültigkeit für die Autorisierung von Zugriffen auf Dienste der zentralen DEMIS-Infrastruktur genutzt werden.

Meldungsversand

[07] Grundlage des Meldungsversands ist der Aufbau einer MTLS-Verbindung zum entsprechenden Endpunkt (vgl. [01]).

[08] Über einen http-POST Request (Operation: $process-notification) sendet der DEMIS Client eine Meldung an die DEMIS Notification API. Im http-Authorization-Header des Requests befindet sich ein vom DEMIS Token Provider ausgestelltes Access Token (vgl. [06]). Die Meldung entspricht inhaltlich und strukturell den Vorgaben des RKI (siehe FHIR-Profile).

[09] Nach einer eingehenden Prüfung des eingebetteten Sicherheitstokens erfolgt die Meldungsvorverarbeitung durch die DEMIS Notification API. Diese beinhaltet u.a. die Validierung, Anreicherung und Verschlüsselung der Meldung für den zuständigen Empfänger. Fehler während der Verarbeitung werden dem aufrufenden Client mitgeteilt.

[10] Eine im Rahmen der Meldungsverarbeitung erzeugte Versandbestätigung/Meldungsquittung wird an den aufrufenden DEMIS Client zurückgegeben.

Tokenausstellung

Der folgende Abschnitt liefert Hintergrundinformationen bezüglich der korrekten Ansteuerung des DEMIS Token Providers. Diese Hinweise sollen Hersteller bei der korrekten Implementierung entsprechender Funktionalität sowie der Analyse von Problemen unterstützen.

Mutual TLS

Voraussetzung für die Anmeldung am DEMIS Token Provider und die anschließende Ausstellung eines Sicherheitstokens ist der Aufbau einer beidseitig authentisierten TLS-Verbindung mit dem entsprechenden Endpunkt. Informationen aus dem für den Verbindungsaufbau verwendeten Zertifikat sowie das Ergebnis der Zertifikatsprüfung bilden die Grundlage der Nutzeridentifizierung und -authentifizierung. Ein entsprechendes Zertifikat für die DEMIS-Produktivumgebung kann über den DEMIS-Support via demis-support@rki.de durch die meldenden Labore und Krankenhäuser beantragt werden. Zertifikate für den Zugang/Zugriff auf die DEMIS-Testumgebung müssen durch Hersteller gesondert angefordert werden.

Zulässige Ciphersuites

Folgende Ciphersuites können für den Aufbau der TLS-Verbindung genutzt werden:

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384

Implementierungshinweise

Für fast alle Programmiersprachen existieren Bibliotheken, die den Aufbau einer beidseitig authentisierten TLS-Verbindung unterstützen. Im Zusammenhang mit deren Nutzung sind jedoch grundlegende Sicherheitsaspekte zu betrachten. Von besonderer Bedeutung sind in diesem Zusammenhang die folgenden Aspekte:

• Sichere Schlüsselspeicherung - Das mit dem Clientzertifikat assoziierte private Schlüsselmaterial muss bestmöglich vor unberechtigten Zugriffen geschützt werden. In diesem Zusammenhang sollte mit entsprechenden Mitteln des Betriebssystems der Zugriff auf die das Schlüsselmaterial enthaltene Datei eng eingegrenzt werden. Zusätzlich sollte das Schlüsselmaterial niemals unverschlüsselt im Dateisystem abgelegt werden. Entsprechende Standards für eine verschlüsselte Speicherung in speziellen Container existieren und werden von den einschlägigen Bibliotheken umfassend unterstützt. Das für die Ableitung des Containerschlüssels gewählte Passwort sollte entsprechend sicher gewählt werden. Entsprechende Empfehlung hierzu finden sich in einschlägigen Dokumenten des BSI.

• Truststore Management - Es sollte darauf verzichtet werden, den Default-Truststore zu verwenden, der üblicherweise mit TLS-Implementierungen ausgeliefert wird. Die zum Einsatz kommenden Serverzertifikate für die DEMIS-Test- und Produktivumgebung stammen aus der "D-TRUST SSL Class 3 CA 1 EV 2009" CA. Ausschließlich diese CA sollte im entsprechenden Truststore als vertrauenswürdig hinterlegt werden.

• Prüfen des Serverzertifikats - todo (Hostname-Verification, Certificate Chain Validation …)

Beispiele

Folgende Beispiele sollen für verschiedene Tools, die häufig im Rahmen der Entwicklung genutzt werden, zeigen, wie die zertifikatsbasierte Authentisierung konfiguriert werden kann:

curl

curl -verbose --cert-type P12 --cert "cert.p12":PASSWORT-X POST 'https://test.demis.rki.de/live-test/...' ...

Hinweis: Im angeführten Beispiel wird das Schlüsselmaterial - anders als in den Implementierungshinweisen empfohlen - unverschlüsselt gespeichert. Dies sollte nur mit dem Schlüsselmaterial der Testumgebung in dieser Form erfolgen.

postman

Einstellungen unter “File/Settings/Certificates”

Endpunktadressen

Der Abruf von Token kann über die folgenden Endpunktadressen angestoßen werden: siehe Endpunkte, Zertifikate, User und Passwort

Request-Struktur

Es muss ein http-POST-Request mit spezifischen Parametern an die jeweilige Endpunktadresse gesendet werden. Diese Parameter sind x-www-form-urlencoded zu übertragen:

client_id=[placeholder]
client_secret=[placeholder]
username=[placeholder]
grant_type=password

Client_id / client_secret:

Siehe Endpunkte, Zertifikate, User und Passwort

Username:

Bitte entnehmen Sie Ihre individuelle DEMIS-Kennung aus der Informationsmail des Robert Koch-Instituts zur DEMIS-Registrierung und Zertifikatsbereitstellung (z.B. DEMIS-12345). Der username in der Konfiguration entspricht dem CN des Zertifikats ohne das vorgestellte "DEMIS-", also z.B. bei individueller DEMIS-Kennung bzw. CN=DEMIS-12345 lautet der username "12345".

Beispiele

curl

curl --verbose --cert-type P12 --cert "cert.p12":PASSWORT -X POST 'https://auth.test.demis.rki.de/live-test/realms/LAB/protocol/openid-connect/token' -H 'Content-Type: application/x-www-form-urlencoded' -d 'grant_type=password' -d 'client_id=demis-adapter' -d 'username=test-test' -d 'client_secret=secret_client_secret'


Mögliche Fehlermeldungen

Hinweis: Weitere Fehlermeldungen sind möglich. Die enthaltenen Beschreibungstexte sind dann jedoch zumeist aussagekräftig genug, um das Problem zu analysieren und zu lösen.