NĂ« çdo kompani tĂ« madhe, dhe X5 Retail Group nuk bĂ«n pĂ«rjashtim, me kalimin e kohĂ«s rritet numri i projekteve ku kĂ«rkohet autorizimi i pĂ«rdoruesve. Me kalimin e kohĂ«s, nevojitet njĂ« kalim pa pengesa 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 Identifikimin dhe Autorizimin e PĂ«rdoruesve (Single-Sign-On - SSO). Por si tĂ« veprohet, kur ofrues tĂ« tillĂ« identifikimi si AD apo tĂ« tjerĂ«, qĂ« nuk disponojnĂ« atribute shtesĂ«, pĂ«rdoren tashmĂ« nĂ« projekte tĂ« ndryshme. KĂ«tu vjen ndihma nga njĂ« klasĂ« sistemesh tĂ« quajtur "borker identifikimi". MĂ« funksionalĂ«t janĂ« pĂ«rfaqĂ«suesit e tij, si Keycloak, Gravitee Access management etj. ScenarĂ«t e pĂ«rdorimit shpesh mund tĂ« jenĂ« tĂ« ndryshĂ«m: ndĂ«rveprimi makinĂ«-makine, pjesĂ«marrja e pĂ«rdoruesve, etj. Zgjidhja duhet tĂ« mbĂ«shtesĂ« njĂ« funksionalitet fleksibĂ«l dhe tĂ« shkallĂ«zueshĂ«m, i aftĂ« tĂ« bashkojĂ« tĂ« gjitha kĂ«rkesat nĂ« njĂ«, dhe zgjidhja e tillĂ« nĂ« kompaninĂ« tonĂ« aktualisht Ă«shtĂ« brokeri identifikues â Keycloak.
Keycloak Ă«shtĂ« njĂ« produkt me kod tĂ« hapur, i destinuar pĂ«r identifikimin dhe kontrollin e aksesit, dhe mbĂ«shtetet nga kompania RedHat. Ai Ă«shtĂ« baza pĂ«r produktet e kompanisĂ« qĂ« pĂ«rdorin SSO â RH-SSO.
Konceptet themelore
Para se të filloni të hulumtoni zgjidhjet dhe qasjet, duhet të përcaktoni terminologjinë dhe rendin e proceseve:
Identifikimi â kjo Ă«shtĂ« procedura e njohjes sĂ« subjektit me identifikuesin e tij (thjesht, kjo Ă«shtĂ« pĂ«rcaktimi i emrit, username ose numrit).
Autentikimi â kjo Ă«shtĂ« procedura e verifikimit (pĂ«rdoruesi verifikohet me fjalĂ«kalim, emaili verifikohet me nĂ«nshkrim elektronik etj.)
Autorizimi â kjo Ă«shtĂ« ofrimi i aksesit nĂ« ndonjĂ« burim (pĂ«r shembull, nĂ« emailin elektronik).
Brokeri identifikues Keycloak
Keycloak â kjo Ă«shtĂ« njĂ« zgjidhje pĂ«r menaxhimin e identifikimit dhe aksesit me kod tĂ« hapur, e destinuar pĂ«r t'u pĂ«rdorur nĂ« informacionin e sistemit ku mund tĂ« pĂ«rdoren modelet e arkitekturĂ«s mikroshĂ«rbimeve.
Keycloak ofron funksione si: hyrje të vetme (SSO), identifikim brokeri dhe hyrje sociale në sistem, federatë përdoruesish, adaptorë klientësh, konsolën e administratorit dhe konsolën për menaxhimin e llogarive.
Funksionaliteti i bazës, i mbështetur në Keycloak:
- Single-Sign On dhe Single-Sign Out për aplikacione të shfletuesit.
- Mbështetje për OpenID/OAuth 2.0/SAML.
- Identiteti i ShĂ«rbimit â autentikimi me ndihmĂ«n e ofruesve tĂ« identitetit tĂ« jashtĂ«m OpenID Connect ose SAML.
- Login Social â mbĂ«shtetje pĂ«r Google, GitHub, Facebook, Twitter pĂ«r identifikimin e pĂ«rdoruesve.
- Federimi i PĂ«rdoruesve â sinkronizimi i pĂ«rdoruesve nga serverĂ«t LDAP dhe Active Directory dhe ofrues tĂ« tjetĂ«r identiteti.
- Bridge Kerberos â pĂ«rdorimi i serverit Kerberos pĂ«r autentikimin automatik tĂ« pĂ«rdoruesve.
- Konsola e Administratorit â pĂ«r menaxhimin e centralizuar tĂ« konfigurimeve dhe parametrave tĂ« zgjidhjes pĂ«rmes Web-it.
- Konsola e Menaxhimit tĂ« Llogarive â pĂ«r menaxhimin e pavarur tĂ« profilit tĂ« pĂ«rdoruesve.
- Kostumizimi i zgjidhjes në bazë të stilit të brendshëm të kompanisë.
- Autentikimi 2FA â mbĂ«shtetje pĂ«r TOTP/HOTP me ndihmĂ«n e Google Authenticator ose FreeOTP.
- Flukset e Kyçjes â regjistrimi i vetĂ«-pĂ«rdoruesve, rikuperimi dhe rivendosja e fjalĂ«kalimeve dhe mĂ« shumĂ«.
- Menaxhimi i Sesioneve â administratorĂ«t mund tĂ« menaxhojnĂ« sesionet e pĂ«rdoruesve nga njĂ« pikĂ« qendrore.
- Mappers e TokenĂ«ve â lidhja e atributeve tĂ« pĂ«rdoruesve, roleve dhe atributeve tĂ« tjera tĂ« nevojshme nĂ« tokenĂ«.
- Menaxhimi fleksibël i politikave përmes realm, aplikacionit dhe përdoruesve.
- MbĂ«shtetje CORS â adaptuesit e klientĂ«ve kanĂ« mbĂ«shtetje tĂ« brendshme pĂ«r CORS.
- Interface tĂ« Ofruesve tĂ« ShĂ«rbimeve (SPI) â njĂ« sĂ«rĂ« SPI-sĂ«h, duke lejuar konfigurimin e aspekteve tĂ« ndryshme tĂ« funksionimit tĂ« serverit: fluxet e autentikimit, ofruesit e identitetit, pĂ«rputhja e protokolleve dhe shumĂ« mĂ« tepĂ«r.
- Adaptuesit e klientëve për aplikacionet JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Mbështetje për punën me aplikacione të ndryshme që mbështesin bibliotekën e OpenID Connect Relying Party ose bibliotekën e Shërbimit të Ofruesit SAML 2.0.
- 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 të ndërmarrjes (On-Premise)
Mundësia për autentikimin e përdoruesve përmes shërbimeve të Federimit të Përdoruesve.
Gjithashtu, mund tĂ« pĂ«rdoret autentikimi i vazhdueshĂ«m â nĂ«se pĂ«rdoruesit autentikohen nĂ« stacionet e punĂ«s me Kerberos (LDAP ose AD), ata mund tĂ« autentikohen automatikisht nĂ« Keycloak pa pasur nevojĂ« tĂ« japin pĂ«rsĂ«ri emrin e pĂ«rdoruesit dhe fjalĂ«kalimin.
Për autentikimin dhe autorizimin e mëpasshëm të përdoruesve, është e mundur të përdoren një bazë e dhënash relacional, e cila është më e aplikueshme për mjediset e zhvillimit, pasi nuk kërkon konfigurime të zgjatura dhe integrime në fazat fillestare të projekteve. Për default, në Keycloak përdoret një bazë e dhënash e integruar për ruajtjen e konfigurimeve dhe të dhënave mbi përdoruesit.
Lista e bazave të dhënash të mbështetura është e gjerë dhe përfshin: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle dhe të tjera. Aktualisht, më të testuarat janë Oracle 12C Release1 RAC dhe Galera 3.12 cluster për MariaDB 10.1.19.
Ofruesit e identifikimit â kyçja sociale
ĂshtĂ« e mundur pĂ«rdorimi i kyçjes nga rrjetet sociale. PĂ«r aktivizimin e mundĂ«sisĂ« pĂ«r tĂ« autentifikuar pĂ«rdoruesit, pĂ«rdoret konsola e administratorit tĂ« 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Ă« realizimit tĂ« projektit.
Për autentikimin e përdoruesve, është e mundur të përdoren ofruesit e identitetit OpenID/SAML.
Skenarët tipik të autorizimit me përdorimin e OAuth2 në Keycloak
Fluksi i Kodit tĂ« Autorizimit â pĂ«rdoret me aplikacionet server-side. NjĂ« nga llojet mĂ« tĂ« zakonshme tĂ« lejes pĂ«r autorizim, pasi Ă«shtĂ« shumĂ« i pĂ«rshtatshĂ«m pĂ«r aplikacionet server-side, nĂ« tĂ« cilat kode burimi i aplikacionit dhe tĂ« dhĂ«nat e klientit nuk janĂ« tĂ« aksesueshme pĂ«r tĂ« tjerĂ«t. Procesi nĂ« kĂ«tĂ« rast Ă«shtĂ« i ndĂ«rtuar mbi ridrejtimin (redirection). Aplikacioni duhet tĂ« jetĂ« nĂ« gjendje tĂ« ndĂ«rveprojĂ« me agjentĂ«t e pĂ«rdoruesit (user-agents), siç Ă«shtĂ« shfletuesi i internetit â pĂ«r tĂ« marrĂ« kodet e autorizimit tĂ« API qĂ« ridrejtohen pĂ«rmes agjentĂ«ve tĂ« pĂ«rdoruesve.
Fluksi Implicit â pĂ«rdoret nga aplikacionet mobile ose web (aplikacione qĂ« punojnĂ« nĂ« pajisjen e pĂ«rdoruesit).
Tipi implicit i autorizimit përdoret nga aplikacionet mobile dhe web, ku privatësia e klientit nuk mund të garantohet. Ky tip autorizimi gjithashtu përdor ridrejtime të agjentit të përdoruesit, ku access token-i i kalon agjentit të përdoruesit për përdorim të mëvonshëm në aplikacion. Kjo e bën token-in të disponueshëm për përdoruesin dhe aplikacione të tjera në pajisjen e përdoruesit. Me këtë tip autorizimi nuk realizohet verifikimi i vërtetësisë së aplikacionit, dhe procesi mbështetet në URL-në e ridrejtuar (e regjistruar më parë në shërbim).
Implicit Flow nuk mbështet token-at e rinovimit (refresh tokens).
Fluksi i Akrediteve tĂ« Klientit â pĂ«rdoret kur aplikacioni qasje nĂ« API. Ky tip autorizimi zakonisht pĂ«rdoret pĂ«r ndĂ«rveprime "server-server", tĂ« cilat duhet tĂ« kryhen nĂ« sfond pa ndĂ«rveprim tĂ« menjĂ«hershĂ«m me pĂ«rdoruesin. Fluksi i akrediteve tĂ« klientit lejon shĂ«rbimet nĂ« internet (klientĂ« konfidencialĂ«) tĂ« pĂ«rdorin akreditimet e tyre nĂ« vend tĂ« identifikimit tĂ« pĂ«rdoruesit pĂ«r verifikim kur thirrin njĂ« shĂ«rbim tjetĂ«r nĂ« internet. PĂ«r njĂ« nivel mĂ« tĂ« lartĂ« sigurie, shĂ«rbimi qĂ« thĂ«rret mund tĂ« pĂ«rdorĂ« njĂ« certifikatĂ« (nĂ« vend tĂ« sekretit tĂ« zakonshĂ«m) si akreditim.
Specifikimi OAuth2 përshkruhet në
Token-i JWT dhe përfitimet e tij
JWT (JSON Web Token) është një standard i hapur (), i cili përcakton një mënyrë kompakte dhe autonome për transmetimin e sigurt të informacionit midis palëve në formën e një objekti JSON.
Sipas standardit, token-i pĂ«rbĂ«het nga tre pjesĂ« nĂ« format base-64, tĂ« ndara me pika. Pjesa e parĂ« quhet header, ku pĂ«rmban tipin e token-it dhe emrin e algoritmit tĂ« hash pĂ«r marrjen e nĂ«nshkrimit digjital. Pjesa e dytĂ« ruan informacionin kryesor (pĂ«rdoruesi, atributet etj.). Pjesa e tretĂ« â nĂ«nshkrimi digjital.
..
Kurrë mos e ruani token-in në databazën tuaj. Sepse një token i vlefshëm është ekuivalent me një fjalëkalim, ruajtja e token-it është njësoj si të ruani një fjalëkalim në mënyrë të hapur.
Access-token â Ă«shtĂ« njĂ« token qĂ« i jep akses pronarit tĂ« tij nĂ« burimet e mbrojtura tĂ« serverit. Zakonisht, ai ka njĂ« kohĂ«zgjatje tĂ« shkurtĂ«r dhe mund tĂ« pĂ«rmbajĂ« informacione shtesĂ«, si adresa IP e palĂ«s qĂ« po kĂ«rkon kĂ«tĂ« token.
Token rifreskimi â Ă«shtĂ« njĂ« token qĂ« i lejon klientĂ«ve tĂ« kĂ«rkojnĂ« tokene tĂ« reja tĂ« aksesit pasi tĂ« jetĂ« e skaduar koha e tyre. KĂ«to tokene zakonisht lĂ«shohen pĂ«r njĂ« periudhĂ« tĂ« gjatĂ«.
Pikat kryesore të përfitimeve të aplikimit në arkitekturën mikroserviz:
- Mundësia për të aksesuar aplikacione dhe shërbime të ndryshme përmes një autentifikimi të vetëm.
- Në mungesë të një sërë atributesh të nevojshme në profilin e përdoruesve, është e mundur të pasurohet me të dhëna që mund të shtohen në ngarkesën e dobishme, madje dhe automatizuar dhe "në flakë".
- Nuk ka nevojë të ruhet informacioni rreth seancave aktive, aplikacioni server duhet vetëm të kontrollojë nënshkrimin.
- Menaxhim më fleksibël të aksesit përmes atributesh shtesë në ngarkesën e dobishme.
- Përdorimi i nënshkrimit të tokenit për kokën dhe ngarkesën e dobishme rrit sigurinë e zgjidhjes në tërësi.
Tokeni JWT â pĂ«rbĂ«rja
Header-i â me default, koka pĂ«rmban vetĂ«m llojin e tokenit dhe algoritmin qĂ« pĂ«rdoret pĂ«r enkriptimin.
Lloji 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Ă« njĂ« JSON Web Token.
ĂelĂ«si i dytĂ« "alg" pĂ«rcakton algoritmin qĂ« pĂ«rdoret pĂ«r enkriptimin e tokenit. Me default, ai duhet tĂ« vendoset nĂ« HS256. Koka kodifikohet nĂ« base64.
{ "alg": "HS256", "typ": "JWT"}
Ngarkesa (pĂ«rmbajtja) â nĂ« ngarkesĂ«n e dobishme ruhet çdo informacion qĂ« duhet tĂ« verifikohet. Ădo çelĂ«s nĂ« ngarkesĂ«n e dobishme njihet si "çështje". PĂ«r shembull, nĂ« aplikacion mund tĂ« hyni vetĂ«m me ftesĂ« (promovim i mbyllur). Kur duam tĂ« ftojmĂ« dikĂ« tĂ« marrĂ« pjesĂ«, i dĂ«rgojmĂ« atij njĂ« letĂ«r ftesĂ«. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« verifikohet se adresa e emailit i pĂ«rket personit qĂ« pranon ftesĂ«n, prandaj do ta pĂ«rfshijmĂ« kĂ«tĂ« adresĂ« nĂ« ngarkesĂ«n e dobishme, pĂ«r kĂ«tĂ« do ta ruajmĂ« nĂ« çelĂ«sin "e-mail".
{ "email": "example@x5.ru" }
ĂelĂ«sat nĂ« ngarkesĂ«n e dobishme mund tĂ« jenĂ« tĂ« rastit. MegjithatĂ«, ka disa tĂ« rezervuar:
- iss (ShkĂ«putĂ«si) â pĂ«rcakton aplikacionin nga i cili dĂ«rgohet tokeni.
- sub (Subjekti) â pĂ«rcakton temĂ«n e tokenit.
- aud (Audience) â njĂ« array i vargjeve tĂ« ndjeshme ndaj regjistrit ose URI, qĂ« pĂ«rbĂ«n njĂ« listĂ« tĂ« marrĂ«sve tĂ« kĂ«tij tokeni. Kur pala marrĂ«se merr JWT me kĂ«tĂ« çelĂ«s, ajo duhet tĂ« kontrollojĂ« praninĂ« e saj te marrĂ«sit â nd otherwise ignore the token.
- exp (Koha e skadimit) â tregon kur skadon afati i vlefshmĂ«risĂ« sĂ« tokenit. Standardi JWT kĂ«rkon qĂ« nĂ« tĂ« gjitha implementimet e tij, tokes me afat tĂ« skaduar tĂ« refuzohen. ĂelĂ«si Exp duhet tĂ« jetĂ« njĂ« shĂ«nim kohor nĂ« formatin unix.
- nbf (Nuk pĂ«rpara) â kjo Ă«shtĂ« koha nĂ« formatin unix qĂ« pĂ«rcakton momentin kur tokeni do tĂ« bĂ«het i vlefshĂ«m.
- iat (I lĂ«shuar nĂ«) â ky çelĂ«s pĂ«rfaqĂ«son kohĂ«n kur tokeni Ă«shtĂ« lĂ«shuar dhe mund tĂ« pĂ«rdoret pĂ«r tĂ« pĂ«rcaktuar moshĂ«n e JWT. ĂelĂ«si iat duhet tĂ« jetĂ« njĂ« shĂ«nim kohor nĂ« formatin unix.
- Jti (ID e JWT) â njĂ« varg qĂ« pĂ«rcakton identifikuesin unik tĂ« kĂ«tij tokeni duke marrĂ« parasysh regjistrin.
ĂshtĂ« e rĂ«ndĂ«sishme tĂ« kuptohet se ngarkesa e dobishme nuk transmetohet nĂ« formĂ« tĂ« enkriptuar (megjithatĂ«, tokenet mund tĂ« jenĂ« tĂ« ndara dhe atĂ«herĂ« Ă«shtĂ« e mundur tĂ« transmetohen tĂ« dhĂ«na tĂ« enkriptura). Prandaj, nuk mund tĂ« ruani asnjĂ« informacion sekret nĂ« tĂ«. Ashtu si titulli, ngarkesa e dobishme kodifikohet nĂ« base64.
NĂ«nshkrimi â kur kemi titullin dhe ngarkesĂ«n, mund tĂ« llogaritim nĂ«nshkrimin.
Marrim titullin dhe ngarkesĂ«n tĂ« kodifikuara nĂ« base64, ato pĂ«rzihen nĂ« njĂ« varg pĂ«rmes pikĂ«s. MĂ« pas ky varg dhe çelĂ«si sekret hyjnĂ« nĂ« algoritmin e enkriptimit tĂ« specifikuar nĂ« titull (çelĂ«si âalgâ). ĂelĂ«si mund tĂ« jetĂ« çfarĂ«do vargu. KĂ«to vargje mĂ« tĂ« gjata do tĂ« jenĂ« mĂ« tĂ« preferuara, pasi do tĂ« nevojitet mĂ« shumĂ« kohĂ« pĂ«r t'u zbuluar.
{"alg":"RSA1_5", "payload":"A128CBC-HS256"}
Ndërtimi i arkitekturës së klasterit të qëndrueshëm të Keycloak
Kur përdorim një klaster të vetëm për të gjithë projektet, kërkesat për zgjidhjen e SSO rriten. Kur numri i projekteve nuk është i madh, këto kërkesa nuk janë aq të ndjeshme për të gjitha projektet, megjithatë me rritjen e numrit të përdoruesve dhe integrimeve, kërkesat për disponueshmërinë dhe performancën rriten.
Rritja e riskut të dështimit të SSO-së së vetme rrit kërkesat ndaj arkitekturës së zgjidhjes dhe metodave të përdorura për ruajtjen e komponentëve dhe çon në një SLA shumë të ashpër. Për këtë arsye, shpesh në zhvillimin ose në fazat e hershme të implementimit të zgjidhjeve, projektet kanë infrastrukturen e tyre jo të çrregullt. Me kalimin e kohës, është e nevojshme të parashikohet mundësia e zhvillimit dhe shkallëzimit. Një klaster i qëndrueshëm mund të ndërtohet më fleksibël duke përdorur virtualizimin e konteinerëve ose një qasje hibride.
PĂ«r tĂ« punuar nĂ« modalitetet Active/Active dhe Active/Passive, klasteri kĂ«rkon tĂ« sigurojĂ« konsistencĂ«n e tĂ« dhĂ«nave nĂ« njĂ« bazĂ« tĂ« dhĂ«nash relazionale â tĂ« dy node-t e bazĂ«s sĂ« tĂ« dhĂ«nave duhet tĂ« replikohen sinhronisht midis Qendrave tĂ« tĂ« DhĂ«nave me shpĂ«rndarje gjeografike.
Shembulli më i thjeshtë i një instalimi të qëndrueshëm.
Cilat janë avantazhet e përdorimit të një klasteri të vetëm:
- Disponueshmëri e lartë dhe performancë.
- Mbështetje për modalitetet e punës: Active/Active, Active/Passive.
- MundĂ«si pĂ«r shkallĂ«zim dinamik â kur pĂ«rdoret virtualizimi i konteinerĂ«ve.
- Mundësi për menaxhim dhe monitorim të centralizuar.
- Qasje e vetme për identifikimin/authentifikimin/autorizimin e përdoruesve në projekte.
- Ndërveprimi më i qartë midis projekteve të ndryshme pa pjesëmarrjen e përdoruesve.
- Mundësia e ripërdorimit të tokenit JWT në projekte të ndryshme.
- Pika e vetme e besueshmërisë.
- Start më të shpejtë të projekteve duke përdorur mikroshërbimet/virtualizimin e konteinerëve (nuk kërkohet ngritja dhe konfigurimi i komponenteve shtesë).
- Mundësia e blerjes së mbështetjes komerciale nga shitësi.
ĂfarĂ« duhet tĂ« merrni parasysh kur planifikoni klasterin
DBMS
Keycloak përdor një sistem menaxhimi DBMS për të ruajtur: realms, clients, users etj.
MbĂ«shtetet njĂ« gamĂ« e gjerĂ« DBMS: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak vjen me njĂ« bazĂ« tĂ« dhĂ«nash relazionale tĂ« integruar. PĂ«rdorimi rekomandohet pĂ«r mjediset qĂ« nuk ngarkohen â siç janĂ« mjediset e zhvillimit.
Për të punuar në modalitetet Active/Active dhe Active/Passive, klasteri kërkon të sigurojë konsistencën e të dhënave në një bazë të dhënash relazionale dhe të dy node-t e klasterit të bazës së të dhënave replikohen sinhronisht midis Qendrave të të Dhënave.
Cache i shpërndarë (Infinspan)
Për funksionimin e duhur të klasterit kërkohet sinkronizimi shtesë i këtyre llojeve të caches duke përdorur JBoss Data Grid:
Seancat e autentifikimit â pĂ«rdoren pĂ«r ruajtjen e tĂ« dhĂ«nave gjatĂ« autentifikimit tĂ« njĂ« pĂ«rdoruesi tĂ« caktuar. KĂ«rkesat nga ky cache zakonisht pĂ«rfshijnĂ« vetĂ«m shfletuesin dhe serverin Keycloak, jo aplikacionin.
Tokenat e veprimit â pĂ«rdoren pĂ«r skenarĂ«t kur pĂ«rdoruesi duhet tĂ« konfirmojĂ« njĂ« veprim asinkronisht (pĂ«rmes emailit). PĂ«r shembull, gjatĂ« procesit tĂ« rikuperimit tĂ« fjalĂ«kalimit, cache i actionTokens Infinispan pĂ«rdoret pĂ«r tĂ« ndjekur metadata mbi tokenat e lidhur me veprimet qĂ« tashmĂ« janĂ« pĂ«rdorur, prandaj nuk mund tĂ« pĂ«rdoren sĂ«rish.
Caching dhe invalidimi i tĂ« dhĂ«nave tĂ« pĂ«rhershme â pĂ«rdoret pĂ«r keshimin e tĂ« dhĂ«nave tĂ« pĂ«rhershme, pĂ«r tĂ« shmangur kĂ«rkesat e panevojshme ndaj bazĂ«s sĂ« tĂ« dhĂ«nave. Kur ndonjĂ« server Keycloak pĂ«rditĂ«son tĂ« dhĂ«nat, tĂ« gjithĂ« serverĂ«t e tjerĂ« Keycloak nĂ« tĂ« gjitha qendrat e tĂ« dhĂ«nave duhet tĂ« dinĂ« pĂ«r kĂ«tĂ«.
Puna â pĂ«rdoret vetĂ«m pĂ«r dĂ«rgimin e mesazheve mbi pavlefshmĂ«rinĂ« mes nyjave tĂ« klasterit dhe qendrave tĂ« tĂ« dhĂ«nave.
Seancat e pĂ«rdoruesve â pĂ«rdoren pĂ«r ruajtjen e tĂ« dhĂ«nave mbi seancat e pĂ«rdoruesve, qĂ« janĂ« tĂ« vlefshme gjatĂ« seancĂ«s sĂ« shfletuesit tĂ« pĂ«rdoruesit. Cache duhet tĂ« pĂ«rpunojĂ« kĂ«rkesat HTTP nga pĂ«rdoruesit pĂ«rfundimtarĂ« dhe aplikacioni.
Mbrojtja nga forcat e kĂ«qija â pĂ«rdoret pĂ«r tĂ« ndjekur tĂ« dhĂ«nat mbi hyrjet e dĂ«shtuara.
Balancimi i ngarkesës
Balancuesi i ngarkesës është pika e vetme e hyrjes në keycloak dhe duhet të mbajnë seanca të ngjitur.
Serverët e aplikacioneve
Përdoren për të kontrolluar ndërveprimin e komponentëve me njëri-tjetrin dhe mund të jenë të virtualizuar ose të kontejnerizuar duke përdorur mjetet ekzistuese të automatizimit dhe shkallëzimit dinamik të infrastrukturës. Skenarët më të zakonshëm të implementimit 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 identifikimi dhe shembuj tĂ« konfigurimeve.
Burimi: habr.com
