Keycloak und OpenID Connect: Unsere Basis für ein modernes Authentifizierungssystem

Posted on | 1798 words | ~9 mins

In unseren letzten Blogposts haben wir über verschiedene Aspekte unserer Anwendungslandschaft und unseren damit verbundenen Zielen berichtet. In diesem Post wollen wir auf unsere Lösung zur Authentifizierung unserer AnwenderInnen als ein zentrales Element dieser Ziel-Anwendungslandschaft eingehen. Es handelt sich für uns hierbei um ein Anwendungsgebiet, in dem die vorhandenen Branchen-Standards unseren Anforderungen weitgehend gerecht werden. In diesem Gebiet entwickeln wir also nicht von Grund auf selbst, sondern wollen Best-In-Class-Lösungen von Drittanbietern einsetzen, die zur Erfüllung aller unserer Anforderungen flexibel erweitert werden können.

Anforderungen an moderne Authentifizierung

In unseren Augen erfordert eine moderne Anwendungslandschaft ein sicheres und flexibles Authentifizierungssystem, das die Anforderungen unserer Web- und Cloud-Strategien erfüllt. Im Detail sehen wir folgende Anforderungen an eine solche Lösung:

  • Sicherheit und wirksamer Schutz vor Angriffen: Durch unsere Fokussierung auf bequem über das Internet erreichbare Web-Anwendungen sind unsere Anwendungen exponiert erreichbar und müssen entsprechend geschützt sein. Allem voran muss die Authentifizierungslösung daher den Schutz aller Daten vor jeglichen unbefugten Zugriffen sicherstellen. Eine solche wirksame Schutzmaßnahme ist die Nutzung einer Multi-Faktor-Authentifizierung, die zusätzlich zum Kennwort einen zweiten Faktor wie z.B. eine biometrisch geschützte Authentifikations-App auf dem Smartphone nutzt. Diese Möglichkeit soll unseren AnwenderInnen für alle zur Verfügung gestellten Anwendungen überall zur Verfügung stehen.
  • Komfort: Authentifizierung ist aus Sicherheitsgründen unumstritten notwendig. Nüchtern betrachtet ist die Anmeldung an einem System aus Sicht der NutzerInnen allerdings eine Notwendigkeit, die es zu erledigen gilt, um danach zum eigentlichen Ziel, der Nutzung einer konkreten Anwendung, zu gelangen. In unserer täglichen Erfahrung stellen Authentifizierungs-Systeme für viele NutzerInnen große Hürden dar. Umso wichtiger ist es uns, den Authentifizierungsprozess so einfach und verständlich wie möglich zu gestalten, um über eine signifikante Reduktion der Komplexität eine höchstmögliche Akzeptanz dieser Maßnahmen zu erzielen. Wir wollen unseren NutzerInnen daher eine möglichst komfortable und stabil verfügbare Anmeldung bereitstellen. Die Anmeldung soll zudem nur einmalig in jedem Medium (z.B. Browser) stattfinden müssen und anschließend via Single-Sign-On (SSO) in der gesamten Anwendungslandschaft genutzt werden können.
  • Schnelle und sichere Anbindung: Unsere Anwendungslandschaft entwickelt sich rasant weiter und wird zunehmend heterogener. Zu klassischen Websites und Portalen, gesellen sich Microsites und modulare Micro-Frontends, die in verschiedenen Kontexten genutzt werden können. Neben dieser selbst erstellten Software befinden sich inzwischen auch Standardlösungen wie z.B. O365 in der zur Verfügung gestellten Anwendungslandschaft. Jede dieser Anwendungen muss an das Authentifizierungssystem angebunden werden. Unser Ziel ist es diese Anbindung so einfach wie möglich zu gestalten und die Aufwände in der Entwicklung gering zu halten, ohne dass hierdurch Abstriche in Funktionsumfang oder Sicherheit in Kauf genommen werden müssen.
  • Anpassbarkeit: Einige unserer Authentifizierungs-Anforderungen liegen im Geschäftsmodell der DVAG begründet, daher ist eine Abbildung dieser speziellen Anforderungen essentiell, aber im üblichen Standard unwahrscheinlich. Hierzu zählt z.B. die Nutzung von Konten durch hierfür berechtigte Vertretungen- und Assistenzen, in Form einer Impersonation, die Anwendungsübergreifend konfigurierbar sein soll. Die Authentifizierungslösung muss daher auch entsprechend solcher Anforderungen anpassbar sein.

