Bet kurioje didelėje įmonėje ir X5 Retail Group nėra išimtis, nes jai vystantis daugėja projektų, kuriems reikalingas vartotojo leidimas. Laikui bėgant reikalingas sklandus vartotojų perėjimas iš vienos programos į kitą, o tada reikia naudoti vieną Single-Sing-On (SSO) serverį. Bet ką daryti, kai tapatybės teikėjai, tokie kaip AD ar kiti, kurie neturi papildomų atributų, jau naudojami įvairiuose projektuose. Į pagalbą ateis sistema, vadinama „identifikavimo brokeriais“. Funkcionaliausi yra jo atstovai, tokie kaip Keycloak, Gravitee Access valdymas ir kt. Dažniausiai naudojimo atvejai gali būti įvairūs: mašinos sąveika, vartotojo dalyvavimas ir tt Sprendimas turi palaikyti lanksčią ir keičiamo dydžio funkcionalumą, galintį sujungti visus reikalavimus viename, ir tokie sprendimai mūsų įmonė dabar turi indikacinį brokerį - Keycloak.
Keycloak yra atvirojo kodo tapatybės ir prieigos kontrolės produktas, kurį prižiūri RedHat. Tai yra pagrindas įmonės gaminiams naudojant SSO - RH-SSO.
Pagrindinės sąvokos
Prieš pradėdami dirbti su sprendimais ir metodais, turėtumėte nuspręsti dėl procesų terminų ir sekos:
Identifikavimas yra subjekto atpažinimo pagal jo identifikatorių (kitaip tariant, tai vardo, prisijungimo ar numerio apibrėžimas) procedūra.
Autentifikavimas - tai autentifikavimo procedūra (vartotojas tikrinamas slaptažodžiu, laiškas tikrinamas elektroniniu parašu ir pan.)
Leidimas – suteikia prieigą prie šaltinio (pavyzdžiui, el. pašto).
Identity Broker Keycloak
raktų apsiaustas yra atvirojo kodo tapatybės ir prieigos valdymo sprendimas, skirtas naudoti IS, kur galima naudoti mikro paslaugų architektūros modelius.
„Keycloak“ siūlo tokias funkcijas kaip vienkartinis prisijungimas (SSO), tarpininkaujant suteikta tapatybė ir socialinis prisijungimas, vartotojų susijungimas, klientų adapteriai, administratoriaus konsolė ir paskyros valdymo pultas.
Pagrindinės „Keycloak“ palaikomos funkcijos:
- Vienkartinis prisijungimas ir vienkartinis išjungimas naršyklės programoms.
- OpenID/OAuth 2.0/SAML palaikymas.
- Identity Brokering – autentifikavimas naudojant išorinius OpenID Connect arba SAML tapatybės teikėjus.
- Socialinis prisijungimas – „Google“, „GitHub“, „Facebook“, „Twitter“ palaikymas vartotojo identifikavimui.
- Vartotojų susijungimas – vartotojų iš LDAP ir Active Directory serverių bei kitų tapatybės teikėjų sinchronizavimas.
- Kerberos tiltas – naudojant Kerberos serverį automatiniam vartotojo autentifikavimui.
- Admin Console – skirta vieningam nustatymų ir sprendimų parinkčių valdymui žiniatinklyje.
- Paskyros valdymo pultas – skirtas savarankiškam vartotojo profilio tvarkymui.
- Sprendimo pritaikymas pagal įmonės firminį identitetą.
- 2FA autentifikavimas – TOTP/HOTP palaikymas naudojant Google Authenticator arba FreeOTP.
- Prisijungimo srautai – galima vartotojo savarankiška registracija, slaptažodžio atkūrimas ir atstatymas bei kt.
- Seansų valdymas – administratoriai gali valdyti vartotojų sesijas iš vieno taško.
- Token Mappers – vartotojo atributų, vaidmenų ir kitų būtinų atributų susiejimas su žetonais.
- Lankstus politikos valdymas įvairiose srityse, programose ir naudotojuose.
- CORS palaikymas – klientų adapteriai turi savąjį CORS palaikymą.
- Paslaugų teikėjo sąsajos (SPI) – daugybė SPI, leidžiančių konfigūruoti įvairius serverio aspektus: autentifikavimo srautus, tapatybės teikėjus, protokolų susiejimą ir daug daugiau.
- Klientų adapteriai JavaScript programoms, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Palaikymas dirbant su įvairiomis programomis, palaikančiomis „OpenID Connect Relying Party“ biblioteką arba SAML 2.0 paslaugų teikėjo biblioteką.
- Išplečiama naudojant papildinius.
CI / CD procesams, taip pat valdymo procesų automatizavimui Keycloak, galima naudoti REST API / JAVA API. Dokumentus galima gauti elektroniniu būdu:
POILSIO API
Java API
Įmonės tapatybės teikėjai (vietoje)
Galimybė autentifikuoti vartotojus naudojant vartotojų susiejimo paslaugas.
Taip pat gali būti naudojamas perduodamas autentifikavimas – jei vartotojai autentifikuojasi darbo stotyse su Kerberos (LDAP arba AD), tada jie gali būti automatiškai autentifikuoti „Keycloak“ ir nereikia dar kartą įvesti savo vartotojo vardo ir slaptažodžio.
Autentifikavimui ir tolesniam naudotojų autorizavimui galima naudoti reliacinę DBVS, kuri labiausiai tinka kūrimo aplinkoms, nes ji neapima ilgų nustatymų ir integracijų ankstyvosiose projektų stadijose. Pagal numatytuosius nustatymus „Keycloak“ naudoja integruotą DBVS, kad saugotų nustatymus ir vartotojo duomenis.
Palaikomų DBVS sąrašas yra platus ir apima: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle ir kt. Iki šiol labiausiai išbandytas „Oracle 12C Release1 RAC“ ir „Galera 3.12“ klasteris, skirtas „MariaDB 10.1.19“.
Tapatybės teikėjai – socialinis prisijungimas
Galima naudotis prisijungimu iš socialinių tinklų. Norėdami suaktyvinti galimybę autentifikuoti vartotojus, naudokite „Keycloack“ administratoriaus konsolę. Programos kodo keisti nereikia, o ši funkcija pasiekiama iš karto ir gali būti suaktyvinta bet kuriame projekto etape.
Vartotojo autentifikavimui galima naudoti OpenID/SAML tapatybės teikėjus.
Įprasti autorizacijos scenarijai naudojant OAuth2 programoje Keycloak
Autorizacijos kodo srautas - naudojamas su serverio programomis. Vienas iš labiausiai paplitusių autorizacijos leidimo tipų, nes jis puikiai tinka serverio programoms, kuriose programos šaltinio kodas ir kliento duomenys neprieinami pašaliniams asmenims. Procesas šiuo atveju pagrįstas peradresavimu. Programa turi turėti galimybę sąveikauti su vartotojo agentu (vartotojo agentu), pvz., žiniatinklio naršykle, kad gautų API autorizavimo kodus, nukreiptus per vartotojo agentą.
numanomas srautas — naudojamos mobiliosiose arba žiniatinklio programose (programos, veikiančios vartotojo įrenginyje).
Netiesioginio autorizacijos leidimo tipas naudojamas mobiliosiose ir žiniatinklio programose, kur kliento konfidencialumas negali būti garantuotas. Numanomas leidimo tipas taip pat naudoja vartotojo agento peradresavimą, kai prieigos raktas perduodamas vartotojo agentui, kad jis būtų toliau naudojamas programoje. Taip prieigos raktas bus prieinamas vartotojui ir kitoms vartotojo įrenginyje esančioms programoms. Šio tipo autorizacijos leidimas nepatvirtina programos tapatybės, o pats procesas priklauso nuo peradresavimo URL (anksčiau užregistruotu paslaugoje).
Implicit Flow nepalaiko prieigos prieigos rakto atnaujinimo prieigos raktų.
Kliento kredencialų suteikimo srautas – naudojami, kai programa pasiekia API. Šio tipo autorizacijos leidimas paprastai naudojamas serverio tarpusavio sąveikai, kuri turi būti atliekama fone be tiesioginio vartotojo sąveikos. Kliento kredencialų suteikimo srautas leidžia žiniatinklio paslaugai (konfidencialiam klientui) naudoti savo kredencialus, o ne apsimesti vartotoju, kad jis autentifikuotųsi skambinant kitai žiniatinklio tarnybai. Siekiant didesnio saugumo lygio, skambinanti tarnyba gali naudoti sertifikatą (vietoj bendros paslapties) kaip kredencialą.
OAuth2 specifikacija aprašyta
JWT tokenas ir jo privalumai
JWT (JSON Web Token) yra atviras standartas (), kuris apibrėžia kompaktišką ir savarankišką būdą saugiai perduoti informaciją tarp šalių JSON objekto forma.
Pagal standartą žetonas susideda iš trijų bazinio-64 formato dalių, atskirtų taškais. Pirmoji dalis vadinama antrašte, kurioje yra žetono tipas ir maišos algoritmo, skirto skaitmeniniam parašui gauti, pavadinimas. Antroje dalyje saugoma pagrindinė informacija (vartotojas, atributai ir kt.). Trečioji dalis – skaitmeninis parašas.
. .
Niekada nesaugokite žetono savo duomenų bazėje. Kadangi galiojantis prieigos raktas yra lygiavertis slaptažodžiui, žetono saugojimas yra tas pats, kas slaptažodžio saugojimas aiškiu tekstu.
Prieigos raktas yra prieigos raktas, suteikiantis jo savininkui prieigą prie saugių serverio išteklių. Paprastai jis galioja trumpai ir gali turėti papildomos informacijos, pvz., prieigos rakto prašančios šalies IP adresą.
Atnaujinti prieigos raktą yra prieigos raktas, leidžiantis klientams prašyti naujų prieigos žetonų pasibaigus jų galiojimo laikui. Šie žetonai paprastai išduodami ilgam laikui.
Pagrindiniai naudojimo mikro paslaugų architektūroje privalumai:
- Galimybė pasiekti įvairias programas ir paslaugas naudojant vienkartinį autentifikavimą.
- Nesant daugelio būtinų atributų vartotojo profilyje, galima praturtinti duomenimis, kuriuos galima pridėti prie naudingo krovinio, įskaitant automatizuotus ir tiesioginius.
- Nereikia saugoti informacijos apie aktyvius seansus, serverio programai tereikia patikrinti parašą.
- Lankstesnė prieigos kontrolė naudojant papildomus naudingojo krovinio atributus.
- Žetono parašo naudojimas antraštei ir naudingajam kroviniui padidina viso sprendimo saugumą.
JWT žetonas – kompozicija
Pavadinimas — pagal numatytuosius nustatymus antraštėje yra tik prieigos rakto tipas ir šifravimui naudojamas algoritmas.
Ženklo tipas išsaugomas klaviše "typ". „Tipo“ klavišas JWT nepaisomas. Jei yra raktas „typ“, jo reikšmė turi būti JWT, kad būtų nurodyta, jog šis objektas yra JSON žiniatinklio prieigos raktas.
Antrasis raktas „alg“ apibrėžia žetonui užšifruoti naudojamą algoritmą. Pagal numatytuosius nustatymus jis turėtų būti nustatytas į HS256. Antraštė užkoduota base64.
{ "alg": "HS256", "type": "JWT"}
naudingoji apkrova (turinys) - naudingoji apkrova saugo bet kokią informaciją, kurią reikia patikrinti. Kiekvienas naudingojo krovinio raktas yra žinomas kaip „pretenzija“. Pavyzdžiui, į programą galite patekti tik su kvietimu (uždara akcija). Kai norime ką nors pakviesti dalyvauti, išsiunčiame jam kvietimo laišką. Svarbu patikrinti, ar el. pašto adresas priklauso pakvietimą priėmusiam asmeniui, todėl šį adresą įtrauksime į naudingą apkrovą, tam išsaugome rakte „el.
{ "el. paštas": "[apsaugotas el. paštu]"}
Naudingojo krovinio raktai gali būti savavališki. Tačiau yra keletas rezervuotų:
- iss (Issuer) – identifikuoja programą, iš kurios siunčiamas prieigos raktas.
- sub (Subject) – apibrėžia žetono temą.
- aud (auditorija) yra didžiosioms ir mažosioms raidėms skirtų eilučių arba URI masyvas, kuris yra šio prieigos rakto gavėjų sąrašas. Kai gaunančioji pusė gauna JWT su duotu raktu, ji turi patikrinti, ar gavėjuose nėra savęs – kitaip nepaisykite tokeno.
- exp (galiojimo laikas) – nurodo, kada baigiasi prieigos rakto galiojimo laikas. JWT standartas reikalauja, kad visi jo diegimai atmestų pasibaigusio galiojimo žetonus. Raktas exp turi būti unix formato laiko žyma.
- nbf (Not Before) yra laikas unix formatu, kuris nustato momentą, kada prieigos raktas pradeda galioti.
- iat (Išduota) – šis raktas rodo žetono išdavimo laiką ir gali būti naudojamas JWT amžiui nustatyti. Iat raktas turi būti laiko žyma unix formatu.
- Jti (JWT ID) – eilutė, apibrėžianti unikalų šio prieigos rakto identifikatorių, skiriant didžiąsias ir mažąsias raides.
Svarbu suprasti, kad naudingoji apkrova nėra perduodama šifruota forma (nors žetonus galima įdėti ir tada galima perduoti šifruotus duomenis). Todėl jis negali saugoti jokios slaptos informacijos. Kaip ir antraštė, naudingoji apkrova yra užkoduota base64.
Parašas - kai turime titulą ir apkrovą, galime apskaičiuoti parašą.
Užkoduota Base64: paimama antraštė ir naudingoji apkrova, jos per tašką sujungiamos į eilutę. Tada ši eilutė ir slaptasis raktas įvedami į šifravimo algoritmą, nurodytą antraštėje („alg“ raktas). Raktas gali būti bet kokia eilutė. Labiausiai pageidautina ilgesnės eilutės, nes jos paėmimas užtruks ilgiau.
{"alg":"RSA1_5","naudingoji apkrova":"A128CBC-HS256"}
„Keycloak Failover Cluster“ architektūros kūrimas
Visiems projektams naudojant vieną klasterį, SSO sprendimui keliami didesni reikalavimai. Kai projektų skaičius nedidelis, šie reikalavimai nėra tokie pastebimi visiems projektams, tačiau didėjant vartotojų ir integracijų skaičiui, didėja prieinamumo ir našumo reikalavimai.
Padidėjus vieno SSO gedimo rizikai, didėja reikalavimai sprendimo architektūrai ir metodams, naudojamiems pertekliniams komponentams, todėl SLA yra labai griežta. Atsižvelgiant į tai, dažniau kuriant ar pradiniame sprendimų įgyvendinimo etape projektai turi savo gedimams netoleruojančią infrastruktūrą. Tobulėjant plėtrai, reikia numatyti plėtros ir mastelio didinimo galimybes. Lanksčiausia sukurti perjungimo klasterį naudojant konteinerio virtualizavimą arba hibridinį metodą.
Norint dirbti aktyvaus/aktyvaus ir aktyvaus/pasyvaus klasterio režimais, reikia užtikrinti duomenų nuoseklumą reliacinėje duomenų bazėje – abu duomenų bazės mazgai turi būti sinchroniškai replikuoti tarp skirtingų geografiškai paskirstytų duomenų centrų.
Paprasčiausias gedimams atsparaus įrengimo pavyzdys.
Kokie yra vieno klasterio naudojimo pranašumai:
- Didelis prieinamumas ir našumas.
- Veikimo režimų palaikymas: aktyvus / aktyvus, aktyvus / pasyvus.
- Galimybė dinamiškai keisti mastelį – naudojant konteinerio virtualizaciją.
- Galimybė centralizuotai valdyti ir stebėti.
- Vieningas vartotojų identifikavimo/autentifikavimo/autorizacijos projektuose metodas.
- Skaidresnė sąveika tarp skirtingų projektų be vartotojo sąveikos.
- Galimybė pakartotinai naudoti JWT žetoną įvairiuose projektuose.
- Vienintelis pasitikėjimo taškas.
- Greitesnis projektų paleidimas naudojant mikropaslaugas/konteinerių virtualizaciją (nereikia kelti ir konfigūruoti papildomų komponentų).
- Iš pardavėjo galima įsigyti komercinę paramą.
Į ką atkreipti dėmesį planuojant klasterį
DBVS
„Keycloak“ naudoja duomenų bazių valdymo sistemą, kad saugotų: sritis, klientus, vartotojus ir kt.
Palaikomas platus DBVS spektras: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak turi savo integruotą reliacinę duomenų bazę. Rekomenduojama naudoti neapkrautoms aplinkoms, pvz., kūrimo aplinkoms.
Norint dirbti aktyvaus / aktyvaus ir aktyvaus / pasyvaus klasterio režimais, reikalingas duomenų nuoseklumas reliacinėje duomenų bazėje, o abu duomenų bazės klasterio mazgai yra sinchroniškai replikuojami tarp duomenų centrų.
Paskirstyta talpykla („Infinspan“)
Kad klasteris veiktų tinkamai, reikia papildomai sinchronizuoti šių tipų talpyklas naudojant JBoss duomenų tinklelį:
Autentifikavimo seansai – naudojami duomenims išsaugoti autentifikuojant konkretų vartotoją. Užklausos iš šios talpyklos paprastai apima tik naršyklę ir „Keycloak“ serverį, o ne programą.
Veiksmo žetonai naudojami scenarijuose, kai vartotojas turi patvirtinti veiksmą asinchroniškai (el. paštu). Pavyzdžiui, slaptažodžio pamiršimo srauto metu „actionTokens Infinispan“ talpykla naudojama metaduomenims apie susijusius veiksmų prieigos raktus, kurie jau buvo naudojami, sekti, todėl jų negalima naudoti pakartotinai.
Nuolatinių duomenų kaupimas talpykloje ir negaliojimas – naudojamas nuolatiniams duomenims saugoti talpykloje, kad būtų išvengta nereikalingų duomenų bazės užklausų. Kai bet kuris „Keycloak“ serveris atnaujina duomenis, apie tai turi žinoti visi kiti „Keycloak“ serveriai visuose duomenų centruose.
Darbas – naudojamas tik negaliojimo pranešimams siųsti tarp klasterio mazgų ir duomenų centrų.
Vartotojo seansai – naudojami duomenims apie vartotojo seansus, kurie galioja visą vartotojo naršyklės seansą, saugoti. Talpykla turi apdoroti HTTP užklausas iš galutinio vartotojo ir programos.
Brute force apsauga – naudojama duomenims apie nesėkmingus prisijungimus sekti.
Apkrovos balansavimas
Apkrovos balansavimo priemonė yra vienintelis įėjimo į klaviatūros uždengimas taškas ir turi palaikyti fiksuotus seansus.
Programų serveriai
Jie naudojami kontroliuoti komponentų sąveiką tarpusavyje ir gali būti virtualizuojami arba talpinami naudojant esamus automatizavimo įrankius ir dinaminį infrastruktūros automatizavimo įrankių mastelį. Dažniausi diegimo scenarijai yra „OpenShift“, „Kubernates“, „Rancher“.
Tuo baigiama pirmoji dalis – teorinė. Kitoje straipsnių serijoje bus analizuojami integracijų su įvairiais tapatybės teikėjais pavyzdžiai ir nustatymų pavyzdžiai.
Šaltinis: www.habr.com