Einführung
Nutzung von docker / docker-compose
Quelltext / Build-Artefakte
Backend Komponenten
Überblick
Reverse Proxy
Account Management Service
Identity Provider (keycloak)
Client Apps
Health Card Authenticator
Alle Bausteine der prototypischen Realisierung werden in Form von docker Containern realisiert. Dieser Ansatz ermöglicht ein einfaches Deployment in verschiedenen Betriebsumgebungen, angefangen von Entwicklerarbeitsplätzen, über klassische Server im Rechenzentrum bis hin zu modernen Cloudinfrastrukturen. Weiterführende Informationen zu docker finden sich unter https://www.docker.com/. Für die Orchestrierung der verschiedenen Container wird docker-compose genutzt.
Die Verwendung von verschiedenen docker Containern ermöglicht den Einsatz von Containerorchestrierungsplattformen wie Openshift von RedHat, die ein automatisiertes Deployment und Lifecycle-Management der Container und ihrer Daten ermöglichen.
Der Quelltext der entwickelten Komponenten sowie alle weiteren Artefakte, die für den Aufbau einer lauffähigen Umgebung benötigt werden (Beispielkonfiguration, build und deployment Skripte für docker etc.) sind nach Projektabschluss im git-Repository des Fraunhofer FOKUS zu finden.
Die nachfolgenden Abschnitte beschreiben die konkrete Realisierung der durch die technische Architektur vorgegebenen Lösungskomponenten. Die Abbildung der jeweiligen Komponenten bzw. deren funktionaler Bestandteile erfolgt dabei über separate Lösungsbausteine, die als individuelle docker-Container realisiert werden.
Für die Registrierung neuer Nutzer wurde ein eigener “Account Management Service” entwickelt. Der Dienst verwendet mit Swagger generierten Code zum Zweck der Integration der Identity Provider API.
Bei jeder neuen Verbindung wird ein Challenge erzeugt, das für die Registrierung eines neuen Nutzers verwendet wird.
Erreichbar unter https://<hostname>/ams/registrationchallenge. Die Verwendung der Challenge soll die Verwaltung
und Speicherung einer Nutzer-Session auf der Server ersetzen. Die Challenge wird vom Client transportiert und
muss nur noch vom Dienst validiert werden.
https://<hostname>/ams/account - Für das Anlegen eines neuen Account.https://<hostname>/ams/account/<account_id> - Wenn ein Account bereits existiert, muss er vom Identity Provider
erstmal gelöscht werden und dann neu erstellt.Der “Account Management Service” kann umfangreich konfiguriert werden. Die allgemeinen Gruppen von verfügbaren Parametern werden im Folgenden zusammengefasst. Eine genauere Beschreibung der einzelnen Parameter finden Sie im Git-Repository des Projekts.
Für die Realisierung der Identity Provider Funktionalität kommt eine speziell angepasste Version von keycloak (Version 4.5) zum Einsatz, welche durch das Projekt um einen zusätzlichen Authentifizierungsmechanismus erweitert wurde und eine leicht veränderte OIDC-Token-Ausgestaltung umsetzt. Der keycloak Quelltext steht unter der Apache Licence 2.0 bereit und kann problemlos auch im kommerziellen Einsatz kostenfrei genutzt werden.
Der Identity Provider stellt einen Port für die Kommunikation über das HTTP-Protokoll bereit:
Nutzung der Authentication SPI
Die Architektur des keycloak Servers ermöglicht eine einfache Erweiterbarkeit der bereitgestellten Funktionalität über
spezielle Service Provider Interfaces (SPI). Zur Umsetzung der Authentifizierungsfunktionalität wurde das von keycloak
bereitgestellte Authentication SPI genutzt, um ein Plugin (keycloak-authenticator) zu entwickeln,
welches insbesondere die initiale Nutzerregistrierung sowie die Authentisierung mittles Smartcard,
Attestation-Zertifikat oder Session-zertifikat serverseitig umsetzt.
Die entsprechende Funktionalität wird weitestgehend innerhalb der Klasse de.fraunhofer.fokus.ehealth.movi.keycloak.authenticator.MoviAuthenticator
realisiert.
Detaillierte Informationen zum Kompilieren der Software sowie zum Einbinden in den keycloak Identity Provider finden sich im Software Repository des Projektes: /movi/keycloak-authenticator.
Anpassung am keycloak Quelltext
In Version 4.5.0 des keycloak Servers werden bestimmte - für die Umsetzung der beschriebenen Szenarien jedoch benötigte - Funktionen nicht unterstützt. Insbesondere das von den OpenID Connect Spezifikationen als optional deklarierte amr-Attribut (Authentication Method Reference) wird derzeit nicht in die ausgestellten OIDC Token eingebettet. Um dieses Problem zu lösen, wurden Anpassungen am keycloak Quelltext vorgenommen. Folgende Module bzw. Klassen sind von den Änderungen betroffen:
org.keycloak.representations.IDTokenorg.keycloak.authentication.DefaultAuthenticationFlow, org.keycloak.protocol.oidc.TokenManager.java und org.keycloak.services.managers.AuthenticationManager.javaDer Quelltext zum Kompilieren der benötigten Softwarekomponenten findet sich im Software Repository des Projektes: /movi/keycloak-server.
Das Projekt bietet die Möglichkeit, den keycloak-Server während des Starts des docker container umfassend zu konfigurieren. Dazu wird eine zuvor erzeugte und im container-Image enthaltene Konfigurationsdatei geladen, die alle relevanten Informationen zur Erstellung des benötigten Realms und der entsprechenden Realm-Konfiguration (clients etc.) enthält. Darüber hinaus bietet das Projekt die Möglichkeit wesentliche Parameter des keycloak Identity Providers über die Umgebungsvariablen des Docker Conatainers zu steuern. Zu den genutzten Variablen gehören:
KEYCLOAK_PASSWORD - Definiert das zum username zugehörige Passwort –> password
Detaillierte Informationen zum Kompilieren der benötigten Softwarekomponenten sowie zum Erstellen von “personalisierten” Containerimages finden sich im Software Repository des Projektes: /movi/keycloak.
Hinweis: Leider können aufgrund eines Fehlers nicht alle Parameter der keycloak-Konfiguration automatisch gesetzt werden. Nach dem ersten Starten des Containers ist das Setzen des neu hinzugefügten Authentication Flows zu den einzelnen Clients zwingend erforderlich. Für diesen Fall wurde ein Tool namens keycloak config engine entwickelt.