Identitätsmanagement für Patienten

Die Online-Identität eines Patienten ist eindeutig zu ermitteln. Nur so sind Authentifizierung und Autorisierung zentral und feingranular zu steuern. Das moderne Identitätsmanagement auf Basis verschiedener ICW Module leistet genau dies und bürgt damit vorbildlich für den Schutz und die Sicherheit von Patientendaten.

DIE ICW EHEALTH SUITE BIETET EIN MODERNES IDENTITÄTSMANAGEMENT

Der Umgang mit Identitäten und Benutzer-/Anmeldedaten bezüglich Sicherheit und Datenschutz ist bereits in kontrollierten Umgebungen wie Kliniknetzen mit den eigenen Mitarbeitern eine Herausforderung. Bei Patienten, die aus dem Internet auf ihre Daten zugreifen wollen, ist dies noch schwieriger. Die Crux der Aufgabe besteht nicht nur darin, die IT-Infrastruktur sicher zu gestalten, sondern auch sicherzustellen, dass der jeweilige Nutzer des Rechners mit dem Patienten der Patientenakte übereinstimmt. Und noch ein weiterer wichtiger Sicherheitsaspekt ist zu beachten: Die Web- oder mobile Anwendung muss auch die Berechtigung haben, auf diese Patientendaten zuzugreifen.

Kann dies erreicht werden und gleichzeitig das Benutzererlebnis positiv bleiben? Das Internet macht es vor: Mit den Konzepten der sogenannten „Social Logins“ lassen sich viele der oben genannten Anforderungen realisieren.

 

Was ist ein Social Login?

Ein Social Login ist nichts anderes als eine Single-Sign-On (SSO)-Lösung, wie sie im Enterprise-Umfeld zum Alltag gehört. In Unternehmen kommen dabei meist Kerberos oder SAML2-basierte SSO-Lösungen zum Einsatz. Diese sind im Enterprise-Kontext ideal, lassen aber Konzepte und die Leichtgewichtigkeit der neuen, modernen Welt des Internets vermissen. Aus diesem Grund hat sich hier ein neuer Standard etabliert, der sowohl sicher als auch leichtgewichtig ist und gerade im mobilen Umfeld große Akzeptanz genießt.

 

OpenID Connect – SSO im Web

OpenID Connect – nicht mit OpenId 1.0/1.1 oder 2.0 zu verwechseln – basiert auf dem OAuth2-Framework und erweitert dieses um Konzepte der Authentifizierung von Benutzern. Ein vereinfachter Anmeldevorgang läuft wie folgt ab:

Vereinfachter Anmeldevorgang nach OpenID Connect
  1. Der Benutzer ruft eine Web-/mobile Anwendung auf.
  2. Die Anwendung (der Client oder auch „Relying Party“ (RP) genannt) leitet den Benutzer auf die Autorisierungs- URL des OpenId-Providers (OP) weiter.
  3. Der OpenId-Provider authentifiziert den Benutzer und autorisiert die Anfrage.
  4. Der OpenId-Provider beantwortet die Autorisierungsanfrage bei Erfolg mit einem Id-Token und meist einem Access-Token. Der Id-Token ist ein JSON Web-Token, welcher kryptographisch gesichert Informationen über den Benutzer, etwa eine eindeutige Id, den Namen, die Anschrift oder auch die E-Mail-Adresse enthalten kann.
  5. Der RP kann entweder die Informationen aus dem Id-Token auswerten oder mit dem Access-Token den UserInfo-Endpunkt des OP abfragen, um Informationen (Claims) über den  authentifizierten Benutzer zu erhalten. Die Abfrage des UserInfo-Endpunkts ist empfohlen, da sie leicht zu implementieren ist und keine Kenntnisse bezüglich Kryptographie erforderlich sind. Allerdings ist ein zusätzlicher Netzwerkaufruf notwendig.

Der Access-Token kann wie jeder andere OAuth2-Token als Bearer-Token genutzt werden, um Informationen bei Resource-Servern anzufragen.

Wie kann eine solche Lösung nun aber die oben genannten Herausforderungen meistern?

 

Zentrale und feingranulare Berechtigungssteuerung

