SSO in einer Mikrodienarchitektur. Verwendung von Keycloak. Teil Nr. 1

In jedem großen Unternehmen, und die X5 Retail Group ist da keine Ausnahme, steigt mit der Entwicklung die Anzahl der Projekte, in denen eine Benutzerauthentifizierung erforderlich ist. Im Laufe der Zeit wird ein nahtloser Übergang der Benutzer von einer Anwendung zur anderen notwendig, und dann entsteht die Notwendigkeit, einen einheitlichen Single-Sign-On (SSO)-Server zu verwenden. Aber was ist zu tun, wenn Identitätsanbieter wie AD oder andere, die keine zusätzlichen Attribute besitzen, bereits in verschiedenen Projekten verwendet werden? Hier kommen die sogenannten "Identitätsbroker" ins Spiel. Zu den funktionalsten Vertretern gehören Keycloak, Gravitee Access Management und andere. Die Nutzungsszenarien können sehr unterschiedlich sein: maschinelles Zusammenspiel, Benutzerinteraktion und mehr. Die Lösung muss flexible und skalierbare Funktionen unterstützen, die alle Anforderungen in einer Lösung vereinen, und diese Lösung in unserem Unternehmen ist derzeit der Identitätsbroker – Keycloak.

Keycloak ist ein Open-Source-Produkt, das für Identitätsmanagement und Zugangskontrolle vorgesehen ist und von RedHat unterstützt wird. Es ist die Grundlage für die von dem Unternehmen verwendeten SSO-Produkte – RH-SSO.

Grundbegriffe

Bevor man sich mit Lösungen und Ansätzen beschäftigt, sollte man die Begriffe und die Reihenfolge der Prozesse klären:

Identifikation – ist das Verfahren zur Erkennung eines Subjekts anhand seiner Kennung (einfacher gesagt, es ist die Bestimmung des Namens, Logins oder der Nummer).

Authentifizierung – ist das Verfahren zur Überprüfung der Echtheit (der Benutzer wird mit einem Passwort überprüft, eine E-Mail wird mit einer elektronischen Signatur überprüft usw.).

Autorisierung – ist die Gewährung des Zugangs zu einer Ressource (zum Beispiel zu einer E-Mail).

Identitätsbroker Keycloak

Keycloak – ist eine Open-Source-Lösung für das Identitäts- und Zugangsmanagement, die für den Einsatz in Informationssystemen vorgesehen ist, in denen Muster der Microservice-Architektur verwendet werden können.

Keycloak bietet Funktionen wie Single Sign-On (SSO), Broker-Identifikation und sozialen Login, Benutzerföderation, Client-Adapter, eine Administrationskonsole und eine Konto-Management-Konsole.

Die grundlegenden Funktionen, die in Keycloak unterstützt werden:

• Single Sign-On und Single Sign-Out für Webanwendungen.
• Unterstützung für OpenID/OAuth 2.0/SAML.
• Identity Brokering – Authentifizierung über externe OpenID Connect oder SAML Identitätsanbieter.
• Social Login – Unterstützung für Google, GitHub, Facebook, Twitter zur Identifizierung von Nutzern.
• User Federation – Synchronisierung von Nutzern aus LDAP und Active Directory Servern sowie anderen Identitätsanbietern.
• Kerberos-Bridge – Nutzung eines Kerberos-Servers für die automatische Authentifizierung von Nutzern.
• Admin-Konsole – zur zentralen Verwaltung von Einstellungen und Parametern der Lösung über das Web.
• Account Management Konsole – zur Selbstverwaltung des Nutzerprofils.
• Anpassung der Lösung basierend auf dem Corporate Design des Unternehmens.
• 2FA Authentifizierung – Unterstützung für TOTP/HOTP mithilfe von Google Authenticator oder FreeOTP.
• Login-Flows – Selbstregistrierung der Nutzer, Passwort-Wiederherstellung und -Zurücksetzung und weiteres ist möglich.
• Session Management – Administratoren können die Nutzer-Sessions von einem zentralen Punkt aus verwalten.
• Token Mappers – Zuordnung von Nutzerattributen, Rollen und anderen erforderlichen Attributen in Token.
• Flexibles Management von Richtlinien über Realm, Anwendung und Nutzer.
• CORS-Unterstützung – die Client-Adapter haben eine integrierte Unterstützung für CORS.
• Service Provider Interfaces (SPI) – eine Vielzahl von SPI zur Anpassung verschiedener Aspekte des Serverbetriebs: Authentifizierungsströme, Identitätsanbieter, Protokoll-Mapping und vieles mehr.
• Client-Adapter für JavaScript-Anwendungen, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
• Unterstützung für die Arbeit mit verschiedenen Anwendungen, die die OpenID Connect Relying Party-Bibliothek oder die SAML 2.0 Service Provider-Bibliothek unterstützen.
• Möglichkeit zur Erweiterung durch Plugins.

