Get best of the week

SSO zur Microservice-Architektur. Wir benutzen Keycloak. Teilenummer 1

In jedem großen Unternehmen ist die X5 Retail Group keine Ausnahme, da die Anzahl der Projekte, für die eine Benutzerauthentifizierung erforderlich ist, mit zunehmender Anzahl der Projekte zunimmt. Im Laufe der Zeit ist ein nahtloser Übergang von Benutzern von einer Anwendung zu einer anderen erforderlich, und dann muss ein Single-Sing-On (SSO) für einen einzelnen Server verwendet werden. Aber was ist, wenn Identitätsanbieter wie AD oder andere, die keine zusätzlichen Attribute haben, bereits in verschiedenen Projekten verwendet werden? Eine Klasse von Systemen, die als "Identitätsbroker" bezeichnet werden, wird zur Rettung kommen. Am funktionalsten sind seine Vertreter wie Keycloak, Gravitee Access Management usw. In den meisten Fällen können Nutzungsszenarien unterschiedlich sein: Maschineninteraktion, Benutzerbeteiligung usw. Die Lösung muss flexible und skalierbare Funktionen unterstützen.In der Lage, alle Anforderungen in einem zu kombinieren, und eine solche Lösung in unserem Unternehmen ist jetzt ein Indikatorbroker - Keycloak.



Keycloak ist ein Open Source-Produkt zur Authentifizierung und Zugriffskontrolle, das von RedHat unterstützt wird. Es ist die Basis für die Produkte des Unternehmens, die SSO - RH-SSO verwenden.

Grundlegendes Konzept


Bevor Sie sich mit Entscheidungen und Ansätzen befassen, sollten Sie die Begriffe und die Reihenfolge der Prozesse festlegen: Bei der



Identifizierung wird ein Subjekt anhand seiner Kennung erkannt (dh es wird ein Name, ein Login oder eine Nummer festgelegt).

Die Authentifizierung ist ein Authentifizierungsverfahren (ein Benutzer wird mit einem Kennwort überprüft, ein Brief wird durch elektronische Signatur überprüft usw.). Die

Autorisierung ist die Bereitstellung des Zugriffs auf eine Ressource (z. B. E-Mail).

Keycloak Identity Broker


Keycloak ist eine Open-Source-Lösung für das Identitäts- und Zugriffsmanagement, die für die Verwendung in ICs entwickelt wurde, in denen Mikroservice-Architekturmuster verwendet werden können.

Keycloak bietet Funktionen wie Single Sign-On (SSO), Brokeridentifikation und Social Login, Benutzerverbund, Clientadapter, Administratorkonsole und Kontoverwaltungskonsole.

Grundlegende Funktionen, die in Keycloak unterstützt werden:

  • Single-Sign-On und Single-Sign-Out für browserbasierte Anwendungen.
  • Unterstützung für OpenID / OAuth 2.0 / SAML.
  • Identity Brokering - Authentifizierung mit externen OpenID Connect- oder SAML-Identitätsanbietern.
  • Social Login - Unterstützung für Google, GitHub, Facebook, Twitter zur Benutzeridentifikation.
  • User Federation – LDAP Active Directory .
  • Kerberos bridge – Kerberos .
  • Admin Console — Web.
  • Account Management Console – .
  • .
  • 2FA Authentication – TOTP/HOTP Google Authenticator FreeOTP.
  • Login Flows – , .
  • Session Management – .
  • Token Mappers – , .
  • realm, application .
  • CORS Support – CORS.
  • Service Provider Interfaces (SPI) – SPI, : , , .
  • JavaScript applications, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
  • , OpenID Connect Relying Party library SAML 2.0 Service Provider Library.
  • plugins.

Für CI / CD-Prozesse sowie für die Automatisierung von Verwaltungsprozessen in Keycloak kann die REST-API / JAVA-API verwendet werden. Die Dokumentation ist in elektronischer Form 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

Enterprise Identity Provider (vor Ort)


Die Möglichkeit, Benutzer über Benutzerverbunddienste zu authentifizieren.



Die Pass-Through-Authentifizierung kann ebenfalls verwendet werden. Wenn sich Benutzer an Arbeitsstationen mit Kerberos (LDAP oder AD) authentifizieren, können sie automatisch in Keycloak authentifiziert werden, ohne ihren Benutzernamen und ihr Kennwort erneut angeben zu müssen.

Für die Authentifizierung und weitere Autorisierung von Benutzern kann ein relationales DBMS verwendet werden, das am besten für Entwicklungsumgebungen geeignet ist, da es keine langfristigen Einstellungen und Integrationen in den frühen Phasen von Projekten erfordert. Standardmäßig verwendet Keycloak ein integriertes DBMS zum Speichern von Einstellungen und Benutzerdaten.

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