Wie der Authentifizierungsvorgang oben zeigt, findet eine Authentifizierung und Autorisierung immer über den OpenId-Provider statt (3.). Der OpenId-Provider ist damit die zentrale Stelle, die sicherstellt, wer, wann, welche Berechtigungen erhält.

Der Anbieter des Identitätsmanagements kann feingranular festlegen, welche Anwendungen auf welche Ressourcen zugreifen dürfen. Beispielsweise könnte einer Mutterpass-App der Zugriff auf psychiatrische Befunde verweigert werden.

Jeder Benutzer kann außerdem gezielt bei jeder Anwendung entscheiden, auf welche Daten zugegriffen werden darf. Eine Webanwendung beispielsweise, die innerhalb einer Klinik einen WLAN-Zugang anbietet, benötigt nicht notwendigerweise Zugriff auf die E-Mail-Adresse oder den Vor- und Nachnamen des Benutzers, muss aber den Benutzer eindeutig identifizieren können.

 

Zusätzlicher Schutz für medizinische Daten

Durch die zentrale Authentifizierung und Autorisierung (3.) können in einem offenen Ökosystem mit immer neuen Apps und Services dennoch die gewünschten Sicherheitsanforderungen erfüllt werden. Ein klassisches Beispiel hierfür ist der Zugriff auf medizinische Daten, welcher nur nach einer validen Multi-Faktor-Authentifizierung erfolgen darf. Bei allen Autorisierungsanfragen
wird am OpenId-Provider geprüft, ob die angeforderten Rechte einen Zugriff auf medizinische Daten beinhalten. Ist dies der Fall, wird zusätzlich ein zweiter Faktor angefordert, sollte dieser noch nicht vorliegen. Nur nach der erfolgreichen Authentifizierung mit dem zweiten Faktor erhält die Anwendung Zugriff auf die medizinischen Daten.

 

Integration mit anderen Identitätsanbietern

Die sicherlich größte Hürde bei jeder Web- oder mobilen Anwendung ist die Notwendigkeit der Registrierung. Häufig besitzt ein Benutzer schon mehrere Konten für verschiedene Services und möchte sich nicht noch bei einem weiteren Service registrieren müssen. Mithilfe von OpenID Connect kann ein Konto aber nicht nur innerhalb einer Organisation verwendet werden, sondern auch dazu benutzt werden, bestehende Anmeldedaten anderer Identitätsanbieter wiederzuverwenden. Dieser Ansatz bietet gleich mehrere Vorteile:

  • Es ist keine neue Registrierung notwendig.
  • Der Benutzer muss sich nur die Anmeldedaten eines (bestehenden) Kontos merken.
  • Der Identitätsanbieter agiert in diesem Fall als Anwendung (Client) und authentifiziert den Benutzer eindeutig gegenüber einem anderen Identitätsanbieter. Geteilt werden dabei nur die zur Anmeldung notwendigen Daten (keine Credentials). Der Zugriff auf medizinische Daten bleibt dem anderen Identitätsanbieter verwehrt.
  • Für den Fall, dass der Identitätsanbieter eine vertrauenswürdige Quelle, etwa eine Bank oder Versicherung ist, kann diese auch herangezogen werden, um die demographischen Daten des Benutzers zu beziehen, bzw. zu bestätigen.

 

Resümee

Ein zentrales Identitätsmanagement ist mehr als eine einfache SSO-Lösung. Es ist die einzige Möglichkeit, sicher für Datenschutz und Datensicherheit zu bürgen und dabei gleichzeitig Patienten nicht zu überfordern oder abzuschrecken. Die ICW setzt mit ihren Modulen Patient Onboarding und App Connect direkt auf OpenID Connect auf und ermöglicht damit modernste  Anwendungsszenarien, die bereits beim Kunden erfolgreich produktiv eingesetzt werden.

 

Links:

Kerberos V5 https://msdn.microsoft.com/de-de/library/cc780469(v=ws.10).aspx
OASIS SAML V2.0 Standardhttps://wiki.oasis-open.org/security
OpenID 
Connect 1.0http://openid.net/connect/
OAuth 2.0 Authorization Frameworkhttps://tools.ietf.org/html/rfc6749
OAuth 2.0: Bearer Token Usage https://tools.ietf.org/html/rfc6750
JSON Web Token (JWT)https://tools.ietf.org/html/rfc7519