Igas suures ettevõttes ja X5 Retail Group pole erand, kuna selle arenedes suureneb kasutajate autoriseerimist nõudvate projektide arv. Aja jooksul on vajalik kasutajate sujuv üleminek ühest rakendusest teise ja seejärel on vaja kasutada ühtainsat ühekordset (SSO) serverit. Aga mis siis, kui identiteedipakkujaid nagu AD või muud, millel pole täiendavaid atribuute, kasutatakse juba erinevates projektides. Appi tuleb süsteemide klass, mida nimetatakse "tuvastusvahendajateks". Kõige funktsionaalsemad on selle esindajad, nagu Keycloak, Gravitee Access Management jne. Enamasti võivad kasutusjuhtumid olla erinevad: masina interaktsioon, kasutajate osalemine jne. Lahendus peab toetama paindlikku ja skaleeritavat funktsionaalsust, mis suudab ühendada kõik nõuded ühte, ja sellised lahendused on meie ettevõttel nüüd näidismaakler - Keycloak.
Keycloak on avatud lähtekoodiga identiteedi- ja juurdepääsukontrollitoode, mida haldab RedHat. See on aluseks ettevõtte toodetele, mis kasutavad SSO - RH-SSO.
Põhimõisted
Enne lahenduste ja lähenemisviisidega tegelemist peaksite otsustama protsesside terminite ja järjestuse osas:
Identifitseerimine on protseduur subjekti äratundmiseks tema identifikaatori järgi (teisisõnu, see on nime, sisselogimise või numbri määratlus).
Autentimine - see on autentimisprotseduur (kasutajat kontrollitakse parooliga, kirja kontrollitakse elektroonilise allkirjaga jne)
luba - see on juurdepääsu võimaldamine ressursile (näiteks e-postile).
Identiteedivahendaja võtmerätt
võtmesärk on avatud lähtekoodiga identiteedi- ja juurdepääsuhalduslahendus, mis on loodud kasutamiseks IS-is, kus saab kasutada mikroteenuste arhitektuuri mustreid.
Keycloak pakub selliseid funktsioone nagu ühekordne sisselogimine (SSO), vahendatud identiteet ja sotsiaalne sisselogimine, kasutajate liit, kliendiadapterid, administraatorikonsool ja kontohalduskonsool.
Keycloaki toetatud põhifunktsioonid:
- Brauserirakenduste jaoks ühekordne sisse- ja väljalogimine.
- OpenID/OAuth 2.0/SAML tugi.
- Identiteedi vahendamine – autentimine väliste OpenID Connecti või SAML-identiteedi pakkujate abil.
- Sotsiaalne sisselogimine – Google, GitHub, Facebook, Twitter kasutaja tuvastamise tugi.
- Kasutajate liitmine – kasutajate sünkroonimine LDAP- ja Active Directory serveritest ning muudest identiteedipakkujatest.
- Kerberose sild – Kerberose serveri kasutamine kasutaja automaatseks autentimiseks.
- Admin Console – seadete ja lahendusvalikute ühtseks haldamiseks veebi kaudu.
- Kontohalduskonsool – kasutajaprofiili isehaldamiseks.
- Lahenduse kohandamine lähtuvalt ettevõtte korporatiivsest identiteedist.
- 2FA autentimine – TOTP/HOTP tugi Google Authenticatori või FreeOTP abil.
- Sisselogimisvood – võimalik on kasutaja ise registreerimine, parooli taastamine ja lähtestamine ning muu.
- Seansihaldus – administraatorid saavad hallata kasutajaseansse ühest punktist.
- Token Mappers – kasutaja atribuutide, rollide ja muude nõutavate atribuutide sidumine žetoonidega.
- Paindlik poliitikahaldus valdkonna, rakenduse ja kasutajate vahel.
- CORS-i tugi – kliendiadapteritel on sisseehitatud CORS-tugi.
- Teenusepakkuja liidesed (SPI) – suur hulk SPI-sid, mis võimaldavad kohandada serveri erinevaid aspekte: autentimisvood, identiteedipakkujad, protokolli vastendamine ja palju muud.
- Kliendiadapterid JavaScripti rakendustele, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Toetus erinevate rakendustega töötamiseks, mis toetavad OpenID Connect Relying Party teeki või SAML 2.0 teenusepakkuja teeki.
- Laiendatav pluginate abil.
CI / CD protsesside ja Keycloaki haldusprotsesside automatiseerimiseks saab kasutada REST API / JAVA API-t. Dokumentatsioon on saadaval elektrooniliselt:
REST API
Java API
Ettevõtte identiteedi pakkujad (kohapealsed)
Võimalus kasutajaid kasutajate liitmise teenuste kaudu autentida.
Kasutada saab ka läbipääsuautentimist – kui kasutajad autentivad Kerberosega (LDAP või AD) tööjaamade vastu, saab neid automaatselt Keycloaki autentida, ilma et peaksid oma kasutajanime ja parooli uuesti sisestama.
Kasutajate autentimiseks ja edasiseks autoriseerimiseks on võimalik kasutada relatsioonilist DBMS-i, mis on kõige sobivam arenduskeskkondades, kuna see ei hõlma projektide varases staadiumis pikki seadistusi ja integreerimist. Vaikimisi kasutab Keycloak seadete ja kasutajaandmete salvestamiseks sisseehitatud DBMS-i.
Toetatud DBMS-ide loend on ulatuslik ja sisaldab: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle jt. Seni enim testitud on Oracle 12C Release1 RAC ja Galera 3.12 klaster MariaDB 10.1.19 jaoks.
Identiteedipakkujad – sotsiaalne sisselogimine
Võimalik on kasutada sisselogimist sotsiaalvõrgustikest. Kasutajate autentimise võimaluse aktiveerimiseks kasutage Keyclocki administraatorikonsooli. Rakenduse koodi muutmine ei ole vajalik ja see funktsioon on saadaval koheselt ja seda saab aktiveerida projekti mis tahes etapis.
Kasutaja autentimiseks on võimalik kasutada OpenID/SAML identiteedi pakkujaid.
Tüüpilised autoriseerimisstsenaariumid, kasutades Keycloakis OAuth2
Autoriseerimiskoodi voog - kasutatakse serveripoolsete rakendustega. Üks levinumaid autoriseerimislubade tüüpe, kuna see sobib hästi serverirakendustele, kus rakenduse lähtekood ja kliendiandmed pole kõrvalistele isikutele kättesaadavad. Sel juhul põhineb protsess ümbersuunamisel. Rakendus peab suutma suhelda kasutajaagendiga (kasutajaagent), näiteks veebibrauseriga – et saada kasutajaagendi kaudu ümber suunatud API autoriseerimiskoode.
kaudne vool - mida kasutavad mobiili- või veebirakendused (kasutaja seadmes töötavad rakendused).
Kaudset autoriseerimisloa tüüpi kasutavad mobiili- ja veebirakendused, kus kliendi konfidentsiaalsust ei saa tagada. Kaudne loatüüp kasutab ka kasutajaagendi ümbersuunamist, mille käigus juurdepääsuluba edastatakse kasutajaagendile rakenduses edasiseks kasutamiseks. See muudab märgi kasutajale ja teistele kasutaja seadmes olevatele rakendustele kättesaadavaks. Seda tüüpi autoriseerimisluba ei autenti rakenduse identiteeti ja protsess ise tugineb ümbersuunamise URL-ile (varem teenuses registreeritud).
Implicit Flow ei toeta juurdepääsulubade värskendamise lubasid.
Kliendi volituste andmise voog - kasutatakse siis, kui rakendus pääseb juurde API-le. Seda tüüpi autoriseerimisluba kasutatakse tavaliselt serveritevahelise suhtluse jaoks, mis tuleb teha taustal ilma kasutaja vahetu sekkumiseta. Kliendi mandaatide andmise voog võimaldab veebiteenusel (konfidentsiaalne klient) kasutada oma mandaate, selle asemel, et esineda teise veebiteenuse helistamisel kasutajana autentimiseks. Kõrgema turvalisuse tagamiseks on helistamisteenusel võimalik kasutada mandaadina sertifikaati (jagatud saladuse asemel).
OAuth2 spetsifikatsiooni on kirjeldatud artiklis
JWT märk ja selle eelised
JWT (JSON Web Token) on avatud standard (), mis määratleb kompaktse ja iseseisva viisi osapooltevahelise teabe turvaliseks edastamiseks JSON-objektina.
Standardi kohaselt koosneb token kolmest osast base-64 formaadis, mis on eraldatud punktidega. Esimest osa nimetatakse päiseks, mis sisaldab märgi tüüpi ja digiallkirja saamise räsialgoritmi nime. Teine osa salvestab põhiteabe (kasutaja, atribuudid jne). Kolmas osa on digitaalallkiri.
. .
Ärge kunagi hoidke oma andmebaasis märki. Kuna kehtiv luba on samaväärne parooliga, on märgi salvestamine sama, mis parooli salvestamine selge tekstina.
Juurdepääsuluba on tunnus, mis annab selle omanikule juurdepääsu turvalistele serveriressurssidele. Tavaliselt on selle kasutusiga lühike ja see võib sisaldada lisateavet, näiteks luba taotleva osapoole IP-aadressi.
Värskenda tunnust on luba, mis võimaldab klientidel taotleda uusi juurdepääsulubasid pärast nende kasutusaja möödumist. Need märgid väljastatakse tavaliselt pikaks perioodiks.
Mikroteenuste arhitektuuris kasutamise peamised eelised:
- Võimalus pääseda juurde erinevatele rakendustele ja teenustele ühekordse autentimise kaudu.
- Mitmete nõutavate atribuutide puudumisel kasutajaprofiilis on võimalik rikastada andmetega, mida saab kasulikku koormust lisada, sh automatiseeritud ja käigupealt.
- Aktiivsete seansside kohta infot pole vaja salvestada, serverirakendus peab vaid allkirja kontrollima.
- Paindlikum juurdepääsukontroll kasuliku koormuse lisaatribuutide kaudu.
- Päise ja kasuliku koormuse märgisignatuuri kasutamine suurendab lahenduse kui terviku turvalisust.
JWT märk – koosseis
Pealkiri - vaikimisi sisaldab päis ainult märgi tüüpi ja krüpteerimiseks kasutatavat algoritmi.
Märgi tüüp salvestatakse klahvi "typ". JWT-s ignoreeritakse klahvi "tüüp". Kui võti "typ" on olemas, peab selle väärtus olema JWT, mis näitab, et see objekt on JSON-i veebimärk.
Teine võti "alg" määratleb algoritmi, mida kasutatakse märgi krüptimiseks. Vaikimisi peaks see olema seatud väärtusele HS256. Päis on kodeeritud base64-s.
{ "alg": "HS256", "tüüp": "JWT"}
kasulik koormus (sisu) - kasulik koormus salvestab kogu teabe, mida tuleb kontrollida. Iga kasuliku koorma võtit nimetatakse "nõudeks". Näiteks saate rakendusse siseneda ainult kutsega (suletud pakkumine). Kui tahame kedagi osalema kutsuda, saadame talle kutsekirja. Oluline on kontrollida, et e-posti aadress kuuluks inimesele, kes kutse vastu võtab, nii et lisame selle aadressi kasulikku koormusse, selleks salvestame selle "e-posti" võtmesse
{ "e-post": "[meiliga kaitstud]"}
Kasuliku koormuse võtmed võivad olla suvalised. Siiski on mõned reserveeritud:
- iss (väljaandja) – identifitseerib rakenduse, kust luba saadetakse.
- sub (Subject) – määrab märgi teema.
- aud (Audience) on tõstutundlike stringide või URI-de massiiv, mis on selle loa saajate loend. Kui vastuvõttev pool saab antud võtmega JWT, peab ta kontrollima enda olemasolu adressaatide hulgas – vastasel juhul ignoreerige luba.
- exp (aegumisaeg) – näitab, millal luba aegub. JWT standard nõuab, et kõik selle juurutused lükkaksid aegunud märgid tagasi. Eksp-võti peab olema unix-vormingus ajatempel.
- nbf (Not Before) on unix-vormingus aeg, mis määrab hetke, millal luba hakkab kehtima.
- iat (välja antud) – see võti tähistab märgi väljastamise aega ja seda saab kasutada JWT vanuse määramiseks. Iat-võti peab olema unix-vormingus ajatempel.
- Jti (JWT ID) – string, mis määrab selle loa kordumatu identifikaatori, tõstutundlik.
Oluline on mõista, et kasulikku koormust ei edastata krüpteeritud kujul (kuigi tokeneid saab pesastada ja seejärel on võimalik krüpteeritud andmeid edastada). Seetõttu ei saa see salvestada mingit salajast teavet. Nagu päis, on kasulik koormus base64 kodeeritud.
Allkiri - kui meil on pealkiri ja koormus, saame allkirja arvutada.
Base64-kodeering: päis ja kasulik koormus võetakse, need ühendatakse stringiks läbi punkti. Seejärel sisestatakse see string ja salajane võti päises määratud krüpteerimisalgoritmi ("alg" võti). Võti võib olla mis tahes string. Enim eelistatakse pikemaid stringe, kuna selle ülesvõtmine võtab kauem aega.
{"alg":"RSA1_5","kasulik koormus":"A128CBC-HS256"}
Keycloak Failover Cluster Arhitektuuri loomine
Kui kasutate kõigi projektide jaoks ühte klastrit, on SSO-lahendusele kõrgemad nõuded. Kui projektide arv on väike, ei ole need nõuded kõigi projektide puhul nii märgatavad, kuid kasutajate arvu ja integratsioonide kasvuga suurenevad nõuded saadavuse ja jõudluse osas.
Ühekordse SSO-tõrke riski suurendamine suurendab nõudeid lahenduse arhitektuurile ja meetoditele, mida kasutatakse üleliigsete komponentide jaoks ning viib väga tiheda SLA-ni. Sellega seoses on projektidel sagedamini väljatöötamisel või lahenduste juurutamise varases staadiumis oma tõrketaluv infrastruktuur. Arengu edenedes tuleb paika panna arendus- ja skaleerimisvõimalused. Kõige paindlikum on luua tõrkesiirdeklastri konteineri virtualiseerimise või hübriidmeetodi abil.
Klastrite režiimides Aktiivne/Aktiivne ja Aktiivne/Passiivne töötamiseks on vaja tagada andmete järjepidevus relatsiooniandmebaasis – mõlemad andmebaasisõlmed peavad olema sünkroonselt paljundatud erinevate geograafiliselt hajutatud andmekeskuste vahel.
Lihtsaim näide tõrketaluvast paigaldusest.
Millised on ühe klastri kasutamise eelised:
- Kõrge kättesaadavus ja jõudlus.
- Töörežiimide tugi: aktiivne / aktiivne, aktiivne / passiivne.
- Võimalus dünaamiliselt skaleerida – konteineri virtualiseerimise kasutamisel.
- Tsentraliseeritud haldamise ja monitooringu võimalus.
- Ühtne lähenemine kasutajate tuvastamiseks/autentimiseks/autoriseerimiseks projektides.
- Läbipaistvam suhtlus erinevate projektide vahel ilma kasutajaid kaasamata.
- Võimalus JWT-märki erinevates projektides uuesti kasutada.
- Üksainus usalduspunkt.
- Projektide kiirem käivitamine kasutades mikroteenuseid/konteinerite virtualiseerimist (pole vaja lisakomponente tõsta ja seadistada).
- Müüjalt on võimalik osta kaubanduslikku tuge.
Mida klastri kavandamisel otsida
DBMS
Keycloak kasutab andmebaasihaldussüsteemi, et salvestada: valdusi, kliente, kasutajaid jne.
Toetatud on lai valik DBMS-e: MS SQL, Oracle, MySQL, PostgreSQL. Keycloakil on oma sisseehitatud relatsiooniandmebaas. Soovitatav on kasutada laadimata keskkondades – näiteks arenduskeskkonnas.
Aktiivse/aktiivse ja aktiivse/passiivse klastrirežiimides töötamiseks on vajalik andmete järjepidevus relatsiooniandmebaasis ning mõlemad andmebaasiklastri sõlmed kopeeritakse andmekeskuste vahel sünkroonselt.
Hajutatud vahemälu (Infinspan)
Klastri korrektseks tööks on vaja järgmist tüüpi vahemälu täiendavat sünkroonimist JBossi andmevõrgu abil.
Autentimiseansid – kasutatakse andmete salvestamiseks konkreetse kasutaja autentimisel. Sellest vahemälust pärinevad päringud hõlmavad tavaliselt ainult brauserit ja Keycloaki serverit, mitte rakendust.
Toimingumärke kasutatakse stsenaariumide jaoks, kus kasutaja peab toimingu asünkroonselt (e-posti teel) kinnitama. Näiteks parooli unustamise ajal kasutatakse vahemälu actionTokens Infinispan juba kasutatud seotud toimingulubade metaandmete jälgimiseks, nii et seda ei saa uuesti kasutada.
Püsivate andmete vahemällu salvestamine ja kehtetuks tunnistamine – kasutatakse püsivate andmete vahemällu salvestamiseks, et vältida tarbetuid päringuid andmebaasi. Kui mõni Keycloaki server andmeid värskendab, peavad sellest teadma kõik teised Keycloaki serverid kõigis andmekeskustes.
Töö – kasutatakse ainult kehtetute sõnumite saatmiseks klastri sõlmede ja andmekeskuste vahel.
Kasutajaseansid – kasutatakse andmete salvestamiseks kasutajaseansside kohta, mis kehtivad kasutaja brauseri seansi kestel. Vahemälu peab töötlema lõppkasutaja ja rakenduse HTTP-päringuid.
Julma jõu kaitse – kasutatakse ebaõnnestunud sisselogimiste andmete jälgimiseks.
Koormuse tasakaalustamine
Koormuse tasakaalustaja on klahvikatte üks sisenemispunkt ja see peab toetama kleepuvaid seansse.
Rakendusserverid
Neid kasutatakse komponentide omavahelise interaktsiooni juhtimiseks ja neid saab virtualiseerida või konteinerisse paigutada olemasolevate automatiseerimistööriistade ja infrastruktuuri automatiseerimistööriistade dünaamilise skaleerimise abil. Levinumad juurutamise stsenaariumid OpenShiftis, Kubernatesis, Rancheris.
Sellega on esimene osa – teoreetiline – lõpetatud. Järgmises artiklite sarjas analüüsitakse näiteid integreerimisest erinevate identiteedipakkujatega ja seadistusnäiteid.
Allikas: www.habr.com