Für CI/CD-Prozesse sowie zur Automatisierung der Verwaltungsprozesse in Keycloak kann das REST API/JAVA API verwendet werden. Die Dokumentation ist elektronisch verfügbar:

REST API https://www.keycloak.org/docs-api/8.0/rest-api/index.html
JAVA API https://www.keycloak.org/docs-api/8.0/javadocs/index.html

Unternehmensbasierte Identitätsanbieter (On-Premise)

Möglichkeit zur Authentifizierung von Nutzern über User Federation-Dienste.

Es kann auch eine durchgehende Authentifizierung verwendet werden – wenn Nutzer sich an Arbeitsstationen mit Kerberos (LDAP oder AD) authentifizieren, können sie sich automatisch bei Keycloak authentifizieren, ohne ihren Benutzernamen und ihr Passwort erneut angeben zu müssen.

Zur Authentifizierung und weiteren Autorisierung von Benutzern kann eine relationale Datenbankmanagementsystem (RDBMS) verwendet werden, was besonders in Entwicklungsumgebungen sinnvoll ist, da dies in den frühen Phasen von Projekten keine langen Konfigurationen und Integrationen erfordert. Standardmäßig wird in Keycloak eine integrierte Datenbank für die Speicherung von Einstellungen und Benutzerdaten verwendet.

Die Liste der unterstützten Datenbankmanagementsysteme ist umfangreich und umfasst: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle und andere. Die derzeit am besten getesteten sind Oracle 12C Release1 RAC und der Galera 3.12 Cluster für MariaDB 10.1.19.

Identitätsanbieter – sozialer Login

Die Verwendung von Logins über soziale Netzwerke ist möglich. Um die Möglichkeit zur Authentifizierung von Benutzern zu aktivieren, wird die Keycloak-Administrationskonsole verwendet. Änderungen im Anwendungscode sind nicht erforderlich, und diese Funktionalität ist "out of the box" verfügbar und kann in jeder Phase der Projektrealisierung aktiviert werden.

Zur Authentifizierung von Benutzern können OpenID/SAML-Identitätsanbieter verwendet werden.

Typische Autorisierungsszenarien mit OAuth2 in Keycloak

Authorization Code Flow — wird mit serverseitigen Anwendungen verwendet (server-side applications). Es ist einer der am weitesten verbreiteten Autorisierungsarten, da er gut für serverseitige Anwendungen geeignet ist, bei denen der Quellcode der Anwendung und die Daten des Clients für Dritte nicht zugänglich sind. Der Prozess basiert in diesem Fall auf der Umleitung (Redirection). Die Anwendung muss in der Lage sein, mit einem Benutzeragenten (user-agent) wie einem Webbrowser zu interagieren – die Authentifizierungs-Codes, die über den Benutzeragenten umgeleitet werden, zu empfangen.

Implicit Flow — wird von mobilen oder Webanwendungen (Anwendungen, die auf dem Gerät des Benutzers betrieben werden) verwendet.

Der implizite Berechtigungstyp für die Autorisierung wird von mobilen und Webanwendungen verwendet, bei denen die Vertraulichkeit des Clients nicht garantiert werden kann. Der implizite Berechtigungstyp verwendet auch die Umleitung des User Agents, wobei das Zugriffstoken an den User Agent übergeben wird, um es in der Anwendung weiter zu nutzen. Dadurch wird das Token für den Nutzer und andere Anwendungen auf dem Gerät des Nutzers verfügbar. Bei diesem Berechtigungstyp erfolgt keine Authentifizierung der Echtheit der Anwendung, und der Prozess verlässt sich auf die vorher registrierte Umleitungs-URL (im Service).