Identitätsanbieter - Social Login


Es ist möglich, ein Login aus sozialen Netzwerken zu verwenden. Um die Authentifizierung von Benutzern zu aktivieren, wird die Keycloack-Administratorkonsole verwendet. Änderungen am Anwendungscode sind nicht erforderlich. Diese Funktionalität ist sofort verfügbar und kann in jeder Phase des Projekts aktiviert werden.



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

Typische Autorisierungsszenarien mit OAuth2 in Keycloak


Authorization Code Flow - wird bei serverseitigen Anwendungen verwendet. Eine der häufigsten Arten von Berechtigungsberechtigungen, da sie sich gut für Serveranwendungen eignet, bei denen der Anwendungsquellcode und die Clientdaten für Außenstehende nicht zugänglich sind. Der Prozess basiert in diesem Fall auf der Umleitung. Die Anwendung sollte in der Lage sein, mit dem Benutzeragenten (Benutzeragenten), z. B. einem Webbrowser, zu interagieren, um API-Autorisierungscodes zu erhalten, die über den Benutzeragenten umgeleitet werden.

Impliziter Fluss - wird von Mobil- oder Webanwendungen verwendet (Anwendungen, die auf dem Gerät des Benutzers ausgeführt werden).

Eine implizite Art von Autorisierungsberechtigung wird von Mobil- und Webanwendungen verwendet, bei denen die Privatsphäre des Kunden nicht garantiert werden kann. Der implizite Berechtigungstyp verwendet auch die Benutzeragentenumleitung, und das Zugriffstoken wird zur weiteren Verwendung in der Anwendung an den Benutzeragenten übergeben. Dadurch wird das Token dem Benutzer und anderen Anwendungen auf dem Gerät des Benutzers zur Verfügung gestellt. Mit dieser Art von Autorisierungsberechtigung wird die Anwendung nicht authentifiziert, und der Prozess selbst basiert auf einer Umleitungs-URL (zuvor im Dienst registriert).

Implicit Flow unterstützt keine Aktualisierungstoken.
Grant Flow für Client-Anmeldeinformationen - Wird verwendet, wenn die Anwendung auf die API zugreift. Diese Art der Autorisierungsberechtigung wird normalerweise für Server-zu-Server-Interaktionen verwendet, die ohne sofortige Benutzerinteraktion im Hintergrund ausgeführt werden müssen. Der Client-Anmeldeinformationsfluss ermöglicht es dem Webdienst (dem vertraulichen Client), seine eigenen Anmeldeinformationen zu verwenden, anstatt sich beim Aufrufen eines anderen Webdienstes als Benutzer für die Authentifizierung auszugeben. Für eine höhere Sicherheitsstufe kann der aufrufende Dienst ein Zertifikat (anstelle eines gemeinsamen Geheimnisses) als Anmeldeinformationen verwenden.

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

JWT-Token und seine Vorteile


