An all grousser Firma, an X5 Retail Group ass keng Ausnahm, wéi se sech entwéckelt, erhéicht d'Zuel vu Projeten, déi d'Benotzerautorisatioun erfuerderen. Mat der Zäit ass en nahtlosen Iwwergang vu Benotzer vun enger Applikatioun an eng aner erfuerderlech, an dann ass et néideg en eenzegen Single-Sing-On (SSO) Server ze benotzen. Awer wéi ass et wann Identitéitsprovider wéi AD oder anerer déi keng zousätzlech Attributer hunn scho a verschiddene Projete benotzt ginn. Eng Klass vu Systemer genannt "Identifikatiounsbroker" wäert zur Rettung kommen. Am meeschte funktionell sinn hir Vertrieder, wéi Keycloak, Gravitee Access Gestioun, etc.. Meeschtens, benotzen Fäll kënnen ënnerschiddlech sinn: Maschinn Interaktioun, Benotzer Participatioun, etc.. D'Léisung muss flexibel an scalable Funktionalitéit ënnerstëtzen, datt all Ufuerderunge an engem kombinéieren kann, an esou Léisungen eis Firma huet elo eng Indikatioun broker - Keycloak.
Keycloak ass en Open Source Identitéits- an Zougangskontrollprodukt, dee vu RedHat gehale gëtt. Et ass d'Basis fir d'Produkter vun der Firma mat SSO - RH-SSO.
Grond Konzepter
Ier Dir ufänkt Léisungen an Approche ze verstoen, sollt Dir d'Begrëffer an d'Sequenz vu Prozesser definéieren:
Identifikatioun ass eng Prozedur fir e Sujet duerch säin Identifizéierer z'erkennen (an anere Wierder, dëst ass d'Bestëmmung vun engem Numm, Login oder Nummer).
Authentifikatioun - Dëst ass eng Authentifikatiounsprozedur (de Benotzer gëtt mat engem Passwuert iwwerpréift, de Bréif gëtt mat enger elektronescher Ënnerschrëft iwwerpréift, etc.)
Autorisatioun - gëtt Zougang zu enger Ressource (zum Beispill E-Mail).
Keycloak Identitéitsbroker
keycloak ass eng Open Source Identitéits- an Zougangsmanagement-Léisung entwéckelt fir am IS ze benotzen, wou Mikroservicearchitekturmuster kënne benotzt ginn.
Keycloak bitt Features wéi Single Sign-On (SSO), Brokered Identitéit a Social Login, User Federation, Client Adapter, Admin Console a Account Management Console.
Basis Funktionalitéit ënnerstëtzt am Keycloak:
- Single-Umeldung an Single-Umellen fir Browser Uwendungen.
- Ënnerstëtzung fir OpenID / OAuth 2.0 / SAML.
- Identitéit Brokering - Authentifikatioun mat externen OpenID Connect oder SAML Identitéit Ubidder.
- Sozial Login - Google, GitHub, Facebook, Twitter Ënnerstëtzung fir Benotzer Identifikatioun.
- Benotzer Federatioun - Synchroniséierung vun Benotzer aus LDAP an Active Directory Serveren an aner Identitéit Provider.
- Kerberos Bréck - mat engem Kerberos Server fir automatesch Benotzerauthentifikatioun.
- Admin Console - fir vereenegt Gestioun vun Astellungen a Léisungsparameter iwwer de Web.
- Account Management Console - fir onofhängeg Benotzerprofilmanagement.
- Personnalisatioun vun der Léisung baséiert op der Firmenidentitéit vun der Firma.
- 2FA Authentifikatioun - TOTP / HOTP Ënnerstëtzung mat Google Authenticator oder FreeOTP.
- Login Flows - Benotzer Selbstregistrierung, Passwuert Erhuelung a Reset, an anerer sinn méiglech.
- Sessiounsmanagement - Administrateure kënne Benotzersessiounen vun engem eenzege Punkt verwalten.
- Token Mappers - verbindlech Benotzerattributer, Rollen an aner erfuerderlech Attributer un Tokens.
- Flexibel Politik Gestioun duerch Räich, Applikatioun an Benotzer.
- CORS Ënnerstëtzung - Client Adapter hunn gebierteg CORS Ënnerstëtzung.
- Service Provider Schnëttplazen (SPI) - eng grouss Zuel vun SPIs datt Dir verschidden Aspekter vun der Server erlaabt ze konfiguréieren: Authentifikatioun Flux, Identitéit Provider, Protokoll Mapping a vill méi.
- Client Adapter fir JavaScript Uwendungen, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Fréijoer.
- Ënnerstëtzung fir mat verschiddenen Uwendungen ze schaffen déi d'OpenID Connect Relying Party Bibliothéik oder SAML 2.0 Service Provider Bibliothéik ënnerstëtzen.
- Ausbaubar mat Plugins.
Fir CI / CD Prozesser, souwéi Automatiséierung vu Gestiounsprozesser am Keycloak, kann de REST API / JAVA API benotzt ginn. Dokumentatioun ass elektronesch verfügbar:
Rescht API
JAVA API
Enterprise Identity Provider (On-Premise)
D'Kapazitéit fir d'Benotzer duerch User Federation Servicer ze authentifizéieren.
Pass-through Authentifikatioun kann och benotzt ginn - wann d'Benotzer sech op Aarbechtsstatiounen mat Kerberos (LDAP oder AD) authentifizéieren, da kënne se automatesch op Keycloak authentifizéiert ginn ouni hir Benotzernumm a Passwuert nach eng Kéier aginn ze mussen.
Fir Authentifikatioun a weider Autorisatioun vun de Benotzer ass et méiglech eng relational DBMS ze benotzen, déi am meeschten applicabel ass fir Entwécklungsëmfeld, well et keng laang Astellungen an Integratiounen an de fréie Stadien vu Projeten involvéiert. Par défaut benotzt Keycloak en agebaute DBMS fir Astellungen a Benotzerdaten ze späicheren.
D'Lëscht vun ënnerstëtzten DBMS ass extensiv an enthält: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle an anerer. Déi meescht getest bis elo sinn Oracle 12C Release1 RAC a Galera 3.12 Cluster fir MariaDB 10.1.19.
Identitéit Provider - sozial Login
Et ass méiglech e Login vu sozialen Netzwierker ze benotzen. Fir d'Fäegkeet z'erméiglechen d'Benotzer z'authentifizéieren, benotzt d'Keycloack Admin Konsole. Keng Ännerunge vum Applikatiounscode sinn erfuerderlech an dës Funktionalitéit ass aus der Këscht verfügbar a kann zu all Stadium vum Projet aktivéiert ginn.
Fir d'Benotzer z'authentifizéieren, ass et méiglech OpenID / SAML Identitéit Ubidder ze benotzen.
Typesch Autorisatiounsszenarie mat OAuth2 an Keycloak
Autorisatioun Code Flow - benotzt mat Server-Säit Uwendungen. Eng vun den heefegsten Aarte vun Autorisatiounserlaabnes well se gutt fir Serverapplikatiounen gëeegent ass, wou de Quellcode vun der Applikatioun a Clientdaten net fir Auslänner verfügbar sinn. De Prozess an dësem Fall baséiert op Viruleedung. D'Applikatioun muss fäeg sinn mat engem Benotzeragent (Benotzeragent) ze kommunizéieren, sou wéi e Webbrowser - fir API Autorisatiounscoden ze kréien, déi duerch de Benotzeragent ëmgeleet ginn.
implizit Flux - benotzt vu mobilen oder Webapplikatiounen (Applikatioune lafen um Apparat vum Benotzer).
Déi implizit Autorisatiouns Erlaabnestyp gëtt vu mobilen a Webapplikatiounen benotzt, wou Client Confidentialitéit net garantéiert ka ginn. Den impliziten Erlaabnestyp benotzt och User Agent Viruleedung, woubäi den Zougang Token un de Benotzer Agent weidergeleet gëtt fir weider an der Applikatioun ze benotzen. Dëst mécht den Token verfügbar fir de Benotzer an aner Uwendungen um Apparat vum Benotzer. Dës Zort vun Autorisatiounserlaabnes authentifizéieren d'Identitéit vun der Applikatioun net, an de Prozess selwer hänkt op enger Viruleedung URL (virdrun am Service registréiert).
Implizit Flow ënnerstëtzt net Zougang Token Refresh Tokens.
Client Umeldungsinformatioune Grant Flow - gi benotzt wann d'Applikatioun op d'API kënnt. Dës Zort vun Autorisatiounserlaabnes gëtt typesch fir Server-zu-Server Interaktiounen benotzt, déi am Hannergrond ouni direkt Benotzerinteraktioun musse gemaach ginn. De Client Umeldungsinformatiounsflow erlaabt e Webservice (vertraulech Client) seng eege Umeldungsinformatiounen ze benotzen anstatt e Benotzer z'identifizéieren fir ze authentifizéieren wann en en anere Webservice rufft. Fir e méi héije Sécherheetsniveau ass et méiglech fir den Uruffservice en Zertifika ze benotzen (amplaz vun engem gemeinsame Geheimnis) als Umeldungsinformatioun.
D'OAuth2 Spezifizéierung gëtt an
JWT Token a seng Virdeeler
JWT (JSON Web Token) ass en oppene Standard (), déi e kompakten a selbststännege Wee definéiert fir sécher Informatioun tëscht Parteien a Form vun engem JSON-Objet ze transferéieren.
Geméiss dem Standard besteet den Token aus dräi Deeler am Base-64 Format, getrennt vu Punkte. Den éischten Deel gëtt den Header genannt, deen d'Zort vum Token an den Numm vum Hash Algorithmus enthält fir eng digital Ënnerschrëft ze kréien. Den zweeten Deel späichert d'Basisinformatioun (Benotzer, Attributer, etc.). Den drëtten Deel ass déi digital Ënnerschrëft.
. .
Späichert ni en Token an Ärer DB. Well e gültege Token gläichwäerteg mat engem Passwuert ass, ass d'Späichere vum Token wéi d'Passwuert am Kloertext ze späicheren.
Zougang Token ass en Token deen sengem Besëtzer Zougang zu geschützte Serverressourcen ubitt. Et huet normalerweis eng kuerz Liewensdauer a kann zousätzlech Informatioun droen, sou wéi d'IP Adress vun der Partei déi den Token freet.
Token erfrëschen ass en Token deen Clienten erlaabt nei Zougang Tokens ze froen nodeems hir Liewensdauer ofgelaf ass. Dës Tokens ginn normalerweis fir eng laang Zäit ausgestallt.
D'Haaptvirdeeler fir eng Mikroservicearchitektur ze benotzen:
- D'Kapazitéit fir Zougang zu verschiddenen Uwendungen a Servicer duerch eng eemoleg Authentifikatioun.
- Beim Fehlen vun enger Zuel vun erfuerderlechen Attributer am Benotzerprofil ass et méiglech mat Daten ze beräicheren, déi an d'Notzlaascht bäigefüügt kënne ginn, och automatiséiert an on-the-fly.
- Et ass net néideg Informatiounen iwwer aktiv Sessiounen ze späicheren, d'Serverapplikatioun brauch nëmmen d'Ënnerschrëft z'iwwerpréiwen.
- Méi flexibel Zougangskontroll duerch zousätzlech Attributer an der Notzlaascht.
- D'Benotzung vun enger Token Ënnerschrëft fir den Header a Notzlaascht erhéicht d'Sécherheet vun der Léisung als Ganzt.
JWT Token - Zesummesetzung
Header - Par défaut enthält den Header nëmmen den Token-Typ an den Algorithmus fir d'Verschlësselung benotzt.
Den Token Typ gëtt am "Typ" Schlëssel gespäichert. Den "Typ" Schlëssel gëtt am JWT ignoréiert. Wann den "Typ" Schlëssel präsent ass, muss säi Wäert JWT sinn fir unzeginn datt dësen Objet e JSON Web Token ass.
Den zweete Schlëssel "alg" definéiert den Algorithmus fir den Token ze verschlësselen. Et soll Standard op HS256 gesat ginn. Den Header ass an base64 kodéiert.
{ "alg": "HS256", "type": "JWT"}
Notzlaascht (Inhalt) - d'Notzlaascht späichert all Informatioun déi kontrolléiert muss ginn. All Schlëssel an der Notzlaascht ass bekannt als "Fuerderung". Zum Beispill kënnt Dir d'Applikatioun nëmmen duerch Invitatioun aginn (zougemaach Promo). Wa mir een wëllen invitéieren fir matzemaachen, schécken mir hinnen en Invitatiounsbréif. Et ass wichteg ze kontrolléieren datt d'E-Mailadress der Persoun gehéiert déi d'Invitatioun akzeptéiert, sou datt mir dës Adress an der Notzlaascht enthalen, dofir späichere mir se am "E-Mail" Schlëssel
{ "E-Mail": "[Email geschützt]"}
Schlësselen an der Notzlaascht kënnen arbiträr sinn. Wéi och ëmmer, et sinn e puer reservéiert:
- iss (Emittent) - Identifizéiert d'Applikatioun aus där den Token geschéckt gëtt.
- sub (Betreff) - definéiert d'Thema vum Token.
- aud (Publikum) - eng Rei vu case-sensiblen Strings oder URIs déi eng Lëscht vun Empfänger vun dësem Token ass. Wann déi empfaangen Partei e JWT mat engem bestëmmte Schlëssel kritt, muss se sech selwer an den Empfänger kontrolléieren - soss ignoréiert den Token.
- exp (Verfallszäit) - Gëtt un wann den Token ofleeft. De JWT Standard erfuerdert datt all Implementatiounen ofgelaaf Tokens refuséieren. Den Exp-Schlëssel muss en Zäitstempel am Unix-Format sinn.
- nbf (Net virdru) ass eng Zäit am Unix-Format, deen de Moment bestëmmt wou den Token gëlteg gëtt.
- iat (Erausginn At) - Dëse Schlëssel representéiert d'Zäit wou den Token ausgestallt gouf a ka benotzt ginn fir den Alter vum JWT ze bestëmmen. Den iat Schlëssel muss en Zäitstempel am Unix Format sinn.
- Jti (JWT ID) - eng String déi den eenzegaartegen Identifizéierer vun dësem Token definéiert, case-sensibel.
Et ass wichteg ze verstoen datt d'Notzlaascht net a verschlësselte Form iwwerdroe gëtt (och wann Tokens nestéiert kënne ginn an et dann méiglech ass verschlësselte Donnéeën ze vermëttelen). Dofir kann et keng geheim Informatioun späicheren. Wéi den Header ass d'Notzlaascht base64 kodéiert.
Ënnerschriwwe ginn - wa mir en Titel an Notzlaascht hunn, kënne mir d'Ënnerschrëft berechnen.
Den Header an d'Notzlaascht kodéiert am base64 ginn geholl a kombinéiert an eng Linn getrennt vun engem Punkt. Dëse String an de geheime Schlëssel ginn dann an de Verschlësselungsalgorithmus uginn, deen am Header spezifizéiert ass (Schlëssel "alg"). De Schlëssel kann all String sinn. Méi laang Saiten sinn am léifsten well se méi Zäit brauchen fir ze wielen.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Eng Keycloak Failover Cluster Architektur bauen
Wann Dir en eenzege Cluster fir all Projete benotzt, ginn et erhéicht Ufuerderunge fir eng SSO Léisung. Wann d'Zuel vun de Projete kleng ass, sinn dës Ufuerderungen net sou opfälleg fir all Projeten, awer mat enger Erhéijung vun der Unzuel vun de Benotzer an Integratiounen, d'Ufuerderunge fir d'Disponibilitéit an d'Performance erhéijen.
D'Erhéijung vum Risiko vun engem eenzegen SSO Echec erhéicht d'Ufuerderunge fir d'Léisungsarchitektur an d'Methoden, déi fir redundante Komponenten benotzt ginn a féiert zu engem ganz enke SLA. An dëser Hisiicht, méi oft während der Entwécklung oder fréi Etappe vun Ëmsetzung Léisungen, Projeten hunn hir eege net-Feeler-tolerant Infrastruktur. Wéi d'Entwécklung weidergeet, ass et erfuerderlech Méiglechkeete fir Entwécklung a Skala ze leeën. Et ass am meeschte flexibel e Failover-Cluster ze bauen mat Containervirtualiséierung oder enger Hybrid Approche.
Fir an den Aktiven / Aktiven an den Aktiven / Passive Cluster Modi ze schaffen, ass et erfuerderlech d'Datekonsistenz an enger relationaler Datebank ze garantéieren - béid Datebankknoten musse synchron tëscht verschiddene geo-verdeelte Datenzenter replizéiert ginn.
Déi einfachst Beispill vun enger Feeler-tolerant Installatioun.
Wat sinn d'Virdeeler vun engem eenzege Cluster ze benotzen:
- Héich Disponibilitéit a Leeschtung.
- Ënnerstëtzung fir Operatiounsmodi: Aktiv / Aktiv, Aktiv / Passiv.
- Méiglechkeet fir dynamesch Skaléieren - wann Dir Containervirtualiséierung benotzt.
- Méiglechkeet vun zentraliséiert Gestioun an Iwwerwachung.
- Eng vereenegt Approche fir Benotzer a Projeten z'identifizéieren/authentifizéieren/autoriséieren.
- Méi transparent Interaktioun tëscht verschiddene Projeten ouni Benotzerbedeelegung.
- D'Kapazitéit fir de JWT Token a verschiddene Projeten ze benotzen.
- Eenzege Punkt vum Vertrauen.
- Méi séier Start vu Projete mat Mikroservicer / Containervirtualiséierung (net néideg fir zousätzlech Komponenten z'installéieren an ze konfiguréieren).
- Et ass méiglech kommerziell Ënnerstëtzung vum Verkeefer ze kafen.
Wat fir ze kucken wann Dir e Cluster plangt
DBMS
Keycloak benotzt en DBMS Management System fir ze späicheren: Räicher, Clienten, Benotzer, etc.
Eng breet Palette vun DBMS gëtt ënnerstëtzt: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak kënnt mat senger eegener agebauter relationaler Datebank. Et ass recommandéiert fir net gelueden Ëmfeld ze benotzen - wéi Entwécklungsëmfeld.
Fir an Aktiven / Aktiven an Aktiven / Passive Cluster Modi ze schaffen, ass et néideg fir Datenkonsistenz an der relationaler Datebank ze garantéieren a béid Node vum Datebankcluster ginn synchron tëscht Datenzenter replizéiert.
Verdeelt Cache (Infinspan)
Fir datt de Cluster korrekt funktionnéiert, ass zousätzlech Synchroniséierung vun de folgende Cache-Typen erfuerderlech mat JBoss Data Grid:
Authentifikatiounssessiounen - benotzt fir Daten ze späicheren wann Dir e spezifesche Benotzer authentifizéiert. Ufroe vun dësem Cache enthalen normalerweis nëmmen de Browser an de Keycloak Server, net d'Applikatioun.
Action Tokens gi fir Szenarie benotzt wou de Benotzer eng Handlung asynchron (via E-Mail) muss bestätegen. Zum Beispill, während engem vergiessen Passwuert Flux, der actionTokens Infinispan Cache gëtt benotzt Metadaten iwwer assoziéiert Aktioun Tokens ze verfollegen déi scho benotzt goufen, sou kann et net erëmbenotzt ginn.
Caching an Invalidatioun vu persistent Donnéeën - benotzt fir persistent Donnéeën ze cache fir onnéideg Ufroen un d'Datebank ze vermeiden. Wann all Keycloak Server Daten aktualiséiert, mussen all aner Keycloak Serveren an all Datenzenter doriwwer wëssen.
Aarbecht - Nëmme benotzt fir Invalidatiounsmeldungen tëscht Clusternoden an Datenzenteren ze schécken.
Benotzersessiounen - benotzt fir Daten iwwer Benotzersessiounen ze späicheren déi valabel sinn fir d'Dauer vun der Browsersession vum Benotzer. De Cache muss HTTP-Ufroe vum Endbenutzer an der Applikatioun veraarbecht.
Brute Force Schutz - benotzt fir Daten iwwer gescheitert Login ze verfolgen.
Last Equiliber
De Lastbalancer ass den eenzegen Entréepunkt fir Keycloak a muss plakeg Sessiounen ënnerstëtzen.
Applikatioun Serveren
Si gi benotzt fir d'Interaktioun vu Komponenten mateneen ze kontrolléieren a kënne virtualiséiert oder containeriséiert ginn mat existéierende Automatisatiounsinstrumenter an dynamescher Skaléierung vun Infrastrukturautomatiséierungstools. Déi meescht üblech Deployment Szenarien an OpenShift, Kubernates, Rancher.
Dëst fäerdeg den éischten Deel - den theoreteschen. An der folgender Serie vun Artikelen ginn Beispiller vun Integratiounen mat verschiddenen Identifikatiounsprovider a Beispiller vun Astellungen diskutéiert.
Source: will.com