Mit Blick auf aktuelle Sicherheitsstandards führt die Suche nach einer erstklassigen Authentifizierungs-Lösung am Markt im nächsten Schritt zu den offenen Authentifizierungs-Protokollen OpenID Connect und OAuth2.

OpenID Connect und OAuth2

In den letzten Jahren haben sich OpenID Connect (OIDC) und OAuth2 als offene Protokolle etabliert. Sie sind damit zu De-Facto-Industrie-Standards geworden und werden von namenhaften Internet-Größen wie Google, Facebook und Microsoft unterstützt. Dies hat den Vorteil, dass einerseits ihre Verbreitung stetig zunimmt und andererseits die Integration mit Standardsoftware häufig out of the box möglich ist.

OAuth 2.0 und das darauf aufbauende OpenID Connect lösen ein zentrales Problem jeder Anwendung: Sie ermöglichen die Integration eines sicheren, zentral bereitgestellten Anmeldevorgangs, ohne dass die Anwendung selbst Kennwörter kennen oder verwalten muss. Darüber hinaus stellen sie Anwendungen auf standardisiertem Weg eine digitale Identität des Nutzers zur Verfügung. Dies lässt sich sehr gut am gängigsten OAuth 2.0 Prozess, dem Authorization Code Flow veranschaulichen.

Der Authentifizierungs-Server (hier Auth0 Tenant genannt) ist Dreh- und Angelpunkt des Prozesses. Zu diesem wird der Nutzer für die Authentifizierung weitergeleitet und auch nur diesem System gibt der Nutzer sein Kennwort preis. Nach erfolgreicher Anmeldung stellt der Authentifizierungs-Server der Anwendung signierte Tokens zur Verfügung, mit denen der Anwendung im Namen des Nutzers Zugriff auf Ressourcen ermöglicht wird. Der Abruf dieser Tokens erfolgt durch Server-zu-Server-Kommunikation zwischen Anwendungs-Backend und Authentifizierungs-Server.

Quelle: https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow

OAuth 2.0 und OpenID Connect lassen sich dabei wie folgt differenzieren:

OAuth 2.0 wurde rein für die sichere Authentifizierung des Zugriffs auf eine Anwendung designt. Durch Nutzung des vom Authentifizierungs-Server ausgestellten Tokens kann eine Applikation auf Ressourcen einer anderen Applikation im Namen des Nutzers zugreifen. Beispielhaft könnte man sich hier vorstellen, dass eine Applikation auf die in einem zentralen File Storage hinterlegten Dateien eines Nutzers zugreifen darf.

OpenID Connect ergänzt OAuth 2.0 um die Möglichkeit, Informationen zur Identität eines Nutzers zentral zu verwalten und in den einzelnen Applikationen zu verwenden. Wenn ein Authentifizierungs-Server OpenID Connect unterstützt, bezeichnet man ihn daher auch als Identity Provider. OpenID Connect ist daher ideal für Single-Sign-On (SSO) Anforderungen geeignet, in denen eine Applikation nicht nur die reine Authentifizierung bewerkstelligen, sondern auch Informationen zur Identität der NutzerInnen verwenden möchte.

Die Authentifizierungs-Flows von OAuth 2.0 und OpenID Connect sind zueinander kompatibel. Der Client erhält im Anschluss an eine erfolgreiche Authentifizierung neben dem Access Token zusätzlich auch ein ID-Token, das Informationen über den Nutzer enthält.

Für die einfache Integration dieser Prozesse gibt es zahlreiche Bibliotheken in verschiedensten Programmiersprachen am Markt. Geprüfte Sicherheit der in diesem kritischen Bereich eingesetzten Bibliotheken gewährleisten die von der OpenID Foundation zertifizierten Lösungen, die unter https://openid.net/developers/certified/ eingesehen werden können.