JWT (JSON Web Token) ist ein offener Standard ( https://tools.ietf.org/html/rfc7519 ), der eine kompakte und eigenständige Methode zum sicheren Übertragen von Informationen zwischen Parteien als JSON-Objekt definiert.

Gemäß dem Standard besteht das Token aus drei Teilen im Basis-64-Format, die durch Punkte getrennt sind. Der erste Teil heißt Header und enthält den Tokentyp und den Namen des Hash-Algorithmus zum Abrufen einer digitalen Signatur. Der zweite Teil speichert die grundlegenden Informationen (Benutzer, Attribute usw.). Der dritte Teil ist eine digitale Signatur.

<codierter Header>. <codierte Nutzlast>. <Signatur>
Speichern Sie niemals ein Token in Ihrer Datenbank. Da ein gültiges Token einem Kennwort entspricht, entspricht das Speichern eines Tokens dem Speichern eines Kennworts im Klartext.
Ein Zugriffstoken ist ein Token, das seinem Besitzer Zugriff auf die geschützten Ressourcen des Servers gewährt. Normalerweise hat es eine kurze Lebensdauer und kann zusätzliche Informationen enthalten, z. B. die IP-Adresse der Partei, die dieses Token anfordert.

Ein Aktualisierungstoken ist ein Token, mit dem Clients nach Ablauf ihrer Lebensdauer neue Zugriffstoken anfordern können. Diese Token werden normalerweise für einen langen Zeitraum ausgegeben.

Hauptvorteile der Anwendung in der Microservice-Architektur:

  • Die Möglichkeit, über eine einmalige Authentifizierung auf verschiedene Anwendungen und Dienste zuzugreifen.
  • Wenn im Benutzerprofil eine Reihe erforderlicher Attribute fehlen, können Daten angereichert werden, die der Nutzlast hinzugefügt werden können, einschließlich automatisierter und spontaner Daten.
  • Es ist nicht erforderlich, Informationen zu aktiven Sitzungen zu speichern. Die Serveranwendung sollte nur die Signatur überprüfen.
  • Flexiblere Zugriffskontrolle mit zusätzlichen Attributen in der Nutzlast.
  • Die Verwendung einer Tokensignatur für den Header und die Nutzdaten erhöht die Sicherheit der gesamten Lösung.

JWT Token - Zusammensetzung


Header - Standardmäßig enthält der Header nur den Token-Typ und den für die Verschlüsselung verwendeten Algorithmus.

Der Token-Typ wird in der Taste "typ" gespeichert. Die Taste "typ" wird im JWT ignoriert. Wenn der Typschlüssel vorhanden ist, muss sein Wert JWT sein, um anzuzeigen, dass dieses Objekt ein JSON-Web-Token ist.

Der zweite Alg-Schlüssel definiert den Algorithmus, der zum Verschlüsseln des Tokens verwendet wird. Standardmäßig sollte HS256 eingestellt sein. Der Header ist in base64 codiert.

{"alg": "HS256", "typ": "JWT"}
Nutzlast (Inhalt) - Die Nutzlast speichert alle Informationen, die überprüft werden müssen. Jeder Schlüssel in der Nutzlast wird als "Anweisung" bezeichnet. Beispielsweise kann die Bewerbung nur auf Einladung (geschlossene Promo) eingegeben werden. Wenn wir jemanden zur Teilnahme einladen möchten, senden wir ihm einen Einladungsbrief. Es ist wichtig zu überprüfen, ob die E-Mail-Adresse der Person gehört, die die Einladung annimmt. Daher nehmen wir diese Adresse in die Nutzdaten auf. Dazu speichern wir sie im E-Mail-Schlüssel

{"email": "example@x5.ru"}
Die Schlüssel in der Nutzlast können beliebig sein. Es gibt jedoch einige reservierte:

  • iss (Aussteller) - definiert die Anwendung, von der das Token gesendet wird.
  • sub (Betreff) - Definiert das Thema des Tokens.
  • aud (Audience) – URI, . JWT , — .
  • exp (Expiration Time) — , . JWT , . Exp unix .
  • nbf (Not Before) — unix , , .
  • iat (Issued At) — , JWT. iat unix .
  • Jti (JWT ID) — , c .

Es ist wichtig zu verstehen, dass die Nutzdaten nicht in verschlüsselter Form übertragen werden (obwohl Token eingebettet werden können und dann verschlüsselte Daten übertragen werden können). Daher ist es unmöglich, geheime Informationen darin zu speichern. Wie der Header ist die Nutzlast in base64 codiert.
Signatur - Wenn wir einen Header und eine Nutzlast haben, können wir die Signatur berechnen.

Base64-codiert: Header und Payload werden übernommen und zu einer Linie durch einen Punkt zusammengefasst. Diese Zeile und der geheime Schlüssel werden dann an die Eingabe des im Header angegebenen Verschlüsselungsalgorithmus gesendet (Schlüssel "alg"). Der Schlüssel kann eine beliebige Zeichenfolge sein. Längere Saiten sind vorzuziehen, da die Übereinstimmung länger dauert.

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

Keycloak-Failovercluster-Architektur


Wenn für alle Projekte ein einziger Cluster verwendet wird, sind die Anforderungen an eine Lösung für SSO erhöht. Wenn die Anzahl der Projekte gering ist, sind diese Anforderungen nicht für alle Projekte so spürbar, aber mit zunehmender Anzahl von Benutzern und Integrationen steigen die Anforderungen an Verfügbarkeit und Produktivität.

Das Erhöhen des Ausfallrisikos eines einzelnen SSO erhöht die Anforderungen an die Lösungsarchitektur und die für die Komponentenredundanz verwendeten Methoden und führt zu einer sehr engen SLA. In dieser Hinsicht verfügen Projekte häufiger bei der Entwicklung oder in der frühen Phase der Implementierung von Lösungen über eine eigene nicht fehlertolerante Infrastruktur. Während Sie sich entwickeln, müssen Sie die Möglichkeit der Entwicklung und Skalierung festlegen. Am flexibelsten ist es, einen Failovercluster mithilfe der Containervirtualisierung oder eines Hybridansatzes zu erstellen.

Um in Aktiv / Aktiv- und Aktiv / Passiv-Clustern arbeiten zu können, muss die Datenkonsistenz in einer relationalen Datenbank sichergestellt werden. Beide Datenbankknoten müssen synchron zwischen verschiedenen geoverteilten Rechenzentren repliziert werden.

Das einfachste Beispiel für eine ausfallsichere Installation.



Welche Vorteile bietet die Verwendung eines einzelnen Clusters:

  • Hohe Verfügbarkeit und Leistung.
  • Unterstützung für Betriebsarten: Aktiv / Aktiv, Aktiv / Passiv.
  • Die Fähigkeit zur dynamischen Skalierung - bei Verwendung der Containervirtualisierung.
  • Möglichkeit der zentralen Verwaltung und Überwachung.
  • Einheitlicher Ansatz zur Identifizierung / Authentifizierung / Autorisierung von Benutzern in Projekten.
  • Transparentere Interaktion zwischen verschiedenen Projekten ohne Beteiligung der Benutzer.
  • Die Möglichkeit, das JWT-Token in verschiedenen Projekten wiederzuverwenden.
  • Ein einziger Vertrauenspunkt.
  • Schnellerer Start von Projekten mithilfe von Microservices / Containervirtualisierung (keine zusätzlichen Komponenten müssen ausgelöst und konfiguriert werden).
  • Möglicherweise der Erwerb von kommerzieller Unterstützung durch den Anbieter.

Dinge, die bei der Planung eines Clusters zu beachten sind


DBMS


Keycloak verwendet ein DBMS-Verwaltungssystem zum Speichern: Bereiche, Clients, Benutzer usw. Es wird
eine Vielzahl von DBMS unterstützt: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak verfügt über eine eigene integrierte relationale Datenbank. Die Verwendung für nicht geladene Umgebungen wie Entwicklungsumgebungen wird empfohlen.

Um in Aktiv / Aktiv- und Aktiv / Passiv-Clustern zu arbeiten, muss die Konsistenz der Daten in einer relationalen Datenbank sichergestellt werden, und beide Knoten des Datenbankclusters werden synchron zwischen den Rechenzentren repliziert.

Verteilter Cache (Infinspan)


Damit der Cluster ordnungsgemäß funktioniert, ist eine zusätzliche Synchronisierung der folgenden Cache-Typen mithilfe von JBoss Data Grid erforderlich:

Authentifizierungssitzungen - werden zum Speichern von Daten während der Authentifizierung eines bestimmten Benutzers verwendet. Anforderungen aus diesem Cache umfassen normalerweise nur den Browser und den Keycloak-Server, nicht die Anwendung.

Aktionstoken - werden für Szenarien verwendet, in denen der Benutzer die Aktion asynchron (per E-Mail) bestätigen muss. Während des Passwort-Streams zum Vergessen wird beispielsweise der Infinispan-Cache von actionTokens verwendet, um Metadaten zu verwandten Aktionsmarkierungen zu verfolgen, die bereits verwendet wurden, sodass sie nicht wiederverwendet werden können.

Zwischenspeichern und Ungültigmachen persistenter Daten - wird zum Zwischenspeichern persistenter Daten verwendet, um unnötige Datenbankabfragen zu vermeiden. Wenn ein Keycloak-Server Daten aktualisiert, sollten dies allen anderen Keycloak-Servern in allen Rechenzentren bekannt sein.

Arbeit - wird nur zum Senden von Ungültigkeitsnachrichten zwischen Clusterknoten und Rechenzentren verwendet.

Benutzersitzungen - Dient zum Speichern von Daten zu Benutzersitzungen, die für die Browsersitzung eines Benutzers gültig sind. Der Cache muss HTTP-Anforderungen des Endbenutzers und der Anwendung verarbeiten.

Brute-Force-Schutz - wird verwendet, um fehlgeschlagene Anmeldedaten zu verfolgen.

Lastverteilung


Der Load Balancer ist ein einzelner Einstiegspunkt in Keycloak und sollte Sticky Sessions unterstützen.

Anwendungsserver


Sie werden verwendet, um die Interaktion von Komponenten untereinander zu steuern. Sie können mithilfe vorhandener Automatisierungstools und dynamischer Skalierung von Infrastrukturautomatisierungstools virtualisiert oder containerisiert werden. Die häufigsten Bereitstellungsszenarien in OpenShift, Kubernetes, Rancher.

Damit ist der erste Teil - theoretisch - beendet. In der folgenden Artikelserie werden Beispiele für Integrationen mit verschiedenen Identifikationsanbietern und Konfigurationsbeispiele diskutiert.

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles