Në çdo kompani të madhe, dhe X5 Retail Group nuk bën përjashtim, ndërsa zhvillohet, numri i projekteve që kërkojnë autorizimin e përdoruesit rritet. Me kalimin e kohës, kërkohet një kalim pa probleme e përdoruesve nga një aplikacion në tjetrin dhe më pas lind nevoja për të përdorur një server të vetëm Single-Sing-On (SSO). Por po kur ofruesit e identitetit si AD ose të tjerë që nuk kanë atribute shtesë përdoren tashmë në projekte të ndryshme. Një klasë sistemesh të quajtura "ndërmjetës identifikimi" do të vijnë në shpëtim. Më funksionalët janë përfaqësuesit e tij, të tillë si Keycloak, Gravitee Access Management, etj. Më shpesh, rastet e përdorimit mund të jenë të ndryshme: ndërveprimi i makinës, pjesëmarrja e përdoruesit, etj. Zgjidhja duhet të mbështesë funksionalitet fleksibël dhe të shkallëzuar që mund të kombinojë të gjitha kërkesat në një. dhe zgjidhje të tilla kompania jonë tani ka një ndërmjetës tregues - Keycloak.
Keycloak është një produkt me burim të hapur identiteti dhe kontrolli të aksesit i mirëmbajtur nga RedHat. Është baza për produktet e kompanisë duke përdorur SSO - RH-SSO.
Konceptet themelore
Para se të filloni të merreni me zgjidhjet dhe qasjet, duhet të vendosni për termat dhe sekuencën e proceseve:
identifikim është një procedurë për njohjen e një subjekti nga identifikuesi i tij (me fjalë të tjera, ky është përkufizimi i një emri, hyrje ose numri).
vërtetim - kjo është një procedurë vërtetimi (përdoruesi kontrollohet me një fjalëkalim, letra kontrollohet me një nënshkrim elektronik, etj.)
Autorizim - kjo është sigurimi i qasjes në një burim (për shembull, në e-mail).
Broker Identiteti Keycloak
mantel çelësi është një zgjidhje e menaxhimit të identitetit dhe aksesit me burim të hapur, e krijuar për t'u përdorur në IS ku mund të përdoren modelet e arkitekturës së mikroshërbimeve.
Keycloak ofron veçori të tilla si identifikimi i vetëm (SSO), identiteti i ndërmjetësuar dhe identifikimi social, federata e përdoruesve, përshtatësit e klientit, konsola e administratorit dhe konsola e menaxhimit të llogarisë.
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.
- Ndërmjetësimi i identitetit - vërtetimi duke përdorur ofrues të jashtëm të OpenID Connect ose SAML.
- Login Social – mbështetje për Google, GitHub, Facebook, Twitter për identifikimin e përdoruesit.
- Federata e përdoruesve - sinkronizimi i përdoruesve nga serverët LDAP dhe Active Directory dhe ofruesit e tjerë të identitetit.
- Ura Kerberos – përdorimi i një serveri Kerberos për vërtetimin automatik të përdoruesit.
- Paneli i administratorit - për menaxhimin e unifikuar të cilësimeve dhe opsioneve të zgjidhjeve përmes Uebit.
- Konsola e Menaxhimit të Llogarisë - për vetë-menaxhimin e profilit të përdoruesit.
- Përshtatja e zgjidhjes bazuar në identitetin korporativ të kompanisë.
- 2FA Authentication - Mbështetje TOTP/HOTP duke përdorur Google Authenticator ose FreeOTP.
- Rrjedhat e hyrjes - vetë-regjistrimi i përdoruesit, rikuperimi dhe rivendosja e fjalëkalimit dhe të tjera janë të mundshme.
- Menaxhimi i sesioneve - administratorët mund të menaxhojnë seancat e përdoruesve nga një pikë e vetme.
- Hartuesit e Tokenit – lidhja e atributeve të përdoruesit, roleve dhe atributeve të tjera të kërkuara në token.
- Menaxhim fleksibël i politikave në të gjithë fushën, aplikacionin dhe përdoruesit.
- Mbështetja CORS - Përshtatësit e klientëve kanë mbështetje të integruar CORS.
- Ndërfaqet e ofruesve të shërbimeve (SPI) – një numër i madh SPI që ju lejojnë të konfiguroni aspekte të ndryshme të serverit: flukset e vërtetimit, ofruesit e identitetit, hartëzimi i protokollit dhe shumë më tepër.
- Përshtatësit e klientit për aplikacionet JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Mbështetje për të punuar me aplikacione të ndryshme që mbështesin bibliotekën OpenID Connect Relying Party ose SAML 2.0 Service Provider Library.
- Zgjerohet duke përdorur shtojca.
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ë mënyrë elektronike:
REST API
Java API
Ofruesit e identitetit të ndërmarrjes (On-Premise)
Aftësia për të vërtetuar përdoruesit përmes shërbimeve të Federatës së Përdoruesve.
Mund të përdoret gjithashtu vërtetimi i kalimit - nëse përdoruesit vërtetojnë në stacionet e punës me Kerberos (LDAP ose AD), atëherë ata mund të vërtetohen automatikisht në Keycloak pa pasur nevojë të fusin përsëri emrin e përdoruesit dhe fjalëkalimin e tyre.
Për vërtetimin dhe autorizimin e mëtejshëm të përdoruesve, është e mundur të përdoret një DBMS relacionale, e cila është më e zbatueshme për mjediset e zhvillimit, pasi nuk përfshin cilësime dhe integrime të gjata në fazat e hershme të projekteve. Si parazgjedhje, Keycloak përdor një DBMS të integruar për të ruajtur cilësimet dhe të dhënat e përdoruesit.
Lista e DBMS-ve të mbështetura është e gjerë dhe përfshin: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle dhe të tjerë. Më të testuarat deri më tani janë Oracle 12C Release1 RAC dhe Galera 3.12 cluster për MariaDB 10.1.19.
Ofruesit e identitetit - login social
Është e mundur të përdorni një hyrje nga rrjetet sociale. Për të aktivizuar aftësinë për të vërtetuar përdoruesit, përdorni tastierën e administratorit Keycloack. Ndryshimet në kodin e aplikacionit nuk kërkohen dhe ky funksion është i disponueshëm jashtë kutisë dhe mund të aktivizohet në çdo fazë të projektit.
Është e mundur të përdoren ofruesit e Identitetit OpenID/SAML për vërtetimin e përdoruesit.
Skenarët tipikë të autorizimit duke përdorur OAuth2 në Keycloak
Rrjedha e Kodit të Autorizimit - përdoret me aplikacione nga ana e serverit. Një nga llojet më të zakonshme të lejeve të autorizimit, sepse është i përshtatshëm për aplikacionet e serverëve ku kodi burimor i aplikacionit dhe të dhënat e klientit nuk janë të disponueshme për të huajt. Procesi në këtë rast bazohet në ridrejtim. Aplikacioni duhet të jetë në gjendje të ndërveprojë me një agjent përdoruesi (përdorues-agjent), si p.sh. një shfletues uebi - për të marrë kodet e autorizimit API të ridrejtuar përmes agjentit të përdoruesit.
rrjedha e nënkuptuar - përdoret nga aplikacione celulare ose ueb (aplikacione që funksionojnë në pajisjen e përdoruesit).
Lloji i nënkuptuar i lejes së autorizimit përdoret nga aplikacionet celulare dhe ueb ku nuk mund të garantohet konfidencialiteti i klientit. Lloji i lejes së nënkuptuar përdor gjithashtu ridrejtimin e agjentit të përdoruesit, ku tokeni i aksesit i kalohet agjentit të përdoruesit për përdorim të mëtejshëm në aplikacion. Kjo e bën tokenin në dispozicion të përdoruesit dhe aplikacioneve të tjera në pajisjen e përdoruesit. Ky lloj leje autorizimi nuk vërteton identitetin e aplikacionit dhe vetë procesi mbështetet në një URL ridrejtuese (e regjistruar më parë në shërbim).
Rrjedha e nënkuptuar nuk mbështet argumentet e rifreskimit të shenjave të qasjes.
Fluksi i Grantit të Kredencialeve të Klientit — përdoren kur aplikacioni akseson API-në. Ky lloj leje autorizimi përdoret zakonisht për ndërveprimet server-me-server që duhet të kryhen në sfond pa ndërveprim të menjëhershëm të përdoruesit. Rrjedha e grantit të kredencialeve të klientit lejon një shërbim ueb (klient konfidencial) të përdorë kredencialet e veta në vend që të imitojë një përdorues për të vërtetuar kur telefonon një shërbim tjetër ueb. Për një nivel më të lartë sigurie, është e mundur që shërbimi telefonues të përdorë një certifikatë (në vend të një sekreti të përbashkët) si kredencial.
Specifikimi OAuth2 përshkruhet në
Token JWT dhe përfitimet e tij
JWT (JSON Web Token) është një standard i hapur () që përcakton një mënyrë kompakte dhe të pavarur për të transferuar në mënyrë të sigurt informacionin midis palëve si një objekt JSON.
Sipas standardit, një shenjë përbëhet nga tre pjesë në formatin bazë-64, të ndara me pika. Pjesa e parë quhet header, e cila përmban llojin e tokenit dhe emrin e algoritmit hash për marrjen e nënshkrimit dixhital. Pjesa e dytë ruan informacionin bazë (përdoruesin, atributet, etj.). Pjesa e tretë është nënshkrimi dixhital.
. .
Asnjëherë mos ruani një shenjë në DB-në tuaj. Për shkak se një shenjë e vlefshme është ekuivalente me një fjalëkalim, ruajtja e tokenit është si ruajtja e fjalëkalimit në tekst të qartë.
Shenja e hyrjes është një shenjë që i jep pronarit të saj akses në burimet e sigurta të serverit. Zakonisht ka një jetëgjatësi të shkurtër dhe mund të ketë informacion shtesë si adresa IP e palës që kërkon token.
Rifresko token është një shenjë që lejon klientët të kërkojnë shenja të reja aksesi pasi të ketë skaduar jeta e tyre. Këto shenja zakonisht lëshohen për një periudhë të gjatë kohore.
Përparësitë kryesore të përdorimit në arkitekturën e mikroshërbimeve:
- Aftësia për të hyrë në aplikacione dhe shërbime të ndryshme përmes vërtetimit një herë.
- Në mungesë të një numri atributesh të kërkuara në profilin e përdoruesit, është e mundur të pasurohen me të dhëna që mund të shtohen në ngarkesë, duke përfshirë të automatizuar dhe në fluturim.
- Nuk ka nevojë të ruani informacione për seancat aktive, aplikacioni i serverit duhet vetëm të verifikojë nënshkrimin.
- Kontroll më fleksibël i aksesit përmes atributeve shtesë në ngarkesë.
- Përdorimi i një nënshkrimi simbolik për kokën dhe ngarkesën rrit sigurinë e zgjidhjes në tërësi.
Token JWT - përbërje
Titulli - si parazgjedhje, kreu përmban vetëm llojin e tokenit dhe algoritmin e përdorur për enkriptim.
Lloji i tokenit ruhet në tastin "typ". Çelësi 'lloj' shpërfillet 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ë Token Ueb JSON.
Çelësi i dytë "alg" përcakton algoritmin e përdorur për të enkriptuar tokenin. Duhet të vendoset në HS256 si parazgjedhje. Koka është e koduar në bazën64.
{ "alg": "HS256", "type": "JWT"}
Ngarkesa (përmbajtja) - ngarkesa ruan çdo informacion që duhet të kontrollohet. Çdo çelës në ngarkesë njihet si "kërkesë". Për shembull, ju mund të hyni në aplikacion vetëm me ftesë (promo e mbyllur). Kur duam të ftojmë dikë të marrë pjesë, i dërgojmë një letër ftese. Është e rëndësishme të kontrolloni që adresa e emailit i përket personit që pranon ftesën, kështu që ne do ta përfshijmë këtë adresë në ngarkesë, për këtë e ruajmë në çelësin "email".
{ "email": "[email mbrojtur]"}
Çelësat në ngarkesë mund të jenë arbitrare. Megjithatë, ka disa të rezervuara:
- iss (Issuer) - Identifikon aplikacionin nga i cili po dërgohet token.
- sub (Subject) - përcakton subjektin e shenjës.
- aud (Audienca) është një grup vargjesh ose URI të ndjeshme ndaj rastit, që është një listë e marrësve të këtij tokeni. Kur pala marrëse merr një JWT me çelësin e dhënë, ajo duhet të kontrollojë praninë e vetvetes në marrës - përndryshe injoroni tokenin.
- exp (Koha e skadimit) - Tregon kur skadon token. Standardi JWT kërkon që të gjitha zbatimet të refuzojnë shenjat e skaduara. Çelësi exp duhet të jetë një vulë kohore në formatin unix.
- nbf (Jo më parë) është një kohë në formatin unix që përcakton momentin kur token bëhet i vlefshëm.
- iat (Issued At) - Ky çelës përfaqëson kohën kur u lëshua token dhe mund të përdoret për të përcaktuar moshën e JWT. Çelësi iat duhet të jetë një vulë kohore në formatin unix.
- Jti (JWT ID) - një varg që përcakton identifikuesin unik të këtij tokeni, i ndjeshëm ndaj shkronjave të vogla.
Është e rëndësishme të kuptohet se ngarkesa nuk transmetohet në formë të koduar (megjithëse argumentet mund të futen në fole dhe më pas është e mundur të transmetohen të dhëna të koduara). Prandaj, nuk mund të ruajë asnjë informacion sekret. Ashtu si titulli, ngarkesa e dobishme është e koduar në bazë64.
Nënshkrim - kur kemi një titull dhe ngarkesë, ne mund të llogarisim nënshkrimin.
Base64-encoded: header dhe payload merren, ato kombinohen në një varg përmes një pike. Pastaj ky varg dhe çelësi sekret futen në algoritmin e enkriptimit të specifikuar në kokë (çelësi "alg"). Çelësi mund të jetë çdo varg. Vargjet më të gjata do të jenë më të preferuara pasi do të duhet më shumë kohë për t'u marrë.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Ndërtimi i një arkitekture të grupit të dështimit të çelësave
Kur përdorni një grup të vetëm për të gjitha projektet, ka kërkesa të shtuara për një zgjidhje SSO. Kur numri i projekteve është i vogël, këto kërkesa nuk janë aq të dukshme për të gjitha projektet, megjithatë, me një rritje të numrit të përdoruesve dhe integrimeve, kërkesat për disponueshmëri dhe performancë rriten.
Rritja e rrezikut të dështimit të vetëm SSO rrit kërkesat për arkitekturën e zgjidhjes dhe metodat e përdorura për komponentët e tepërt dhe çon në një SLA shumë të ngushtë. Në këtë drejtim, më shpesh gjatë zhvillimit ose fazave të hershme të zbatimit të zgjidhjeve, projektet kanë infrastrukturën e tyre jo-toleruese ndaj gabimeve. Ndërsa zhvillimi përparon, kërkohet të përcaktohen mundësitë për zhvillim dhe shkallëzim. Është më fleksibël të ndërtosh një grup të dështimit duke përdorur virtualizimin e kontejnerëve ose një qasje hibride.
Për të punuar në modalitetet e grupimit Active/Active dhe Active/Passive, kërkohet të sigurohet konsistenca e të dhënave në një bazë të dhënash relacionale - të dy nyjet e bazës së të dhënave duhet të riprodhohen në mënyrë sinkronike midis qendrave të ndryshme të të dhënave të shpërndara gjeografike.
Shembulli më i thjeshtë i një instalimi tolerant ndaj gabimeve.
Cilat janë përfitimet e përdorimit të një grupi të vetëm:
- Disponueshmëri dhe performancë e lartë.
- Mbështetje për mënyrat e funksionimit: Aktive / Aktive, Aktive / Pasive.
- Aftësia për të shkallëzuar në mënyrë dinamike - kur përdorni virtualizimin e kontejnerëve.
- Mundësia e menaxhimit dhe monitorimit të centralizuar.
- Qasje e unifikuar për identifikimin/autentifikimin/autorizimin e përdoruesve në projekte.
- Ndërveprim më transparent ndërmjet projekteve të ndryshme pa përfshirjen e përdoruesve.
- Aftësia për të ripërdorur tokenin JWT në projekte të ndryshme.
- Pika e vetme e besimit.
- Nisja më e shpejtë e projekteve duke përdorur mikroshërbime/virtualizimin e kontejnerëve (nuk ka nevojë të ngrini dhe konfiguroni komponentë shtesë).
- Është e mundur të blini mbështetje tregtare nga shitësi.
Çfarë duhet të kërkoni kur planifikoni një grup
DBMS
Keycloak përdor një sistem të menaxhimit të bazës së të dhënave për të ruajtur: sferat, klientët, përdoruesit, etj.
Mbështetet një gamë e gjerë DBMS: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak vjen me bazën e vet të integruar relacionale. Rekomandohet të përdoret për mjedise pa ngarkesë - siç janë mjediset e zhvillimit.
Për të punuar në modalitetet e grupimit Active/Active dhe Active/Passive, kërkohet konsistenca e të dhënave në një bazë të dhënash relacionale dhe të dy nyjet e grupimit të bazës së të dhënave riprodhohen në mënyrë sinkronike midis qendrave të të dhënave.
Cache e shpërndarë (Infinspan)
Që grupi të funksionojë siç duhet, kërkohet sinkronizim shtesë i llojeve të mëposhtme të cache-ve duke përdorur rrjetin e të dhënave JBoss:
Sesionet e vërtetimit - përdoren për të ruajtur të dhënat kur vërtetoni një përdorues specifik. Kërkesat nga ky cache zakonisht përfshijnë vetëm shfletuesin dhe serverin Keycloak, jo aplikacionin.
Shenjat e veprimit përdoren për skenarë ku përdoruesi duhet të konfirmojë një veprim në mënyrë asinkrone (me email). Për shembull, gjatë rrjedhës së harrimit të fjalëkalimit, memoria e fshehtë e actionTokens Infinispan përdoret për të mbajtur gjurmët e meta të dhënave në lidhje me tokenat e veprimeve të lidhura që janë përdorur tashmë, kështu që nuk mund të ripërdoret.
Caching dhe pavlefshmëri e të dhënave të vazhdueshme - përdoret për të memorizuar të dhënat e vazhdueshme për të shmangur pyetjet e panevojshme në bazën e të dhënave. Kur çdo 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 të.
Puna - Përdoret vetëm për të dërguar mesazhe të pavlefshme midis nyjeve të grupimit dhe qendrave të të dhënave.
Sesionet e përdoruesit - përdoren për të ruajtur të dhënat në lidhje me sesionet e përdoruesit që janë të vlefshme për kohëzgjatjen e sesionit të shfletuesit të përdoruesit. Cache duhet të përpunojë kërkesat HTTP nga përdoruesi përfundimtar dhe aplikacioni.
Mbrojtja nga forca brutale - përdoret për të gjurmuar të dhënat rreth hyrjeve të dështuara.
Balancimi i ngarkesës
Balancuesi i ngarkesës është pika e vetme hyrëse në tastierën dhe duhet të mbështesë sesionet ngjitëse.
Serverët e aplikacionit
Ato përdoren për të kontrolluar ndërveprimin e komponentëve me njëri-tjetrin dhe mund të virtualizohen ose kontejnerizohen duke përdorur mjetet ekzistuese të automatizimit dhe shkallëzimin dinamik të mjeteve të automatizimit të infrastrukturës. Skenarët më të zakonshëm të vendosjes në OpenShift, Kubernates, Rancher.
Kështu përfundon pjesa e parë - ajo teorike. Në serinë e mëposhtme të artikujve, do të diskutohen shembuj të integrimeve me ofrues të ndryshëm identifikimi dhe shembuj të cilësimeve.
Burimi: www.habr.com