Edozein enpresa handitan, eta X5 Retail Group ez da salbuespena, garatzen doan heinean, erabiltzaileen baimena behar duten proiektuen kopurua handitzen da. Denboraren poderioz, erabiltzaileen aplikazio batetik bestera igarotzea beharrezkoa da, eta, ondoren, Single-Sing-On (SSO) zerbitzari bakarra erabili beharra dago. Baina zer gertatzen da AD bezalako identitate-hornitzaileak edo atributu gehigarririk ez duten beste hainbat proiektutan dagoeneko erabiltzen direnean. "Identifikazio-artekariak" izeneko sistema mota bat etorriko da erreskatatzera. Funtzionalenak bere ordezkariak dira, hala nola Keycloak, Gravitee Access kudeaketa... Gehienetan, erabilera-kasuak desberdinak izan daitezke: makinen interakzioa, erabiltzaileen parte-hartzea, etab. Irtenbideak funtzionalitate malgu eta eskalagarriak onartu behar ditu, eskakizun guztiak bakarrean konbina ditzaketenak. eta horrelako irtenbideak gure enpresak orain adierazle-artekari bat du - Keycloak.
Keycloak RedHat-ek mantentzen duen kode irekiko identitate eta sarbidea kontrolatzeko produktua da. SSO - RH-SSO erabiliz konpainiaren produktuen oinarria da.
Oinarrizko kontzeptuak
Irtenbideak eta planteamenduak jorratzen hasi aurretik, prozesuen terminoak eta sekuentziak erabaki behar dituzu:
identifikazio subjektu bat bere identifikatzailearen bidez ezagutzeko prozedura bat da (hau da, izen, login edo zenbaki baten definizioa da).
autentifikazio - autentifikazio prozedura bat da (erabiltzailea pasahitz batekin egiaztatzen da, gutuna sinadura elektronikoarekin egiaztatzen da, etab.)
baimen - Baliabide baterako sarbidea ematea da (adibidez, posta elektronikora).
Identity Broker Keycloak
giltza kapaia IS-n erabiltzeko diseinatutako kode irekiko identitatea eta sarbidea kudeatzeko irtenbide bat da, non mikrozerbitzuen arkitektura ereduak erabil daitezkeen.
Keycloak-ek funtzioak eskaintzen ditu, hala nola, saioa hasteko (SSO), nortasun bitartekatua eta saio-hasiera soziala, erabiltzaileen federazioa, bezero-egokitzaileak, administrazio-kontsola eta kontuak kudeatzeko kontsola.
Keycloak-ek onartzen duen oinarrizko funtzionaltasuna:
- Saio-hasi bakarra eta saioa amaitzea arakatzaileko aplikazioetarako.
- OpenID/OAuth 2.0/SAMLrako laguntza.
- Identity Brokering - autentifikazioa kanpoko OpenID Connect edo SAML identitate hornitzaileen bidez.
- Saio-hasiera soziala - Google, GitHub, Facebook, Twitter laguntza erabiltzailea identifikatzeko.
- Erabiltzaileen federazioa - LDAP eta Active Directory zerbitzarietako eta beste identitate hornitzaileetako erabiltzaileen sinkronizazioa.
- Kerberos zubia - Kerberos zerbitzari bat erabiliz erabiltzaileen autentifikazio automatikoa egiteko.
- Admin kontsola - ezarpenen eta irtenbide-aukeren kudeaketa bateratu baterako Web bidez.
- Kontuak kudeatzeko kontsola - erabiltzailearen profila autokudeatzeko.
- Irtenbidearen pertsonalizazioa enpresaren identitate korporatiboan oinarrituta.
- 2FA autentifikazioa - TOTP/HOTP laguntza Google Authenticator edo FreeOTP erabiliz.
- Saioa hasteko fluxuak - erabiltzaileen auto-erregistroa, pasahitza berreskuratzea eta berrezartzea, eta beste batzuk posible dira.
- Saioen kudeaketa - administratzaileek erabiltzaileen saioak kudeatu ditzakete puntu bakar batetik.
- Token Mappers - tokenei erabiltzaileen atributuak, rolak eta beharrezko beste atributu batzuk lotzea.
- Politika-kudeaketa malgua eremuan, aplikazioetan eta erabiltzaileetan.
- CORS euskarria - Bezeroaren egokigailuek CORS euskarria dute.
- Zerbitzu Hornitzaileen Interfazeak (SPI) - Zerbitzariaren hainbat alderdi pertsonalizatzeko aukera ematen duten SPI kopuru handi bat: autentifikazio-fluxuak, identitate-hornitzaileak, protokoloen mapaketa eta abar.
- JavaScript aplikazioetarako bezero-egokitzaileak, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- OpenID Connect Relying Party liburutegia edo SAML 2.0 Zerbitzu Hornitzailearen Liburutegia onartzen duten hainbat aplikaziorekin lan egiteko laguntza.
- Pluginak erabiliz zabal daiteke.
CI / CD prozesuetarako, baita Keycloak-en kudeaketa prozesuen automatizaziorako, REST API / JAVA APIa erabil daiteke. Dokumentazioa elektronikoki eskuragarri dago:
REST API
Java APIa
Enpresa-identitate-hornitzaileak (On-premise)
Erabiltzaileak autentifikatzeko gaitasuna Erabiltzaileen Federazioaren zerbitzuen bidez.
Pass-through autentifikazioa ere erabil daiteke - erabiltzaileek Kerberos (LDAP edo AD) duten lan-estazioen aurka autentifikatzen badute, orduan automatikoki autentifikatu ahal izango dira Keycloak-en, erabiltzaile-izena eta pasahitza berriro sartu beharrik gabe.
Erabiltzaileen autentifikaziorako eta baimen gehiagorako, DBMS erlazional bat erabil daiteke, garapen-inguruneetarako aplikagarriena dena, proiektuen hasierako faseetan ezarpen eta integrazio luzerik suposatzen ez baitu. Lehenespenez, Keycloak-ek DBMS integratua erabiltzen du ezarpenak eta erabiltzailearen datuak gordetzeko.
Onartutako DBMS zerrenda zabala da eta honako hauek ditu: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle eta beste batzuk. Orain arte probatuenak Oracle 12C Release1 RAC eta Galera 3.12 clusterra MariaDB 10.1.19rako dira.
Identitate-hornitzaileak - saio-hasiera soziala
Sare sozialetatik saioa hasteko aukera dago. Erabiltzaileak autentifikatzeko gaitasuna aktibatzeko, erabili Keycloack administrazio kontsola. Aplikazio-kodean aldaketak ez dira beharrezkoak eta funtzionalitate hau kutxatik kanpo dago eta proiektuaren edozein fasetan aktiba daiteke.
Erabiltzaileen autentifikaziorako OpenID/SAML Identity hornitzaileak erabil daitezke.
Keycloak-en OAuth2 erabiliz baimentzeko eszenatoki tipikoak
Baimen Kodearen Fluxua - zerbitzariaren aldeko aplikazioekin erabiltzen da. Baimen-baimen mota ohikoenetako bat zerbitzari-aplikazioetarako oso egokia delako, non aplikazioaren iturburu-kodea eta bezeroaren datuak kanpokoentzat eskuragarri ez dauden. Kasu honetan prozesua birbideratzean oinarritzen da. Aplikazioak erabiltzaile-agente batekin (erabiltzaile-agentearekin) komunikatzeko gai izan behar du, hala nola web-arakatzaile batekin, erabiltzaile-agentearen bidez birbideratzen diren API baimen-kodeak jasotzeko.
fluxu inplizitua - Mugikorreko edo web aplikazioek erabiltzen dute (erabiltzailearen gailuan exekutatzen diren aplikazioak).
Baimen inplizitua baimen-mota mugikorretarako eta web-aplikazioek erabiltzen dute, non bezeroen konfidentzialtasuna bermatu ezin den. Baimen inplizitu motak erabiltzaile-agentearen birbideratzea ere erabiltzen du, eta, horren bidez, sarbide-tokena erabiltzaile-agenteari pasatzen zaio aplikazioan gehiago erabiltzeko. Horrek tokena erabilgarri jartzen du erabiltzailearen eta erabiltzailearen gailuko beste aplikazio batzuentzat. Baimen-baimen mota honek ez du aplikazioaren benetakotasuna egiaztatzen, eta prozesua bera birbideratzeko URL batean oinarritzen da (aurretik zerbitzuan erregistratua).
Implicit Flow-ek ez ditu sarbide-tokenak freskatzeko tokenak onartzen.
Bezeroaren kredentzialak emandako fluxua β Aplikazioa APIra sartzen denean erabiltzen dira. Baimen-baimen mota hau normalean zerbitzaritik zerbitzariko elkarreraginetarako erabiltzen da, atzeko planoan egin behar diren erabiltzaileak berehalako interakziorik gabe. Bezeroaren kredentzialak emateko fluxuak web-zerbitzu bati (bezero konfidentziala) bere kredentzialak erabiltzeko aukera ematen dio, beste web-zerbitzu bati deitzen dionean erabiltzaile bat autentifikatu ordez. Segurtasun maila handiagoa lortzeko, baliteke dei-zerbitzuak ziurtagiri bat erabiltzea (partekatutako sekretu baten ordez) kredentzial gisa.
OAuth2 zehaztapena atalean deskribatzen da
JWT tokena eta bere onurak
JWT (JSON Web Token) estandar irekia da () alderdien arteko informazioa JSON objektu gisa modu seguruan transferitzeko modu trinko eta autonomoa definitzen duena.
Estandarraren arabera, tokenak hiru zati ditu oinarri-64 formatuan, puntuz bereizita. Lehenengo zatiari goiburua deitzen zaio, eta sinadura digitala lortzeko token mota eta hash algoritmoaren izena jasotzen ditu. Bigarren zatian oinarrizko informazioa gordetzen da (erabiltzailea, atributuak, etab.). Hirugarren zatia sinadura digitala da.
. .
Inoiz ez gorde token bat zure DBan. Baliozko token bat pasahitz baten baliokidea denez, tokena gordetzea pasahitza testu garbian gordetzea bezalakoa da.
Sarbide-tokena bere jabeari zerbitzari baliabide seguruetarako sarbidea ematen dion token bat da. Normalean bizitza laburra izaten du eta informazio gehigarria izan dezake, hala nola tokena eskatzen duen alderdiaren IP helbidea.
Freskatu tokena token bat da, bezeroei sarbide-token berriak eskatzeko aukera ematen dien bizitza iraungi ondoren. Token hauek normalean denbora luzez jaulkitzen dira.
Mikrozerbitzuen arkitekturan erabiltzearen abantaila nagusiak:
- Hainbat aplikazio eta zerbitzuetara sartzeko gaitasuna aldi bakarreko autentifikazioaren bidez.
- Erabiltzaile-profilean beharrezkoak diren atributu batzuk ez badira, kargari gehi daitezkeen datuekin aberastu daiteke, automatizatuak eta berehalakoak barne.
- Ez dago saio aktiboei buruzko informazioa gorde beharrik, zerbitzariaren aplikazioak sinadura egiaztatu besterik ez du egin behar.
- Sarbide-kontrol malguagoa kargaren atributu gehigarrien bidez.
- Goibururako eta kargarako token sinadura erabiltzeak soluzio osoaren segurtasuna areagotzen du.
JWT token - konposizioa
Izenburua - lehenespenez, goiburuak enkriptatzeko erabilitako token mota eta algoritmoa baino ez ditu.
Token mota "typ" teklan gordetzen da. "Mota" gakoa ez da aintzat hartzen JWTn. "Typ" gakoa badago, bere balioa JWT izan behar du objektu hau JSON Web Token bat dela adierazteko.
"alg" bigarren gakoak tokena enkriptatzeko erabiltzen den algoritmoa definitzen du. Lehenespenez HS256 ezarri behar da. Goiburua base64-n kodetuta dago.
{ "alg": "HS256", "type": "JWT"}
karga erabilgarria (edukia) - kargak egiaztatu beharreko informazioa gordetzen du. Kargako gako bakoitza "erreklamazio" gisa ezagutzen da. Adibidez, aplikaziora gonbidapenez soilik sar dezakezu (promozio itxia). Norbait parte hartzera gonbidatu nahi dugunean, gonbidapen gutuna bidaltzen diogu. Garrantzitsua da helbide elektronikoa gonbidapena onartzen duenarena dela egiaztatzea, beraz, helbide hau karga-kargan sartuko dugu, horretarako "email" gakoan gordetzen dugu.
{ "email": "[posta elektroniko bidez babestua]"}
Garbiko gakoak arbitrarioak izan daitezke. Hala ere, erreserbatutako batzuk daude:
- iss (Igorlea) - Tokena bidaltzen den aplikazioa identifikatzen du.
- sub (Subject) - tokenaren gaia definitzen du.
- aud (Audience) maiuskulak eta minuskulak bereizten dituen kate edo URI multzo bat da, token honen hartzaileen zerrenda dena. Alde hartzaileak emandako gakoarekin JWT bat jasotzen duenean, hartzaileek bere burua dagoen egiaztatu behar du - bestela, tokena baztertu.
- exp (Expiration Time) - Tokena noiz iraungitzen den adierazten du. JWT estandarrak bere inplementazio guztiak iraungitako tokenak baztertzeko eskatzen du. Exp gakoak denbora-zigilu bat izan behar du unix formatuan.
- nbf (Not Before) tokena baliozkoa den unea zehazten duen unix formatuan dagoen denbora da.
- iat (Issued at) - Gako honek tokena jaulki zeneko denbora adierazten du eta JWT-aren adina zehazteko erabil daiteke. iat gakoak denbora-zigilu bat izan behar du unix formatuan.
- Jti (JWT ID) - token honen identifikatzaile bakarra definitzen duen katea, maiuskulak eta minuskulak bereizten ditu.
Garrantzitsua da ulertzea karga karga ez dela enkriptatutako forman transmititzen (nahiz eta tokenak habiaratu daitezkeen eta gero enkriptatutako datuak transmititzea posible den). Beraz, ezin du informazio sekreturik gorde. Goiburua bezala, karga base64 kodetuta dago.
sinadura - titulua eta karga dugunean, sinadura kalkulatu dezakegu.
Base64 kodetuta: goiburua eta karga hartzen dira, puntu baten bidez kate batean konbinatzen dira. Ondoren, kate hau eta gako sekretua goiburuan zehaztutako enkriptazio-algoritmoan sartzen dira ("alg" gakoa). Gakoa edozein kate izan daiteke. Soka luzeagoak hobetsiko dira jasotzeko denbora gehiago beharko baitute.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Keycloak Failover Cluster Arkitektura eraikitzea
Proiektu guztietarako kluster bakarra erabiltzean, SSO irtenbide baterako eskakizunak areagotu egiten dira. Proiektuen kopurua txikia denean, eskakizun horiek ez dira hain nabariak proiektu guztietan, hala ere, erabiltzaile eta integrazio kopurua handituz gero, erabilgarritasun eta errendimendurako baldintzak areagotzen dira.
SSO bakarraren hutsegite arriskua areagotzeak soluzio-arkitekturaren eta osagai erredundanteetarako erabiltzen diren metodoen eskakizunak areagotzen ditu eta SLA oso estua dakar. Ildo horretatik, konponbideak garatzeko edo ezartzeko hasierako faseetan sarriago, proiektuek akatsekiko tolerantziarik gabeko azpiegitura dute. Garapenak aurrera egin ahala, garapenerako eta eskalatzeko aukerak ezarri behar dira. Malguena da hutsegite-kluster bat eraikitzea edukiontzien birtualizazioa edo ikuspegi hibridoa erabiliz.
Aktibo/aktibo eta aktibo/pasibo kluster moduetan lan egiteko, datu-base erlazional batean datu-koherentzia bermatu behar da; datu-baseko bi nodoak modu sinkronikoan errepikatu behar dira geo-banatutako datu-zentro desberdinen artean.
Akatsak toleranteak diren instalazio baten adibiderik errazena.
Zeintzuk dira kluster bakarra erabiltzearen onurak:
- Eskuragarritasun eta errendimendu handia.
- Funtzionamendu moduetarako laguntza: Aktiboa / Aktiboa, Aktiboa / Pasiboa.
- Edukiontzien birtualizazioa erabiltzean dinamikoki eskalatzeko gaitasuna.
- Kudeaketa eta jarraipen zentralizatua egiteko aukera.
- Proiektuetako erabiltzaileen identifikazio/autentifikazio/baimenaren ikuspegi bateratua.
- Proiektu ezberdinen arteko interakzio gardenagoa erabiltzaileen inplikaziorik gabe.
- JWT tokena hainbat proiektutan berrerabiltzeko gaitasuna.
- Konfiantza puntu bakarra.
- Proiektuak abiarazte azkarrago mikrozerbitzuak/edukiontzien birtualizazioa erabiliz (ez da osagai osagarriak altxatu eta konfiguratu beharrik).
- Saltzaileak laguntza komertziala erosteko aukera dago.
Zer bilatu Cluster bat planifikatzerakoan
DBMS
Keycloak-ek datu-baseak kudeatzeko sistema erabiltzen du gordetzeko: erreinuak, bezeroak, erabiltzaileak, etab.
DBMS sorta zabala onartzen da: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak-ek bere datu-base erlazionalarekin dator. Kargarik gabeko inguruneetarako erabiltzea gomendatzen da, hala nola garapen inguruneetarako.
Kluster aktibo/aktibo eta aktibo/pasibo moduetan lan egiteko, datu-base erlazional batean datu-koherentzia beharrezkoa da, eta datu-baseen kluster-nodo biak modu sinkronoan errepikatzen dira datu-zentroen artean.
Banatutako cachea (Infinspan)
Klusterrak behar bezala funtziona dezan, ondoko cache mota hauen sinkronizazio gehigarria behar da JBoss Data Grid erabiliz:
Autentifikazio saioak - erabiltzaile jakin bat autentifikatzean datuak gordetzeko erabiltzen da. Cache honetako eskaerek normalean arakatzailea eta Keycloak zerbitzaria soilik sartzen dituzte, ez aplikazioa.
Ekintza-tokenak erabiltzaileak ekintza bat modu asinkronoan baieztatu behar duen agertokietarako erabiltzen dira (posta elektroniko bidez). Adibidez, ahaztu pasahitza-fluxu batean, actionTokens Infinispan cachea erabiltzen da dagoeneko erabili diren ekintza-token elkartuei buruzko metadatuen jarraipena egiteko, beraz, ezin da berrerabili.
Datu iraunkorrak cachean gordetzea eta baliogabetzea - ββdatu iraunkorrak gordetzeko erabiltzen da, datu-baseari alferrikako kontsultak ekiditeko. Keycloak zerbitzariak datuak eguneratzen dituenean, datu-zentro guztietako Keycloak zerbitzari guztiek horren berri izan behar dute.
Lana - Kluster-nodoen eta datu-zentroen artean baliogabeko mezuak bidaltzeko bakarrik erabiltzen da.
Erabiltzaileen saioak - erabiltzailearen arakatzailearen saioak irauten duen bitartean baliozkoak diren erabiltzailearen saioei buruzko datuak gordetzeko erabiltzen da. Cacheak azken erabiltzailearen eta aplikazioaren HTTP eskaerak prozesatu behar ditu.
Indar gordinaren babesa - huts egin duten saio-hasiei buruzko datuak jarraitzeko erabiltzen da.
Karga orekatzea
Karga-orekatzailea keycloak egiteko sarrera puntu bakarra da eta saio itsaskorrak onartu behar ditu.
Aplikazio-zerbitzariak
Osagaien elkarreragina kontrolatzeko erabiltzen dira eta birtualizatu edo edukiontziratu daitezke lehendik dauden automatizazio-tresnak eta azpiegituren automatizazio-tresnen eskalatze dinamikoa erabiliz. OpenShift, Kubernates, Rancher-en inplementazio-eszenatoki ohikoenak.
Honek amaitzen du lehen zatia, teorikoa. Hurrengo artikulu-sailean, identitate-hornitzaile ezberdinekin integrazioen adibideak eta ezarpenen adibideak aztertuko dira.
Iturria: www.habr.com