NĂ« çdo kompani tĂ« madhe, dhe X5 Retail Group nuk Ă«shtĂ« pĂ«rjashtim, me zhvillimin rritet numri i projekteve ku kĂ«rkohet identifikimi i pĂ«rdoruesve. Me kalimin e kohĂ«s, kĂ«rkohet njĂ« kalim fluid i pĂ«rdoruesve nga njĂ« aplikacion nĂ« tjetrin dhe atĂ«herĂ« lind nevoja pĂ«r pĂ«rdorimin e njĂ« serveri tĂ« vetĂ«m pĂ«r identifikim, Single-Sign-On (SSO). Por si tĂ« veprojmĂ« kur provajderĂ«t e tillĂ« tĂ« identitetit si AD ose tĂ« tjerĂ«, qĂ« nuk kanĂ« atribute tĂ« tjera shtesĂ«, tashmĂ« pĂ«rdoren nĂ« projekte tĂ« ndryshme. PĂ«r kĂ«tĂ«, do tĂ« na ndihmojnĂ« sistemet e klasĂ«s sĂ« quajtur "brokerĂ«t e identitetit". MĂ« tĂ« funksionalĂ«t janĂ« pĂ«rfaqĂ«suesit e tij, tĂ« tillĂ« si Keycloak, Gravitee Access Management, etj. MĂ« sĂ« shpeshti, skenarĂ«t e pĂ«rdorimit mund tĂ« jenĂ« tĂ« ndryshĂ«m: ndĂ«rveprimi i makinave, pjesĂ«marrja e pĂ«rdoruesve, etj. Zgjidhja duhet tĂ« mbĂ«shtesĂ« njĂ« funksionalitet fleksibĂ«l dhe tĂ« shkallĂ«zueshĂ«m, nĂ« gjendje tĂ« bashkojĂ« tĂ« gjitha kĂ«rkesat nĂ« njĂ«, dhe njĂ« zgjidhje e tillĂ« nĂ« kompaninĂ« tonĂ« aktualisht Ă«shtĂ« brokeri i identitetit â Keycloak.
Keycloak â Ă«shtĂ« njĂ« produkt me kod tĂ« hapur, i destinuar pĂ«r identifikimin dhe kontrollin e qasjes, dhe i mbĂ«shtetur nga kompania RedHat. Ai Ă«shtĂ« baza pĂ«r produktet e kompanisĂ« qĂ« pĂ«rdorin SSO â RH-SSO.
Koncepte themelore
Para se të filloni të shqyrtoni zgjidhjet dhe qasjet, duhet të përcaktoni terminologjinë dhe sekuencën e proceseve:
Identifikimi â Ă«shtĂ« procedura e njohjes sĂ« subjektit sipas identifikuesit tĂ« tij (thjesht, kjo Ă«shtĂ« pĂ«rcaktimi i emrit, login-it ose numrit).
Autentifikimi â Ă«shtĂ« procedura e verifikimit tĂ« identitetit (pĂ«rdoruesi verifikohet me anĂ« tĂ« njĂ« fjalĂ«kalimi, letra verifikohet me anĂ« tĂ« njĂ« nĂ«nshkrimi elektronike, etj.)
Autorizimi â Ă«shtĂ« ofrimi i qasjes nĂ« njĂ« burim tĂ« caktuar (pĂ«r shembull, nĂ« email-in tuaj).
Brokeri i identifikimit Keycloak
Keycloak â Ă«shtĂ« njĂ« zgjidhje pĂ«r menaxhimin e identifikimit dhe qasjes me kod tĂ« hapur, e destinuar pĂ«r t'u pĂ«rdorur nĂ« Sistemet e Informacionit ku mund tĂ« pĂ«rdoren modele tĂ« arkitekturĂ«s mikroshĂ«rbimeve.
Keycloak ofron funksione të tilla si hyrje e vetme (SSO), identifikim broker dhe hyrje sociale, federatë përdoruesish, adaptues klientësh, konsolë administratori dhe konsolë menaxhimi për llogaritë.
Funksionaliteti bazë, i mbështetur në Keycloak:
- Single-Sign On dhe Single-Sign Out për aplikacionet e shfletuesit.
- Mbështetje për OpenID/OAuth 2.0/SAML.
- Identity Brokering â autentifikimi me anĂ« tĂ« ofruesve tĂ« jashtĂ«m tĂ« identitetit OpenID Connect ose SAML.
- Social Login â mbĂ«shtetje pĂ«r Google, GitHub, Facebook, Twitter pĂ«r identifikimin e pĂ«rdoruesve.
- User Federation â sinkronizimi i pĂ«rdoruesve nga serverĂ«t LDAP dhe Active Directory dhe ofrues tĂ« tjerĂ« identiteti.
- Kerberos bridge â pĂ«rdorimi i serverit Kerberos pĂ«r autentifikimin automatik tĂ« pĂ«rdoruesve.
- Admin Console â pĂ«r menaxhimin e centralizuar tĂ« konfigurimeve dhe parametrave tĂ« zgjidhjes pĂ«rmes Web.
- Account Management Console â pĂ«r menaxhimin e vetĂ«pĂ«rdoruesve tĂ« profileve tĂ« pĂ«rdoruesve.
- Kustomizimi i zgjidhjes në bazë të stilit të markës së kompanisë.
- 2FA Authentication â mbĂ«shtetje pĂ«r TOTP/HOTP me Google Authenticator ose FreeOTP.
- Login Flows â vetĂ«-regjistrimi i pĂ«rdoruesve, rikuperimi dhe rinovimi i fjalĂ«kalimeve dhe tĂ« tjera.
- Session Management â administratorĂ«t mund tĂ« menaxhojnĂ« sesionet e pĂ«rdoruesve nga njĂ« pikĂ« tĂ« vetme.
- Token Mappers â lidhja e atributeve tĂ« pĂ«rdoruesve, roleve dhe atributeve tĂ« tjera tĂ« kĂ«rkuara nĂ« tokene.
- Menaxhimi fleksibël i politikave përmes realm, aplikacioneve dhe përdoruesve.
- MbĂ«shtetje CORS â adaptuesit e klientĂ«ve kanĂ« mbĂ«shtetje tĂ« integruar pĂ«r CORS.
- Interfatat e ShĂ«rbimeve (SPI) â njĂ« numĂ«r i madh SPI qĂ« lejojnĂ« konfigurimin e aspekteve tĂ« ndryshme tĂ« funksionimit tĂ« serverit: rrjedhat e autentikimit, ofruesit e identitetit, pĂ«rputhja e protokolleve dhe shumĂ« mĂ« tepĂ«r.
- Adaptuesit e klientëve për aplikacione JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Mbështetje për punën me aplikacione të ndryshme që mbështesin bibliotekën OpenID Connect Relying Party ose bibliotekën SAML 2.0 Service Provider.
- Mundësia e zgjerimit duke përdorur plugins.
Për proceset CI/CD, si dhe automatizimin e proceseve të menaxhimit në Keycloak, mund të përdoret REST API/JAVA API. Dokumentacioni është i disponueshëm në format elektronik:
REST API
JAVA API
Ofruesit e identitetit të nivelit sipërmarrës (On-Premise)
Mundësia e autentikimit të përdoruesve përmes shërbimeve të Federatës së Përdoruesve.
Gjithashtu mund tĂ« pĂ«rdoret autentikim i pĂ«rbashkĂ«t â nĂ«se pĂ«rdoruesit autentikohen nĂ« stacionet e punĂ«s me Kerberos (LDAP ose AD), ata mund tĂ« autentikohen automatikisht nĂ« Keycloak pa nevojĂ«n pĂ«r tĂ« pĂ«rsĂ«ritur emrin e pĂ«rdoruesit dhe fjalĂ«kalimin.
Për autentikimin dhe autorizimin e mëtejshëm të përdoruesve, mund të përdoret një DBMS relacional, që është më e përshtatshme për mjediset e zhvillimit sepse nuk kërkon konfiguraime të gjata dhe integrime në fazat e hershme të projekteve. Në mënyrë default, Keycloak përdor një DBMS të integruar për ruajtjen e konfigurimeve dhe të dhënave të përdoruesve.
Lista e DBMS-ve të mbështetur është e gjerë dhe përfshin: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle dhe të tjerë. Të testuarit më së miri deri më tani janë Oracle 12C Release1 RAC dhe Galera 3.12 kluster për MariaDB 10.1.19.
Ofruesit e identitetit â login social
ĂshtĂ« e mundur tĂ« pĂ«rdoret login nga rrjetet sociale. PĂ«r aktivizimin e mundĂ«sisĂ« pĂ«r tĂ« autentikuar pĂ«rdoruesit, pĂ«rdoret konsola e administratorit nĂ« Keycloak. Nuk kĂ«rkohen ndryshime nĂ« kodin e aplikacioneve dhe ky funksionalitet Ă«shtĂ« i disponueshĂ«m "nga kutia" dhe mund tĂ« aktivizohet nĂ« çdo fazĂ« tĂ« zbatimit tĂ« projektit.
Për autentikimin e përdoruesve, është e mundur të përdoren ofruesit e identitetit OpenID/SAML.
Skema tipike të autorizimit duke përdorur OAuth2 në Keycloak
Authorization Code Flow â pĂ«rdoret me aplikacionet server (server-side applications). NjĂ« nga llojet mĂ« tĂ« zakonshme tĂ« autorizimit, pasi pĂ«rshtatet mirĂ« pĂ«r aplikacionet server, ku kodi burimor i aplikacionit dhe tĂ« dhĂ«nat e klientit nuk janĂ« tĂ« qasshĂ«m pĂ«r tĂ« tjerĂ«t. Procesi nĂ« kĂ«tĂ« rast mbĂ«shtetet nĂ« ridrejtimin (redirection). Aplikacioni duhet tĂ« jetĂ« nĂ« gjendje tĂ« ndĂ«rveprojĂ« me agjentĂ«t e pĂ«rdoruesit (user-agent), si shfletuesin e internetit â pĂ«r tĂ« marrĂ« kodet e autorizimit tĂ« API-sĂ« tĂ« ridrejtuara pĂ«rmes agjentit tĂ« pĂ«rdoruesit.
Fluksi Implicit â pĂ«rdoret nga aplikacionet mobile ose webs (aplikacionet qĂ« punojnĂ« nĂ« pajisjen e pĂ«rdoruesit).
Lloji implicit i autorizimit përdoret nga aplikacionet mobile dhe ato në web, ku privatësia e klientit nuk mund të garantohet. Lloji implicit i autorizimit gjithashtu përdor ridirektimin e agjentit të përdoruesit, duke transferuar tokenin e aksesit te agjenti i përdoruesit për përdorim të mëtejshëm në aplikacion. Kjo e bën tokenin të disponueshëm për përdoruesin dhe aplikacione të tjera në pajisjen e përdoruesit. Në këtë lloj autorizimi nuk kryhet autentifikimi i aplikacionit, dhe vetë procesi mbështetet në URL-në e ridirektimit (e regjistruar më parë në shërbim).
Fluksi Implicit nuk mbështet tokenët e rinovimit (refresh tokens).
Fluksi i Grant-it tĂ« Kredencialeve tĂ« Klientit â pĂ«rdoren kur aplikacioni ka qasje nĂ« API. Ky lloj autorizimi zakonisht pĂ«rdoret pĂ«r ndĂ«rveprime 'server-server', qĂ« duhet tĂ« kryhen nĂ« sfond pa ndĂ«rveprim tĂ« menjĂ«hershĂ«m me pĂ«rdoruesin. Fluxi i ofrimit tĂ« kredencialeve tĂ« klientit lejon qĂ« shĂ«rbimi nĂ« internet (klienti konfidencial) tĂ« pĂ«rdorĂ« kredencialet e tij nĂ« vend tĂ« personifikimit tĂ« pĂ«rdoruesit pĂ«r verifikimin e identitetit kur thĂ«rret njĂ« shĂ«rbim tjetĂ«r nĂ« internet. PĂ«r njĂ« nivel mĂ« tĂ« lartĂ« sigurie, shĂ«rbimi qĂ« bĂ«n thirrjen mund tĂ« pĂ«rdorĂ« njĂ« certifikatĂ« (ndryshe nga sekreti i zakonshĂ«m) si kredenciale.
Specifikimi OAuth2 përshkruhet në
Tokeni JWT dhe përfitimet e tij
JWT (JSON Web Token) â njĂ« standard i hapur (), i cili pĂ«rcakton njĂ« mĂ«nyrĂ« tĂ« kompaktĂ« dhe autonome pĂ«r tĂ« transferuar informacionin nĂ« mĂ«nyrĂ« tĂ« sigurt midis palĂ«ve nĂ« formĂ«n e njĂ« objekti JSON.
Sipas standardit, tokeni përbëhet nga tre pjesë në formatin base-64, të ndara me pika. Pjesa e parë quhet header dhe përmban llojin e tokenit dhe emrin e algoritmit të hash-it për të marrë nënshkrimin digjital. Pjesa e dytë ruan informacionin kryesor (përdoruesi, atributet etj.). Pjesa e tretë është nënshkrimi digjital.
..
Mos e ruani kurrë tokenin në bazën tuaj të të dhënave. Sepse një token i vlefshëm është ekuivalent me një fjalëkalim; ruajtja e tokenit është e barabartë me ruajtjen e fjalëkalimit të hapur.
Access-token është një token që i jep pronarit të tij qasje në burimet e mbrojtura të serverit. Zakonisht ka një jetëshkurtër dhe mund të mbajë informacion shtesë, si për shembull adresën IP të palës që kërkon këtë token.
Refresh-token është një token që u lejon klientëve të kërkojnë access-token të rinj pas skadimit të kohës së tyre të jetës. Këto tokenë zakonisht jepen për një periudhë afatgjatë.
Përfitimet kryesore të përdorimit në arkitekturën mikrosërvizore:
- Mundësia për të pasur qasje në aplikacione dhe shërbime të ndryshme përmes një autentifikimi një herësh.
- Në mungesë të disa atributëve të kërkuar në profilin e përdoruesve, është e mundshme që të pasurohet me të dhëna që mund të shtohen në ngarkesë, përfshirë dhe automatizimin dhe "në flakë".
- Nuk është e nevojshme të ruhet informacioni mbi sesionet aktive; aplikacioni server duhet vetëm të verifikojë nënshkrimin.
- Menaxhim më fleksibël i aksesit përmes atributeve shtesë në ngarkesë.
- Përdorimi i nënshkrimit të tokenit për titullin dhe ngarkesën rrit sigurinë e zgjidhjes në tërësi.
Tokeni JWT â pĂ«rbĂ«rja
Titulli â sipas parazgjedhjeve, titulli pĂ«rmban vetĂ«m tipin e tokens dhe algoritmin e pĂ«rdorur pĂ«r enkriptim.
Tipi i tokenit ruhet nĂ« çelĂ«sin «typ». ĂelĂ«si «typ» injorohet nĂ« JWT. NĂ«se çelĂ«si «typ» Ă«shtĂ« i pranishĂ«m, vlera e tij duhet tĂ« jetĂ« JWT pĂ«r tĂ« treguar se ky objekt Ă«shtĂ« JSON Web Token.
ĂelĂ«si i dytĂ« «alg» pĂ«rcakton algoritmin e pĂ«rdorur pĂ«r enkriptimin e tokenit. Sipas parazgjedhjeve, ai duhet tĂ« vendoset nĂ« HS256. Titulli kodifikohet nĂ« base64.
{ "alg": "HS256", "typ": "JWT"}
Ngarkesa (pĂ«rmbajtja) â nĂ« ngarkesĂ« ruhet çdo informacion qĂ« nevojitet pĂ«r t'u verifikuar. Ădo çelĂ«s nĂ« ngarkesĂ« njihet si "deklaratĂ«". PĂ«r shembull, nĂ« aplikacion mund tĂ« hyhet vetĂ«m me ftesĂ« (promocion i mbyllur). Kur duam tĂ« ftojmĂ« dikĂ« tĂ« marrĂ« pjesĂ«, i dĂ«rgojmĂ« atij njĂ« letĂ«r me ftesĂ«. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« verifikohet se adresa e email-it i pĂ«rket personit qĂ« pranon ftesĂ«n, prandaj ne do ta pĂ«rfshijmĂ« kĂ«tĂ« adresĂ« nĂ« ngarkesĂ«, duke e ruajtur atĂ« nĂ« çelĂ«sin "e-mail".
{ "email": "example@x5.ru" }
ĂelĂ«sat nĂ« ngarkesĂ« mund tĂ« jenĂ« tĂ« rastĂ«sishĂ«m. MegjithatĂ«, ka disa tĂ« rezervuar:
- iss (LĂ«shuesi) â pĂ«rcakton aplikacionin nga i cili dĂ«rgohet tokeni.
- sub (Subjekti) â pĂ«rcakton temĂ«n e tokenit.
- aud (Audita) â njĂ« array i vargjeve ndjeshme ndaj rastit ose URI, qĂ« Ă«shtĂ« njĂ« listĂ« e marrĂ«sve tĂ« kĂ«tij tokeni. Kur pala qĂ« pranon merr JWT me kĂ«tĂ« çelĂ«s, ajo duhet tĂ« kontrollojĂ« praninĂ« e saj nĂ« marrĂ«sit â pĂ«rndryshe ta injorojĂ« tokenin.
- exp (Koha e skadencĂ«s) â tregon se kur skadon vlefshmĂ«ria e token-it. Standarti JWT kĂ«rkon qĂ« nĂ« tĂ« gjitha implementimet e tij token-et me skadencĂ« tĂ« refuzohen. ĂelĂ«si exp duhet tĂ« jetĂ« njĂ« shenjĂ« kohe nĂ« formatin UNIX.
- nbf (Jo Para) â Ă«shtĂ« koha nĂ« formatin UNIX, qĂ« pĂ«rcakton momentin kur token-i do tĂ« bĂ«het i vlefshĂ«m.
- iat (LĂ«shuar NĂ«) â ky çelĂ«s pĂ«rfaqĂ«son kohĂ«n kur token-i Ă«shtĂ« lĂ«shuar dhe mund tĂ« pĂ«rdoret pĂ«r tĂ« pĂ«rcaktuar moshĂ«n e JWT. ĂelĂ«si iat duhet tĂ« jetĂ« njĂ« shenjĂ« kohe nĂ« formatin UNIX.
- Jti (ID e JWT) â njĂ« varg qĂ« pĂ«rcakton njĂ« identifikues unik tĂ« kĂ«tij token-i duke marrĂ« parasysh tĂ« gjitha shkronjat.
ĂshtĂ« e rĂ«ndĂ«sishme tĂ« kuptohet se ngarkesa e dobishme nuk transmetohet nĂ« formĂ« tĂ« enkriptuar (megjithatĂ«, token-et mund tĂ« jenĂ« tĂ« ngjashme dhe nĂ« atĂ« rast Ă«shtĂ« e mundur tĂ« transmetohen tĂ« dhĂ«na tĂ« enkriptuara). Prandaj, nuk Ă«shtĂ« e mundur tĂ« ruhet ndonjĂ« informacion sekret brenda saj. Siç Ă«shtĂ« edhe titulli, ngarkesa e dobishme kodifikohet nĂ« base64.
NĂ«nshkrimi â kur kemi titullin dhe ngarkesĂ«n, mund tĂ« llogarisim nĂ«nshkrimin.
PĂ«rzgjidhen tĂ« koduara nĂ« base64: titulli dhe ngarkesa, ato bashkohen nĂ« njĂ« varg pĂ«rmes pikĂ«s. Pastaj ky varg dhe çelĂ«si sekret kalojnĂ« nĂ« algoritmin e enkriptimit tĂ« pĂ«rcaktuar nĂ« titull (çelĂ«si "alg"). ĂelĂ«si mund tĂ« jetĂ« çdo varg. Vargjet mĂ« tĂ« gjata do tĂ« jenĂ« mĂ« tĂ« preferueshme, pasi do tĂ« kĂ«rkojnĂ« mĂ« shumĂ« kohĂ« pĂ«r tĂ« gjetur.
{"alg":"RSA1_5", "payload":"A128CBC-HS256"}
Ndërtimi i arkitekturës së një klasteri të qëndrueshëm Keycloak
Përsa i përket përdorimit të një klasteri të vetëm për të gjitha projektet, kërkesat për zgjidhjen e SSO janë të rritura. Kur numri i projekteve është i vogël, këto kërkesa nuk ndihen fort në të gjitha projektet, megjithatë me rritjen e numrit të përdoruesve dhe integrimeve, rriten kërkesat për disponueshmërinë dhe performancën.
Rritja e rrezikut të dështimit të një SSO të vetëm ngre kërkesat për arkitekturën e zgjidhjes dhe metodat e përdorura për rezervimin e komponentëve dhe çon në një SLA shumë strikte. Siç ndodh, shpesh gjatë zhvillimit ose fazave të hershme të zbatimit të zgjidhjeve, projektet kanë infrastrukturë të vetën që nuk është e qëndrueshme ndaj dështimeve. Me zhvillimin, është e nevojshme të planifikohet mundësia e zhvillimit dhe shkallëzimit. Një klaster i qëndrueshëm ndaj dështimeve ndërtuar më fleksibël me përdorimin e virtualizimit të kontejnerëve ose qasjes hibride.
PĂ«r tĂ« punuar nĂ« modin Active/Active dhe Active/Passive, klasteri kĂ«rkon ruajtjen e qĂ«ndrueshmĂ«risĂ« sĂ« tĂ« dhĂ«nave nĂ« bazĂ«n e tĂ« dhĂ«nave relacional â tĂ« dy nyjet e bazĂ«s sĂ« tĂ« dhĂ«nave duhet tĂ« replikohen nĂ« mĂ«nyrĂ« sinxhrone midis qendrave tĂ« tĂ« dhĂ«nave tĂ« distribuuara gjeografikisht.
Shembulli më i thjeshtë i instalimit të qëndrueshëm ndaj dështimeve.
Cilat janë përfitimet e përdorimit të një klasteri të vetëm:
- Disponueshmëri e lartë dhe performancë.
- Mbështetje për mënyrat e punës: Active/Active, Active/Passive.
- MundĂ«sia e shkallĂ«zimit dinamik â me pĂ«rdorimin e virtualizimit tĂ« kontejnerĂ«ve.
- Mundësia e menaxhimit dhe monitorimit të centralizuar.
- Qëndrim i vetëm për identifikimin/autentifikimin/autorizimin e përdoruesve në projekte.
- Interaction më e qartë mes projekteve të ndryshme pa përfshirjen e përdoruesve.
- Mundësia e ripërdorimit të tokenit JWT në projekte të ndryshme.
- Një pikë e vetme besimi.
- Nisje më e shpejtë e projekteve duke përdorur mikroshërbime/virtualizimin e kontejnerëve (nuk kërkohet ngritja dhe konfigurimi i komponenteve të tjera).
- Mundësia për të blerë mbështetje komerciale nga shitësi.
ĂfarĂ« duhet tĂ« kushtohet vĂ«mendje gjatĂ« planifikimit tĂ« klasterit
DBMS
Keycloak përdor një sistem menaxhimi DBMS për ruajtjen e: realms, clients, users, etj.
MbĂ«shtetet njĂ« gamĂ« e gjerĂ« e DBMS: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak vjen me njĂ« bazĂ« tĂ« dhĂ«nash relacional tĂ« integruar. PĂ«rdorimi rekomandohet pĂ«r ambientet e pak ngarkuara â si pĂ«r shembull ambientet e zhvillimit.
Për punën në modalitetin Active/Active dhe Active/Passive të klasterit kërkohet të sigurohet që të dhënat të jenë të qëndrueshme në bazën e të dhënave relacionale dhe të dy nyjet e klasterit të bazës së të dhënave të replikohen në mënyrë të sinkronizuar mes Qendrave të Të Dhënave.
Cache e shpërndarë (Infinispan)
Për funksionimin e saktë të klasterit, kërkohet sinkronizimi shtesë i tipeve të ndryshme të caches duke përdorur JBoss Data Grid:
Sesione tĂ« autentikimit â pĂ«rdoret pĂ«r ruajtjen e tĂ« dhĂ«nave gjatĂ« autentikimit tĂ« njĂ« pĂ«rdoruesi tĂ« caktuar. KĂ«rkesat nga ky cache zakonisht pĂ«rfshijnĂ« vetĂ«m shfletuesin dhe serverin Keycloak, dhe jo aplikacionin.
Tokenat e veprimit â pĂ«rdoren pĂ«r skenarĂ«t kur pĂ«rdoruesi duhet tĂ« konfirmojĂ« njĂ« veprim asinkronisht (nĂ«pĂ«rmjet email-it). PĂ«r shembull, gjatĂ« procesit tĂ« rikujtimit tĂ« fjalĂ«kalimit, cache-i i actionTokens Infinispan pĂ«rdoret pĂ«r tĂ« ndjekur metadata nĂ« lidhje me shenjat e veprimit tĂ« lidhura qĂ« janĂ« pĂ«rdorur tashmĂ«, ndaj nuk mund tĂ« pĂ«rdoren pĂ«rsĂ«ri.
Caching dhe pastrimi i të dhënave të qëndrueshme - përdoret për të bërë cache të të dhënave të qëndrueshme për të shmangur kërkesat e panevojshme në bazën e të dhënave. Kur ndonjë server Keycloak azhurnon të dhënat, të gjithë serverët e tjerë Keycloak në të gjitha qendrat e të dhënave duhet të jenë në dijeni për këtë.
Puna â pĂ«rdoret vetĂ«m pĂ«r dĂ«rgimin e mesazheve tĂ« pastrimit midis nyjeve tĂ« klasterit dhe qendrave tĂ« tĂ« dhĂ«nave.
Seancat e pĂ«rdoruesve â pĂ«rdoren pĂ«r tĂ« ruajtur tĂ« dhĂ«nat e seancave tĂ« pĂ«rdoruesve, tĂ« cilat vlejnĂ« pĂ«r gjatĂ« seancĂ«s sĂ« shfletuesit tĂ« pĂ«rdoruesit. Cache duhet tĂ« trajtojĂ« kĂ«rkesat HTTP nga pĂ«rdoruesi dhe aplikacioni.
Mbrojtja nga forcimi bruto â pĂ«rdoret pĂ«r tĂ« ndjekur tĂ« dhĂ«nat e hyrjeve tĂ« dĂ«shtuar.
Balancimi i ngarkesës
Balancuesi i ngarkesës është pika e vetme e hyrjes në keycloak dhe duhet të mbështesë seancat e ngjitura.
Servis të aplikacioneve
Përdoren për të kontrolluar ndërveprimin e komponentëve ndërmjet tyre dhe mund të virtualizohen ose containerizohen duke përdorur mjete ekzistuese për automatizim dhe shkallëzim dinamik të infrastrukturës. Skemët më të zakonshme të ndarjes janë në OpenShift, Kubernates, Rancher.
KĂ«tu pĂ«rfundon pjesa e parĂ« â teorike. NĂ« ciklet e ardhshme tĂ« artikujve do tĂ« shqyrtohen shembuj integrimesh me ofrues tĂ« ndryshĂ«m tĂ« identitetit dhe shembuj konfigurimesh.
Burimi: habr.com