Der Implizite Fluss unterstützt keine Refresh-Tokens.

Client-Zugangsdaten Grant Flow — wird verwendet, wenn Anwendungen auf APIs zugreifen. Dieser Berechtigungstyp wird normalerweise für Server-zu-Server-Interaktionen genutzt, die im Hintergrund ohne sofortige Nutzerinteraktion stattfinden müssen. Der Client-Credentials-Flow ermöglicht es einem Webdienst (vertraulichem Client), seine eigenen Anmeldeinformationen anstelle der Nutzerdaten zur Authentifizierung bei der Aufrufung eines anderen Webdienstes zu verwenden. Für ein höheres Sicherheitsniveau kann der aufrufende Dienst ein Zertifikat (anstatt eines gemeinsamen Geheimnisses) als Anmeldeinformation verwenden.

Die OAuth2-Spezifikation ist in
RFC-6749
RFC-8252
RFC-6819

JWT-Token und seine Vorteile

JWT (JSON Web Token) ist ein offener Standard (https://tools.ietf.org/html/rfc7519), der einen kompakten und autonomen Weg definiert, um Informationen sicher als JSON-Objekt zwischen Parteien zu übertragen.

Laut Standard besteht das Token aus drei Teilen im Base-64-Format, die durch Punkte getrennt sind. Der erste Teil wird als Header bezeichnet, in dem der Typ des Tokens und der Name des Hash-Algorithmus zur Erzeugung der digitalen Signatur enthalten sind. Der zweite Teil speichert die wesentlichen Informationen (Nutzer, Attribute usw.). Der dritte Teil ist die digitale Signatur.

..
Speichern Sie das Token niemals in Ihrer Datenbank. Denn ein gültiges Token ist gleichbedeutend mit einem Passwort; ein Token zu speichern, ist dasselbe wie ein Passwort im Klartext zu speichern.
Zugriffstoken — es ist ein Token, das dem Inhaber Zugriff auf geschützte Ressourcen des Servers gewährt. In der Regel hat es eine kurze Lebensdauer und kann zusätzliche Informationen wie die IP-Adresse der anfordernden Partei enthalten.

Refresh-Token — ist ein Token, das es Client-Anwendungen ermöglicht, neue Access-Token anzufordern, nachdem deren Lebensdauer abgelaufen ist. Diese Token werden normalerweise für längere Zeit ausgegeben.

Hauptvorteile der Anwendung in einer Microservices-Architektur:

• Möglichkeit, auf verschiedene Anwendungen und Dienste über eine einmalige Authentifizierung zuzugreifen.
• Wenn bestimmte erforderliche Attribute im Benutzerprofil fehlen, können Daten ergänzt werden, die in die Payload hinzugefügt werden können, auch automatisiert und „on-the-fly“.
• Es besteht keine Notwendigkeit, Informationen über aktive Sitzungen zu speichern; die Serveranwendung muss nur die Signatur überprüfen.
• Flexibleres Zugriffsmanagement durch zusätzliche Attribute in der Payload.
• Die Verwendung einer Signatur für das Header- und Payload erhöht die Sicherheit der Lösung insgesamt.

JWT-Token — Struktur

Header — standardmäßig enthält der Header nur den Typ des Tokens und den Algorithmus, der zur Verschlüsselung verwendet wird.

Der Typ des Tokens wird im Schlüssel „typ“ gespeichert. Der Schlüssel „typ“ wird in JWT ignoriert. Wenn der Schlüssel „typ“ vorhanden ist, sollte sein Wert JWT sein, um anzugeben, dass dieses Objekt ein JSON Web Token ist.

Der zweite Schlüssel „alg“ definiert den Algorithmus, der zur Verschlüsselung des Tokens verwendet wird. Standardmäßig sollte er auf HS256 gesetzt sein. Der Header wird in Base64 codiert.

{ "alg": "HS256", "typ": "JWT"}
Payload (Inhalt) — in der Payload wird jede Information gespeichert, die überprüft werden muss. Jeder Schlüssel in der Payload wird als „Anspruch“ bezeichnet. Zum Beispiel kann man nur mit einer Einladung in die Anwendung eintreten (geschlossene Promotion). Wenn wir jemanden einladen möchten, senden wir ihm eine E-Mail mit der Einladung. Es ist wichtig zu prüfen, dass die E-Mail-Adresse der Person gehört, die die Einladung annimmt. Daher werden wir diese Adresse in die Payload aufnehmen und in den Schlüssel „e-mail“ speichern.

{ "email": "example@x5.ru" }

Die Schlüssel in der Payload können beliebig sein. Es gibt jedoch einige reservierte:

• iss (Issuer) — definiert die Anwendung, aus der das Token gesendet wird.
• sub (Betreff) — definiert das Thema des Tokens.
• aud (Zielgruppe) – ein Array aus groß-/kleinschreibungssensitiven Strings oder URIs, das die Liste der Empfänger dieses Tokens darstellt. Wenn die empfangende Partei ein JWT mit diesem Schlüssel erhält, muss sie prüfen, ob sie in den Empfängern enthalten ist – andernfalls wird das Token ignoriert.
• exp (Ablaufdatum) — gibt an, wann das Token abläuft. Der JWT-Standard schreibt vor, dass in allen seinen Implementierungen abgelaufene Tokens abgelehnt werden. Der exp-Schlüssel sollte einen Zeitstempel im Unix-Format besitzen.
• nbf (Nicht vor) — dies ist die Zeit im Unix-Format, die angibt, wann das Token gültig wird.
• iat (Ausgestellt am) — dieser Schlüssel stellt die Zeit dar, zu der das Token ausgestellt wurde, und kann verwendet werden, um das Alter des JWT zu bestimmen. Der iat-Schlüssel sollte einen Zeitstempel im Unix-Format besitzen.
• Jti (JWT-ID) — ein String, der eine eindeutige Kennung dieses Tokens unter Berücksichtigung der Groß-/Kleinschreibung definiert.

Es ist wichtig zu verstehen, dass die Payload nicht in verschlüsselter Form übertragen wird (obwohl Tokens verschachtelt sein können und dann möglicherweise verschlüsselte Daten übermittelt werden können). Daher sollten keine geheimen Informationen darin gespeichert werden. Wie der Header wird die Payload in base64 kodiert.
Signatur — wenn wir den Header und die Payload haben, können wir die Signatur berechnen.

Die in base64 codierten Teile: Header und Payload werden durch einen Punkt zu einer Zeichenkette verbunden. Dann wird diese Zeichenkette zusammen mit dem geheimen Schlüssel als Eingabe für den im Header angegebenen Verschlüsselungsalgorithmus verwendet (Schlüssel „alg“). Der Schlüssel kann beliebiger String sein. Längere Strings sind bevorzugt, da es mehr Zeit in Anspruch nimmt, sie zu knacken.

{"alg":"RSA1_5","payload":"A128CBC-HS256"}

Aufbau einer ausfallsicheren Keycloak-Cluster-Architektur

Die Verwendung eines gemeinsamen Clusters für alle Projekte stellt höhere Anforderungen an die SSO-Lösung. Bei einer geringen Anzahl von Projekten sind diese Anforderungen für alle Projekte nicht so spürbar, jedoch steigen die Anforderungen an Verfügbarkeit und Leistung mit der zunehmenden Zahl an Nutzern und Integrationen.

Die Erhöhung der Ausfallrisiken des einheitlichen SSO erhöht die Anforderungen an die Architektur der Lösung und die verwendeten Methoden zur Sicherung von Komponenten und führt zu sehr strengen SLAs. In diesem Zusammenhang haben Projekte in der Regel während der Entwicklung oder in frühen Phasen der Implementierung eigene nicht ausfallsichere Infrastrukturen. Mit der Weiterentwicklung müssen Möglichkeiten für Wachstum und Skalierung eingeplant werden. Der flexibelste Weg besteht darin, einen ausfallsicheren Cluster unter Verwendung von Container-Virtualisierung oder einem hybriden Ansatz zu erstellen.

Für den Betrieb im Active/Active- und Active/Passive-Modus eines Clusters ist die Gewährleistung der Datenkonsistenz in der relationalen Datenbank erforderlich – beide Knoten der Datenbank müssen synchron zwischen verschiedenen geografisch verteilten Rechenzentren repliziert werden.

Das einfachste Beispiel für eine ausfallsichere Installation.

Welche Vorteile bietet die Verwendung eines einheitlichen Clusters:

• Hohe Verfügbarkeit und Leistung.
• Unterstützung von Betriebsmodi: Active/Active, Active/Passive.
• Möglichkeit der dynamischen Skalierung – bei Verwendung von Container-Virtualisierung.
• Möglichkeit der zentralisierten Verwaltung und Überwachung.
• Einheitlicher Ansatz zur Identifikation/Authentifizierung/Autorisierung von Benutzern in Projekten.
• Transparenteres Interagieren zwischen verschiedenen Projekten ohne Benutzereinbindung.
• Möglichkeit der Wiederverwendung von JWT-Token in verschiedenen Projekten.
• Einheitlicher Vertrauenspunkt.
• Schnellere Projektstarts durch den Einsatz von Microservices/Container-Virtualisierung (keine Einrichtung zusätzlicher Komponenten erforderlich).
• Möglichkeit, kommerziellen Support vom Anbieter zu erhalten.

Worauf sollte bei der Planung eines Clusters geachtet werden

Datenbankmanagementsystem

Keycloak verwendet ein Datenbankmanagementsystem zum Speichern von: Realms, Clients, Benutzern usw.
Eine breite Palette von Datenbankmanagementsystemen wird unterstützt: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak wird mit einer eigenen eingebauten relationalen Datenbank geliefert. Die Nutzung wird für nicht belastete Umgebungen empfohlen – wie zum Beispiel Entwicklungsumgebungen.

Für den Betrieb im Active/Active- und Active/Passive-Modus eines Clusters ist die Gewährleistung der Datenkonsistenz in der relationalen Datenbank erforderlich, und beide Knoten des Datenbankclusters werden synchron zwischen den Rechenzentren repliziert.

Verteilte Cache (Infinispan)

Für das ordnungsgemäße Funktionieren des Clusters ist eine zusätzliche Synchronisierung der folgenden Cache-Typen unter Verwendung von JBoss Data Grid erforderlich:

Authentifizierungssitzungen – werden verwendet, um Daten während der Authentifizierung eines bestimmten Benutzers zu speichern. Anfragen aus diesem Cache enthalten in der Regel nur den Browser und den Keycloak-Server, nicht die Anwendung.

Aktionstoken – werden für Szenarien verwendet, in denen der Benutzer eine Aktion asynchron bestätigen muss (per E-Mail). Beispielsweise wird während des Vergessen-Passwort-Prozesses der Cache actionTokens Infinispan verwendet, um Metadaten über die zugehörigen Aktionsmarker zu verfolgen, die bereits verwendet wurden, sodass sie nicht erneut verwendet werden können.

Caching und Invalidierung von persistenten Daten – wird verwendet, um persistente Daten zu cachen und so unnötige Anfragen an die Datenbank zu vermeiden. Wenn ein Keycloak-Server Daten aktualisiert, müssen alle anderen Keycloak-Server in allen Rechenzentren darüber informiert werden.

Arbeit – wird nur verwendet, um Nachrichten über Ungültigkeit zwischen den Knoten des Clusters und den Rechenzentren zu senden.

Benutzersitzungen – werden verwendet, um Daten über Benutzersitzungen zu speichern, die während der Browsersitzung des Benutzers gültig sind. Der Cache muss HTTP-Anfragen von Endbenutzern und der Anwendung verarbeiten.

Brute-Force-Schutz – wird verwendet, um Daten über fehlgeschlagene Anmeldeversuche zu verfolgen.

Lastenausgleich

Der Lastenausgleich ist der einzige Einstiegspunkt in Keycloak und muss sticky sessions unterstützen.

Anwendungsserver

Wird verwendet, um die Interaktion der Komponenten untereinander zu steuern und kann mit vorhandenen Automatisierungswerkzeugen und dynamischen Skalierungsmitteln virtualisiert oder containerisiert werden. Die häufigsten Bereitstellungsszenarien sind in OpenShift, Kubernetes, Rancher.

Damit ist der erste Teil - der theoretische - abgeschlossen. In den nächsten Artikeln werden Beispiele für Integrationen mit verschiedenen Identitätsanbietern sowie Beispiele für Einstellungen behandelt.

Quelle: habr.com