Im Bereich erstklassiger Authentifizierungslösungen, die OpenID Connect und OAuth2 unterstützen, haben wir uns Keycloak und Microsoft als Identity-Provider genauer angesehen. Letztlich haben wir uns, aufgrund der Möglichkeiten zur individuellen Anpassung und zur Integration mit unseren Bestandssystemen, für den flächendeckenden Einsatz von Keycloak entschieden.

Keycloak als modernes Authentifizierungssystem

Keycloak ist eine OpenID zertifizierte, quelloffene, moderne Lösung für das Identity und Access Management (IAM) sowie den Single-Sign-On (SSO). Das Open-Source-Projekt steht unter der Schirmherrschaft von Red Hat, das wiederum zu IBM gehört. Die Code-Basis von Keycloak wird kontinuierlich weiterentwickelt und gepflegt, sodass sichergestellt ist, dass wir von Neuerungen im Authentifizierungsumfeld ebenso profitieren wie von der Behebung von Sicherheitslücken, die in diesem Umfeld besonders kritisch zu bewerten sind.

Wie bereits beschrieben, ist auch der Anmelde-Komfort für unsere NutzerInnen eines unserer entscheidenden Kriterien. In der Vergangenheit hatten unsere Systeme oft eigene Anmeldemasken mit jeweils unterschiedlicher Gestaltung. Mit Keycloak und der Nutzung von OpenID Connect haben wir nun die Möglichkeit geschaffen, dass alle Anwendungen auf dieselbe zentrale Anmeldung verweisen. Damit ist die Herstellung einer übergreifend und durchgängig einheitlichen User Experience auch an dieser Stelle möglich. Gleichzeitig hat uns die Einbindung der zentralen Keycloak-Instanz die Möglichkeit des Single-Sign-On eröffnet. Ohne Einbußen bei der Sicherheit in Kauf nehmen zu müssen, reicht eine einmalige Anmeldung der NutzerInnen über Keycloak z.B. innerhalb eines Browsers aus, um alle daran angebundenen Anwendungen nutzen zu können. Sollte auf Nutzerseite doch einmal etwas schief gehen und beispielsweise das Kennwort in Vergessenheit geraten, bietet Keycloak standardmäßig Hilfe zur Selbsthilfe. Account Recovery und Backup-Prozesse, die von den NutzerInnen eigenständig durchgeführt werden können, ermöglichen eine deutlich schnellere Problemlösung und gleichzeitig eine Entlastung unserer IT-Hotline.

Anwendungen, die OpenID Connect und OAuth2 nicht unterstützen, können mittels des SAML-Standards (Security Assertion Markup Language) an Keycloak angebunden werden. Hierfür haben wir ebenfalls vereinzelte Anwendungsfälle. Damit sind die großen Authentifizierungs-Protokolle vollständig abgedeckt.

Darüber hinaus bietet Keycloak auch hinsichtlich der Anpassung auf die Eigenheiten unseres Unternehmens und der entsprechenden Prozesse zahlreiche Optionen. So können nicht nur bereits vorhandene Funktionen beliebig zu komplexen Abläufen kombiniert werden: Keycloak stellt darüber hinaus Interfaces zur Verfügung, mittels derer eigene Erweiterungen (z.B. die eingangs erwähnte Vertretungsauswahl) entwickelt und in die Abläufe übernommen werden können. Ein individuell anpassbares Vorlagensystem für die grafische Keycloak-Oberfläche ermöglicht es uns, die Anmeldemasken auch optisch nahtlos in das Erscheinungsbild der DVAG-Anwendungen einzubetten. Hierfür kommt wie auch bei den eigenentwickelten Anwendungen unser Design-System zum Einsatz (auf unser Design-System werden wir auch bald im Rahmen eines Blogpost näher eingehen).

Keycloak im Einsatz

Keycloak löst unser bisheriges, ausschließlich auf proprietären Prozessen beruhendes Zentrale-Online-Berechtigungssystem (kurz ZOB) als Authentifizierungssystem ab. Mit Keycloak stellen wir allen Anwendungen einen sicheren und einheitlichen Anmeldeprozess zur Verfügung. ZOB sorgt im Hintergrund weiterhin dafür, alle Nutzerkonten in Keycloak bereitzustellen, verwaltet die Berechtigungen der Nutzer und stellt unseren Anwendungen geeignete Schnittstellen für die Autorisierung bereit.

Um eine nahtlose Transition zu den neuen Keycloak-basierten Prozessen zu gewährleisten, stellen Keycloak und ZOB passende Schnittstellen und Funktionen zur Verfügung, die es ermöglichen, von der bisherigen proprietären auf die neue Keycloak-basierte Authentifizierung zu migrieren. Neben unseren Eigenentwicklungen sind auch Lösungen von Dritt-Anbietern sowie das Microsoft Azure Active Directory mit Keycloak verbunden. Das ermöglicht es uns, unseren NutzerInnen ein nahtloses SSO-Erlebnis über all ihre Anwendungen hinweg anzubieten. Um in diesem weitreichenden SSO-Verbund optimale Sicherheit und eine Separation der Dienste zu gewährleisten, wird der Geltungsbereich der von Keycloak ausgestellten Tokens anwendungsspezifisch angepasst. Über die „Audience“ und „Resource Access” Claims im Token kann ein Service prüfen, ob ein Aufruf berechtigt ist oder nicht. Um eine bestmögliche Sicherheit zu gewährleisten, setzt unser in Keycloak realisierter Anmeldeprozess zwingend eine Multi-Faktor-Authentifizierung voraus. Primäres Verfahren hierfür ist die „DVAG Login App“. Um auch im Falle von Verlust der App-Registrierung oder Störung der App handlungsfähig zu sein, steht als Fallback ein SMS-basiertes Verfahren zur Verfügung.

Für den Ausbau des Keycloak-Einsatzes haben wir bereits eine Reihe von Ideen im Backlog.

So wollen wir den Komfort für unsere NutzerInnen weiter erhöhen, indem wir ihnen künftig einen passwortlosen Login mittels QR-Codes anbieten, die nur mit einer Authentifizierungs-App gescannt werden müssen.

Gleichzeitig treiben wir die Anbindung bestehender Anwendungen an Keycloak voran, um dem Ziel eines einheitlichen Login-Prozesses gerecht zu werden und zukünftig auch über die von OpenID spezifizierten Wege (ID-Token und User-Info) einige Basis-Informationen der Nutzer-Identitäten grundsätzlich bereitzustellen. Dadurch können angeschlossene Anwendungen bereits mit der Anmeldung und ohne Anbindung weiterer Schnittstellen wesentliche Stammdaten des angemeldeten Nutzers beziehen. Last but not least setzen wir derzeit unser aktuelles Corporate Design in den Keycloak-Nutzer-Dialogen um, um eine nahtlose User Experience zu gewährleisten. In diesem Zuge werden wir den NutzerInnen neue sowie überarbeitete Prozesse für die Erstanmeldung und die Kontenwiederherstellung zur Verfügung stellen. Die NutzerInnen werden dann z.B. bei ihrer ersten Anmeldung automatisch in einen eigens hierfür vorgesehenen, geführten Prozess geleitet, der die Einrichtung der Multi-Faktor-Authentifizierung und Vergabe des persönlichen Kennworts unmittelbar während der ersten Anmeldung ermöglicht.

Fazit

Mit Keycloak haben wir eine sichere, stabile und flexibel anpassbare Standard-Lösung für unsere Authentifizierung eingeführt. Die Lernkurve für den professionellen Umgang mit Keycloak, insbesondere im Bereich von Administration und Customizing, ist jedoch nicht zu unterschätzen. Um das System langfristig professionell betreuen und betreiben zu können, setzen wir daher auf den kontinuierlichen Aufbau entsprechender Expertise innerhalb des Unternehmens. Unsere Erfahrungen mit Keycloak sind insgesamt durchweg positiv, sodass wir davon überzeugt sind, auf das für uns richtige Produkt zu setzen, um einen zentralen und zukunftsfähigen Baustein für unsere Ziel-Anwendungslandschaft zu liefern.

Welche Authentifizierungssysteme habt ihr im Einsatz und welche Erfahrungen habt ihr bereits gemacht? Schreibt uns einfach in die Kommentare auf Linkedin - wir freuen uns auf den Erfahrungsaustausch!