In jedem großen Unternehmen, und X5 Retail Group ist da keine Ausnahme, steigt mit der Entwicklung die Anzahl der Projekte, die eine Benutzerautorisierung erfordern. Im Laufe der Zeit ist ein nahtloser Übergang der Benutzer von einer Anwendung zu einer anderen erforderlich, und dann besteht die Notwendigkeit, einen einzigen Single-Sing-On (SSO)-Server zu verwenden. 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 namens „Identification Brokers“ wird Abhilfe schaffen. Am funktionalsten sind seine Vertreter wie Keycloak, Gravitee Access Management usw. Meistens können Anwendungsfälle unterschiedlich sein: Maschineninteraktion, Benutzerbeteiligung usw. Die Lösung muss flexible und skalierbare Funktionalität unterstützen, die alle Anforderungen in einem vereinen kann. Für solche Lösungen verfügt unser Unternehmen jetzt über einen Indikationsbroker – Keycloak.
Keycloak ist ein Open-Source-Identitäts- und Zugriffskontrollprodukt, das von RedHat verwaltet wird. Es ist die Grundlage für die Produkte des Unternehmens, die SSO - RH-SSO verwenden.
Grundlegende Konzepte
Bevor Sie beginnen, sich mit Lösungen und Lösungsansätzen auseinanderzusetzen, sollten Sie sich hinsichtlich der Art und Reihenfolge der Prozesse entscheiden:
Identifikation ist ein Verfahren zur Erkennung eines Subjekts anhand seiner Kennung (mit anderen Worten, dies ist die Definition eines Namens, Logins oder einer Nummer).
Authentifizierung - Hierbei handelt es sich um ein Authentifizierungsverfahren (Benutzer wird mit Passwort überprüft, Brief wird mit elektronischer Signatur überprüft usw.)
Genehmigung - Dies ist die Bereitstellung des Zugriffs auf eine Ressource (z. B. auf E-Mail).
Identitätsbroker-Schlüsselcloak
Schlüsselumhang ist eine Open-Source-Lösung für das Identitäts- und Zugriffsmanagement, die für den Einsatz in IS entwickelt wurde, wo Microservice-Architekturmuster verwendet werden können.
Keycloak bietet Funktionen wie Single Sign-On (SSO), vermittelte Identität und soziale Anmeldung, Benutzerverbund, Client-Adapter, Admin-Konsole und Kontoverwaltungskonsole.
Von Keycloak unterstützte Grundfunktionen:
- Single-Sign-On und Single-Sign-Out für Browseranwendungen.
- Unterstützung für OpenID/OAuth 2.0/SAML.
- Identity Brokering – Authentifizierung mit externen OpenID Connect- oder SAML-Identitätsanbietern.
- Social Login – Google-, GitHub-, Facebook- und Twitter-Unterstützung zur Benutzeridentifizierung.
- Benutzerföderation – Synchronisierung von Benutzern von LDAP- und Active Directory-Servern und anderen Identitätsanbietern.
- Kerberos-Brücke – Verwendung eines Kerberos-Servers zur automatischen Benutzerauthentifizierung.
- Admin-Konsole – für eine einheitliche Verwaltung von Einstellungen und Lösungsoptionen über das Web.
- Account Management Console – zur Selbstverwaltung des Benutzerprofils.
- Anpassung der Lösung basierend auf der Corporate Identity des Unternehmens.
- 2FA-Authentifizierung – TOTP/HOTP-Unterstützung mit Google Authenticator oder FreeOTP.
- Login-Flows – Selbstregistrierung des Benutzers, Wiederherstellung und Zurücksetzung des Passworts und andere sind möglich.
- Sitzungsverwaltung – Administratoren können Benutzersitzungen von einem einzigen Punkt aus verwalten.
- Token-Mapper – Bindung von Benutzerattributen, Rollen und anderen erforderlichen Attributen an Token.
- Flexible Richtlinienverwaltung für alle Bereiche, Anwendungen und Benutzer.
- CORS-Unterstützung – Client-Adapter verfügen über integrierte CORS-Unterstützung.
- Service Provider Interfaces (SPI) – Eine große Anzahl von SPIs, mit denen Sie verschiedene Aspekte des Servers anpassen können: Authentifizierungsflüsse, Identitätsanbieter, Protokollzuordnung und 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 Library unterstützen.
- Erweiterbar durch Plugins.
Für CI/CD-Prozesse, sowie Automatisierung von Managementprozessen in Keycloak kann die REST API/JAVA API genutzt werden. Die Dokumentation ist elektronisch verfügbar:
REST API
JAVA-API
Enterprise Identity Provider (On-Premise)
Möglichkeit zur Authentifizierung von Benutzern über Benutzerföderationsdienste.
Es kann auch die Pass-Through-Authentifizierung genutzt werden – wenn sich Benutzer bei Arbeitsstationen mit Kerberos (LDAP oder AD) authentifizieren, können sie automatisch bei Keycloak authentifiziert werden, ohne dass sie ihren Benutzernamen und ihr Passwort erneut eingeben müssen.
Zur Authentifizierung und weiteren Autorisierung von Benutzern kann ein relationales DBMS verwendet werden, das am besten für Entwicklungsumgebungen geeignet ist, da es keine langwierigen 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 bisher am häufigsten getesteten sind Oracle 12C Release1 RAC und Galera 3.12 Cluster für MariaDB 10.1.19.
Identitätsanbieter – Social Login
Es besteht die Möglichkeit, einen Login aus sozialen Netzwerken zu nutzen. Um die Möglichkeit zur Authentifizierung von Benutzern zu aktivieren, verwenden Sie die Keycloack-Administratorkonsole. Änderungen am Anwendungscode sind nicht erforderlich und diese Funktionalität ist sofort verfügbar und kann in jeder Phase des Projekts aktiviert werden.
Es ist möglich, OpenID/SAML-Identitätsanbieter für die Benutzerauthentifizierung zu verwenden.
Typische Autorisierungsszenarien mit OAuth2 in Keycloak
Ablauf des Autorisierungscodes - Wird mit serverseitigen Anwendungen verwendet. Eine der gebräuchlichsten Arten von Autorisierungsberechtigungen, da sie sich gut für Serveranwendungen eignet, bei denen der Quellcode und die Clientdaten der Anwendung für Außenstehende nicht zugänglich sind. Der Prozess basiert in diesem Fall auf einer Umleitung. Die Anwendung muss in der Lage sein, mit einem Benutzeragenten (User-Agent), beispielsweise einem Webbrowser, zu kommunizieren, um API-Autorisierungscodes zu empfangen, die über den Benutzeragenten umgeleitet werden.
Impliziter Fluss - Wird von Mobil- oder Webanwendungen (Anwendungen, die auf dem Gerät des Benutzers ausgeführt werden) verwendet.
Der Berechtigungstyp „Implizite Autorisierung“ wird von Mobil- und Webanwendungen verwendet, bei denen die Vertraulichkeit des Clients nicht gewährleistet werden kann. Der implizite Berechtigungstyp nutzt auch die User-Agent-Umleitung, wobei das Zugriffstoken an den User-Agent zur weiteren Verwendung in der Anwendung übergeben wird. Dadurch wird das Token für den Benutzer und andere Anwendungen auf dem Gerät des Benutzers verfügbar. Diese Art der Autorisierungsberechtigung authentifiziert nicht die Identität der Anwendung und der Prozess selbst basiert auf einer Umleitungs-URL (die zuvor beim Dienst registriert wurde).
Implicit Flow unterstützt keine Zugriffstoken-Aktualisierungstoken.
Flow zur Gewährung von Client-Anmeldeinformationen – werden verwendet, wenn die Anwendung auf die API zugreift. Diese Art von Autorisierungsberechtigung wird normalerweise für Server-zu-Server-Interaktionen verwendet, die im Hintergrund ohne unmittelbare Benutzerinteraktion ausgeführt werden müssen. Der Fluss zur Gewährung von Client-Anmeldeinformationen ermöglicht es einem Webdienst (vertraulicher Client), seine eigenen Anmeldeinformationen zu verwenden, anstatt sich beim Aufruf eines anderen Webdienstes zur Authentifizierung als Benutzer auszugeben. Für ein höheres Maß an Sicherheit ist es für den aufrufenden Dienst möglich, ein Zertifikat (anstelle eines gemeinsamen Geheimnisses) als Anmeldeinformationen zu verwenden.
Die OAuth2-Spezifikation ist in beschrieben
JWT-Token und seine Vorteile
JWT (JSON Web Token) ist ein offener Standard (), die eine kompakte und eigenständige Möglichkeit zur sicheren Übertragung von Informationen zwischen Parteien als JSON-Objekt definiert.
Laut Standard besteht der Token aus drei Teilen im Base-64-Format, getrennt durch Punkte. Der erste Teil wird Header genannt und enthält den Typ des Tokens und den Namen des Hash-Algorithmus zum Erhalten einer digitalen Signatur. Der zweite Teil speichert die Basisinformationen (Benutzer, Attribute usw.). Der dritte Teil ist die digitale Signatur.
. .
Speichern Sie niemals einen Token in Ihrer Datenbank. Da ein gültiges Token einem Passwort entspricht, ist das Speichern des Tokens so, als würde man das Passwort im Klartext speichern.
Zugangstoken ist ein Token, das seinem Besitzer Zugriff auf sichere Serverressourcen gewährt. Es hat normalerweise eine kurze Lebensdauer und kann zusätzliche Informationen wie die IP-Adresse der Partei enthalten, die das Token anfordert.
Aktualisierungstoken ist ein Token, mit dem Clients nach Ablauf ihrer Lebensdauer neue Zugriffstoken anfordern können. Diese Token werden in der Regel für einen längeren Zeitraum ausgegeben.
Die Hauptvorteile der Verwendung in der Microservice-Architektur:
- Möglichkeit des Zugriffs auf verschiedene Anwendungen und Dienste durch einmalige Authentifizierung.
- Fehlen eine Reihe erforderlicher Attribute im Benutzerprofil, ist eine Anreicherung mit Daten möglich, die der Nutzlast hinzugefügt werden können, auch automatisiert und im laufenden Betrieb.
- Es ist nicht erforderlich, Informationen über aktive Sitzungen zu speichern, die Serveranwendung muss lediglich die Signatur überprüfen.
- Flexiblere Zugriffskontrolle durch zusätzliche Attribute in der Nutzlast.
- Die Verwendung einer Token-Signatur für Header und Payload erhöht die Sicherheit der Gesamtlösung.
JWT-Token – Zusammensetzung
Kopfzeile - Standardmäßig enthält der Header nur den Typ des Tokens und den für die Verschlüsselung verwendeten Algorithmus.
Der Typ des Tokens wird im Schlüssel „typ“ gespeichert. Der Schlüssel „type“ wird im JWT ignoriert. Wenn der Schlüssel „typ“ vorhanden ist, muss sein Wert JWT sein, um anzugeben, dass es sich bei diesem Objekt um ein JSON-Web-Token handelt.
Der zweite Schlüssel „alg“ definiert den Algorithmus, der zum Verschlüsseln des Tokens verwendet wird. Es sollte standardmäßig auf HS256 eingestellt sein. Der Header ist in base64 kodiert.
{ „alg“: „HS256“, „type“: „JWT“}
Nutzlast (Inhalt) - Die Nutzlast speichert alle Informationen, die überprüft werden müssen. Jeder Schlüssel in der Nutzlast wird als „Anspruch“ bezeichnet. Sie können sich beispielsweise nur auf Einladung bewerben (geschlossene Aktion). Wenn wir jemanden zur Teilnahme einladen möchten, senden wir ihm ein Einladungsschreiben. Es ist wichtig zu überprüfen, ob die E-Mail-Adresse zu der Person gehört, die die Einladung annimmt. Deshalb werden wir diese Adresse in die Nutzlast aufnehmen und sie dazu im Schlüssel „E-Mail“ speichern
{ "Email": "[E-Mail geschützt] "}
Schlüssel in der Nutzlast können beliebig sein. Es sind jedoch einige reserviert:
- iss (Aussteller) – Identifiziert die Anwendung, von der das Token gesendet wird.
- sub (Subject) – definiert den Betreff des Tokens.
- aud (Audience) ist ein Array von Zeichenfolgen oder URIs, bei denen die Groß-/Kleinschreibung beachtet wird und die eine Liste der Empfänger dieses Tokens darstellen. Wenn die empfangende Seite ein JWT mit dem angegebenen Schlüssel empfängt, muss sie prüfen, ob sie bei den Empfängern vorhanden ist – andernfalls wird das Token ignoriert.
- exp (Ablaufzeit) – Gibt an, wann das Token abläuft. Der JWT-Standard erfordert, dass alle seine Implementierungen abgelaufene Token ablehnen. Der exp-Schlüssel muss ein Zeitstempel im Unix-Format sein.
- nbf (Not Before) ist eine Zeit im Unix-Format, die den Zeitpunkt bestimmt, an dem das Token gültig wird.
- iat (Ausgestellt am) – Dieser Schlüssel stellt den Zeitpunkt dar, zu dem das Token ausgestellt wurde, und kann zur Bestimmung des Alters des JWT verwendet werden. Der iat-Schlüssel muss ein Zeitstempel im Unix-Format sein.
- Jti (JWT-ID) – eine Zeichenfolge, die die eindeutige Kennung dieses Tokens definiert, wobei die Groß-/Kleinschreibung beachtet wird.
Es ist wichtig zu verstehen, dass die Nutzdaten nicht in verschlüsselter Form übertragen werden (obwohl Token verschachtelt werden können und dann die Übertragung verschlüsselter Daten möglich ist). Daher können keine geheimen Informationen gespeichert werden. Wie der Header ist auch die Nutzlast Base64-kodiert.
Unterschrift - Wenn wir einen Titel und eine Nutzlast haben, können wir die Signatur berechnen.
Base64-kodiert: Header und Payload werden übernommen, diese werden durch einen Punkt zu einem String zusammengefasst. Anschließend werden diese Zeichenfolge und der geheime Schlüssel in den im Header („alg“-Schlüssel) angegebenen Verschlüsselungsalgorithmus eingegeben. Der Schlüssel kann eine beliebige Zeichenfolge sein. Längere Saiten werden am meisten bevorzugt, da das Aufnehmen länger dauert.
{"alg": "RSA1_5", "payload": "A128CBC-HS256"}
Aufbau einer Keycloak-Failover-Cluster-Architektur
Bei der Nutzung eines einzigen Clusters für alle Projekte ergeben sich erhöhte Anforderungen an eine SSO-Lösung. Bei einer geringen Anzahl an Projekten sind diese Anforderungen nicht bei allen Projekten so deutlich spürbar, mit steigender Anzahl an Benutzern und Integrationen steigen jedoch die Anforderungen an Verfügbarkeit und Leistung.
Die Erhöhung des Risikos eines einzelnen SSO-Ausfalls erhöht die Anforderungen an die Lösungsarchitektur und die verwendeten Methoden für redundante Komponenten und führt zu einem sehr engen SLA. In dieser Hinsicht verfügen Projekte während der Entwicklung oder in frühen Phasen der Implementierung von Lösungen häufiger über ihre eigene nicht fehlertolerante Infrastruktur. Mit fortschreitender Entwicklung ist es erforderlich, Möglichkeiten für Entwicklung und Skalierung festzulegen. Am flexibelsten ist es, einen Failover-Cluster mithilfe der Containervirtualisierung oder eines Hybridansatzes aufzubauen.
Um in den Clustermodi „Aktiv/Aktiv“ und „Aktiv/Passiv“ zu arbeiten, muss die Datenkonsistenz in einer relationalen Datenbank sichergestellt werden – beide Datenbankknoten müssen synchron zwischen verschiedenen geografisch verteilten Datenzentren repliziert werden.
Das einfachste Beispiel einer fehlertoleranten Installation.
Welche Vorteile bietet die Verwendung eines einzelnen Clusters:
- Hohe Verfügbarkeit und Leistung.
- Unterstützung für Betriebsarten: Aktiv/Aktiv, Aktiv/Passiv.
- Möglichkeit 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 Benutzerbeteiligung.
- Die Möglichkeit, das JWT-Token in verschiedenen Projekten wiederzuverwenden.
- Ein einziger Vertrauenspunkt.
- Schnellerer Start von Projekten mithilfe von Microservices/Containervirtualisierung (kein Heben und Konfigurieren zusätzlicher Komponenten erforderlich).
- Es besteht die Möglichkeit, kommerziellen Support beim Anbieter zu erwerben.
Worauf Sie bei der Planung eines Clusters achten sollten
DBMS
Keycloak verwendet ein Datenbankverwaltungssystem zum Speichern von Bereichen, Clients, Benutzern usw.
Eine breite Palette von DBMS wird unterstützt: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak verfügt über eine eigene integrierte relationale Datenbank. Die Verwendung wird für nicht geladene Umgebungen empfohlen, beispielsweise für Entwicklungsumgebungen.
Um im Aktiv/Aktiv- und Aktiv/Passiv-Clustermodus zu arbeiten, ist die Datenkonsistenz in einer relationalen Datenbank erforderlich, und beide Datenbankclusterknoten werden synchron zwischen Rechenzentren repliziert.
Verteilter Cache (Infinspan)
Damit der Cluster ordnungsgemäß funktioniert, ist eine zusätzliche Synchronisierung der folgenden Cache-Typen mithilfe des JBoss Data Grid erforderlich:
Authentifizierungssitzungen – werden zum Speichern von Daten bei der Authentifizierung eines bestimmten Benutzers verwendet. Anfragen aus diesem Cache beziehen sich normalerweise nur auf den Browser und den Keycloak-Server, nicht auf die Anwendung.
Aktionstoken werden für Szenarien verwendet, in denen der Benutzer eine Aktion asynchron (per E-Mail) bestätigen muss. Beispielsweise wird der Infinispan-Cache von actionTokens während eines Flusses zum Vergessen eines Passworts verwendet, um Metadaten zu zugehörigen Aktions-Tokens zu verfolgen, die bereits verwendet wurden, sodass sie nicht wiederverwendet werden können.
Zwischenspeicherung und Ungültigmachung persistenter Daten – wird zum Zwischenspeichern persistenter Daten verwendet, um unnötige Abfragen an die Datenbank zu vermeiden. Wenn ein Keycloak-Server die Daten aktualisiert, müssen alle anderen Keycloak-Server in allen Rechenzentren davon erfahren.
Arbeit – Wird nur zum Senden ungültiger Nachrichten zwischen Clusterknoten und Rechenzentren verwendet.
Benutzersitzungen – werden zum Speichern von Daten über Benutzersitzungen verwendet, die für die Dauer der Browsersitzung des Benutzers gültig sind. Der Cache muss HTTP-Anfragen vom Endbenutzer und der Anwendung verarbeiten.
Brute-Force-Schutz – wird verwendet, um Daten über fehlgeschlagene Anmeldungen zu verfolgen.
Lastverteilung
Der Load Balancer ist der einzige Einstiegspunkt für Keycloak und muss Sticky Sessions unterstützen.
Anwendungsserver
Sie dienen der Steuerung der Interaktion von Komponenten untereinander und können mithilfe bestehender Automatisierungstools und dynamischer Skalierung von Infrastrukturautomatisierungstools virtualisiert oder containerisiert werden. Die häufigsten Bereitstellungsszenarien in OpenShift, Kubernates, Rancher.
Damit ist der erste Teil – der theoretische – abgeschlossen. In der nächsten Artikelserie werden Beispiele für Integrationen mit verschiedenen Identitätsanbietern und Beispiele für Einstellungen analysiert.
Source: habr.com