SSO mikroteenuste arhitektuuris. Kasutame Keycloak'i. Osa nr 1

Igasse suuremate ettevõtete, sh X5 Retail Group, arenguga suureneb projektide arv, kus on vajalik kasutajate volitamine. Aja jooksul muutub oluline sujuv üleminek kasutajatelt ühelt rakenduselt teisele ning seetõttu tekib vajadus kasutada ühtset sisselogimisserverit Single-Sign-On (SSO). Kuid kuidas toimida, kui selliseid identifitseerimisteenuse pakkujaid nagu AD või teised, kellel puuduvad täiendavad atribuudid, juba kasutatakse erinevates projektides? Siinkohal aitavad süsteemid, mida nimetatakse „identifitseerimisbroukeriteks“. Kõige funktsionaalsemad esindajad on sellised nagu Keycloak, Gravitee Access management jpt. Kasutusskeemid võivad olla erinevad: masinlik suhtlemine, kasutajate osalemine jne. Lahendus peab toetama paindlikku ja skaleeritavat funktsionaalsust, mis suudab kõik nõuded ühte koondada, ja selliseks lahenduseks meie ettevõttes on praegu identifitseerimisbrouker – Keycloak.

Keycloak on avatud lähtekoodiga toode, mis on mõeldud identifitseerimise ja juurdepääsu kontrollimiseks ning mille toetab RedHat. See on aluseks tooted, mis kasutavad SSO – RH-SSO.

Põhimõisted

Enne lahenduste ja lähenemiste uurimist tuleks selgeks teha terminid ja protsesside järjekord:

Identifitseerimine — see on käitumise tuvastamise protseduur tema identifikaatori põhjal (lihtsalt öeldes, see on nime, sisselogimise või numbri määramine).

Ahnikeerimine – see on autentimise protseduur (kasutajat kontrollitakse parooliga, kirja kontrollitakse digitaalse allkirjaga jne.)

Autoriseerimine – see on juurdepääsu andmine mingile ressursile (näiteks e-posti jaoks).

Identifitseerimisbrouker Keycloak

Keycloak — see on avatud lähtekoodiga identiteedi ja juurdepääsu haldamise lahendus, mis on mõeldud kasutamiseks infosüsteemides, kus võivad kasutada mikroteenuste arhitektuuri mustreid.

Keycloak pakub selliseid funktsioone nagu ühtne sisselogimine (SSO), identifitseerimise brokering ja sotsiaalne sisselogimine, kasutajate föderatsioon, kliendiadapterid, administraatori konsool ja konto haldamise konsool.

Keycloak'is toetatav põhifunktsionaalsus:

• Single-Sign On ja Single-Sign Out brauserirakenduste jaoks.
• OpenID/OAuth 2.0/SAML toe pakkumine.
• Identiteed Curate – autentimine väliste OpenID Connect või SAML identiteedi pakkujate kaudu.
• Sotsiaalne sisselogimine – toe pakkumine Google'ilt, GitHubilt, Facebookilt, Twitterilt kasutajate tuvastamiseks.
• Kasutajate föderatsioon – kasutajate sünkroniseerimine LDAP ja Active Directory serveritest ning teistest identiteedi pakkujatest.
• Kerberos sild – Kerberos serveri kasutamine kasutajate automaatseks autentimiseks.
• Administreerimise konsool — lahenduse seadete ja parameetrite ühtne haldamine veebis.
• Kontohalduskonsool – iseseisev kasutajaprofiilide haldamine.
• Lahenduse kohandamine ettevõtte kaubamärgi stiili alusel.
• 2FA autentimine – TOTP/HOTP toe pakkumine Google Authenticatori või FreeOTP kaudu.
• Sisselogimise protsessid – kasutajate iseregistreerimise, parooli taastamise ja lähtestamise võimalused jne.
• Seansi haldus – administraatorid saavad hallata kasutajate sessioone ühest kohast.
• Token Mappers – kasutajate atribuutide, rollide ja muude vajalike atribuutide sidumine tokenitega.
• Paindlik poliitika haldamine realm'i, rakenduse ja kasutajate kaudu.
• CORS tugi – kliendiadapterid sisaldavad sisseehitatud CORS vaikeseadeid.
• Teenuse pakkujate liidesed (SPI) – suur hulk SPI-sid, mis võimaldavad seadistada serveri erinevaid tööaspekte: autentimisvood, identiteedi pakkujad, protokollide sidumine ja palju muud.
• Kliendiadapterid JavaScripti rakendustele, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
• Toe pakkumine erinevatele rakendustele, mis toetavad OpenID Connecti sõltuvat teeki või SAML 2.0 teenuse pakkujate teeki.
• Laienemisvõimalus plugin'ide abil.

CI/CD protsesside jaoks ning ka Keycloakis haldustegevuste automatiseerimiseks võib kasutada REST API / JAVA API. Dokumentatsioon on saadaval elektrooniliselt:

REST API https://www.keycloak.org/docs-api/8.0/rest-api/index.html
JAVA API https://www.keycloak.org/docs-api/8.0/javadocs/index.html

Ettevõtte taseme identiteedi pakkujad (On-Premise)

Kasutajate autentimise võimalus User Federation teenuste kaudu.

Samuti võib kasutada läbivat autentimist – kui kasutajad autentitakse töölauaarvutites Kerberos'ega (LDAP või AD), saavad nad Keycloak'is automaatselt autentida ilma taas kasutajanime ja parooli sisestamiseta.

Kasutajate autentimiseks ja edasiseks autoriseerimiseks on võimalik kasutada relatsioonilist andmebaasi, mis on kõige asjakohasem arenduskeskkondades, kuna see ei nõua pikaajalisi seadistusi ja integreerimisi projektide algstaadiumis. Vaikimisi kasutab Keycloak seadeid ja kasutajaandmete salvestamiseks sisseehitatud andmebaasi.

Toetatud andmebaaside loetelu on ulatuslik ja sisaldab: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle ja teised. Praegu on kõige rohkem testitud Oracle 12C Release1 RAC ja Galera 3.12 klaster MariaDB 10.1.19 jaoks.

Identifitseerimisproviderid — sotsiaalne sisselogimine

Sotsiaalmeedia sisselogimise kasutamine on võimalik. Kasutajate autentimise võimaluse aktiveerimiseks kasutatakse Keycloacki administraatori konsooli. Rakenduste koodis ei ole muudatusi vajalikud ja see funktsionaalsus on saadaval 'karbist välja' ning võib olla aktiveeritud projekti igas staadiumis.

Kasutajate autentimiseks on võimalik kasutada OpenID/SAML identiteedi proviidereid.

Tüüpilised autoriseerimisstsenaariumid OAuth2 kasutamisel Keycloakis

Autoriseerimistunnuse voog — kasutatakse serveripoolsete rakenduste (server-side applications) puhul. Üks levinumaid autoriseerimistunnustamiseks kasutatavaid meetodeid, kuna see sobib hästi serveripoolsetele rakendustele, mille kood ja kliendiandmed ei ole kolmandatele isikutele ligipääsetavad. Protsess tugineb selles juhul ümbersuunamisele (redirection). Rakendus peab olema võimeline suhtlema kasutajaagendiga, nagu veebibrauser — saama autoriseerimistunnuseid API kaudu, mis suunatakse ümber kasutajaagendi kaudu.

Kaudne voog — kasutatakse mobiilsete või veebirakenduste jaoks (rakendused, mis töötavad kasutaja seadmes).

Implitsiitne volitus on kasutusel mobiil- ja veebirakendustes, kus kliendi privaatsust ei saa tagada. Implitsiitne volitus kasutab ka kasutaja agendi ümber suunamist, kus pääsukood edastatakse kasutaja agendile rakenduses edasiseks kasutamiseks. See teeb koodi kergesti kättesaadavaks kasutajale ja teistele rakendustele kasutaja seadmes. Sellise volituse korral ei toimu rakenduse autentimist ning protsess tugineb ümber suunamise URL-ile (eelnevalt teenuses registreeritud).

Implitsiitne voog ei toeta pääsukoodide uuendamise tokenite (refresh tokens) kasutamist.

Kliendi mandaadi andmise voog — kasutatakse rakenduse juurdepääsuks API-le. See volitus on tavaliselt mõeldud server-server interaktsioonideks, mis toimuvad taustal ilma vahetu kasutaja sekkumiseta. Kliendi mandaadi voog võimaldab veebiteenusel (privaatne klient) kasutada oma mandaate, mitte kasutaja identiteeti, autentimiseks teise veebiteenuse kutsumisel. Kõrgema turvalisuse taseme saavutamiseks võib kutse teenus kasutada mandaadiks sertifikaati (üldise salajase asemel).

OAuth2 spetsifikatsioon on kirjeldatud
RFC-6749
RFC-8252
RFC-6819

JWT token ja tema eelised

JWT (JSON Web Token) — avatud standard (https://tools.ietf.org/html/rfc7519), mis määrab kindlaks kompaktse ja autonoomse viisi teabe turvaliseks edastamiseks osaliste vahel JSON-objekti kujul.

Standardi kohaselt koosneb token kolmest osast base-64 formaadis, mida eraldavad punktid. Esimene osa on pealkiri (header), milles on tokeni tüüp ja häkkimise algoritmi nimi, et saada digitaalallkiri. Teine osa salvestab põhiteabe (kasutaja, atribuute jne). Kolmas osa on digitaalne allkiri.

<encoded header>.<encoded payload>.<signature>
Ärge kunagi salvestage tokenit oma andmebaasi. Sest kehtiv token on võrdne parooliga, tokeni salvestamine on nagu parooli salvestamine selgesõnaliselt.
Pääsutoken — see on token, mis annab selle omanikule juurdepääsu serveri kaitstud ressurssidele. Tavaliselt on selle kehtivusaeg lühike ja see võib sisaldada täiendavat teavet, nagu kliendi IP-aadress, kes seda tokenit küsib.

Refresh-token — see on token, mis võimaldab klientidel taotleda uusi access-token'e nende kehtivusaja lõppedes. Need tokenid antakse tavaliselt pika aja eest.

Peamised eelised mikroteenuste arhitektuuris:

• Eri rakenduste ja teenuste juurde pääsemine ühe autentimise kaudu.
• Kui kasutajate profiilides puuduvad vajalikud atribuudid, võib andmeid rikastada, sealhulgas automatiseeritult ja
• Info aktiivsete sessioonide hoidmine pole vajalik, serveri rakendus peab vaid kontrollima allkirja.
• Paindlikum juurdepääsu haldamine täiendavate atribuutide abil kasulikus laadimises.
• Tokeni allkirja rakendamine päises ja kasulikes laadimistes suurendab lahenduse üldist turvalisust.

JWT token — koosseis

Pealkiri — vaikimisi sisaldab päis ainult tokeni tüüpi ja algoritmi, mis on kasutusel krüpteerimiseks.

Tokeni tüüp hoitakse võtmes "typ". Võtme "typ" ignoreerib JWT. Kui võti "typ" on olemas, peab selle väärtus olema JWT, et näidata, et see objekt on JSON Web Token.

Teine võti "alg" määrab tokeni krüpteerimiseks kasutatava algoritmi. Vaikimisi peaks see olema seadistatud HS256. Päis kodeeritakse base64.

{ "alg": "HS256", "typ": "JWT"}
Payload (sisu) — kasulikes laadimistes hoitakse igasugust teavet, mida tuleb kontrollida. Iga võti kasulikes laadimistes on tuntud kui "deklareering". Näiteks, rakendusse saab sisse logida ainult kutse alusel (suletud kampaania). Kui me soovime kedagi kutsea, saadame talle kutse. Oluline on kontrollida, et e-posti aadress kuulub inimesele, kes kutset aktsepteerib, seega lisame selle aadressi kasuliku laadimise, selle jaoks salvestame selle võtmesse "e-mail".

{ "email": "example@x5.ru" }

Payloadi võtmed võivad olla suvalised. Siiski on mõningaid reserveeritud:

• iss (Issuer) — määrab rakenduse, millest token saadetakse.
• sub (Subject) — määratleb tokeni teema.
• aud (Audience) – suurtundlikest stringidest või URI-dest koosnev massiiv, mis on selle tokeni saajate loetelu. Kui vastuvõtja saab JWT koos selle võtmega, peab ta kontrollima, kas ta on saajate hulgas — muidu tuleb token ignoreerida.
• exp (Expiration Time) — näitab, millal tokeni kehtivus lõppeb. JWT standard nõuab, et kõikides oma rakendustes lükataks tagasi aegunud tokeneid. Exp võti peab olema Unix vormingus ajatempring.
• nbf (Not Before) — see on Unix vormingus aeg, mis määratleb, millal token hakkab kehtima.
• iat (Issued At) — see võti esindab aega, millal token anti välja ja seda saab kasutada JWT vanuse määramiseks. iat võti peab olema Unix vormingus ajatempring.
• Jti (JWT ID) — string, mis määratleb selle tokeni unikaalse identifikaatori, arvestades suurtundlikkust.

Oluline on mõista, et koormust ei edastata krüpteeritud kujul (kuigi tokenid võivad olla pesakonnas ja siis on võimalik edastada krüpteeritud andmeid). Seega ei saa selles salvestada mingeid salajasi andmeid. Nagu pealkiri, kodeeritakse koormus base64.
Allkiri — kui meil on pealkiri ja koormus, saame arvutada allkirja.

Võetakse base64 kodeeritud pealkiri ja koormus, need ühendatakse punktiga stringiks. Seejärel antakse see string ja salajane võti krüpteerimise algoritmi, mis on määratud pealkirjas (võti «alg»). Võti võib olla mis tahes string. Pikemad stringid on eelistatavamad, kuna nende leidmiseks kulub rohkem aega.

{"alg":"RSA1_5", "payload":"A128CBC-HS256"}

Keycloaki talitlushäiredeta klastrite arhitektuuri loomine

Kuna kasutatakse ühte klastrit kõigi projektide jaoks, tõusevad SSO lahenduse nõudmised. Kui projektide arv on väike, ei ole see vägagi tundlik, kuid kasutajate ja integratsioonide arvu suurenedes kasvavad nõudmised kättesaadavuse ja jõudluse osas.

Üheainsa SSO tõusvad riskid suurendavad lahenduse arhitektuuri ja kasutatavate komponentide varukoopiate nõudeid, tuues kaasa väga range SLA. Seetõttu on sageli lahenduste arendamise või varases rakendamisfaasis projektidel oma mittetäiendav infrastruktuur. Arengu käigus peab olema rajatud arenguvõimalused ja skaleeritavus. Kõige paindlikum on ehitada tõrkeohutu klaster konteinerite virtualiseerimise või hübriidlähenemise abil.

Active/Active ja Active/Passive klastrirežiimi töötamiseks tuleb tagada andmete järjepidevus relatsioonilises andmebaasis — mõlemad andmebaasi sõlmed peavad olema geograafiliselt hajutatud andmekeskuste vahel sünkhäälestatud.

Lihtsaim näide tõrkeohutust paigaldusest.

Millised on ühtse klastriga kasutamise eelised:

• Kõrge kättesaadavus ja jõudlus.
• Toetatakse töörežiime: Active/Active, Active/Passive.
• Dünaamilise skaleerimise võimalus — konteinerite virtualiseerimise kasutamisel.
• Keskne haldamise ja jälgimise võimalus.
• Ühtne lähenemine kasutajate tuvastamiseks, autentimiseks ja autoriseerimiseks projektides.
• Selgem koostöö erinevate projektide vahel ilma kasutajate sekkumiseta.
• JWT tokeni uuesti kasutamise võimalus erinevates projektides.
• Üksik usalduspunkt.
• Projektide kiirem käivitamine mikroteenuste või konteinerite virtualiseerimise kasutamisega (lisakomponentide ülesehitamist ja seadistamist pole vajalik).
• On võimalik hankida kaubanduslikku tuge tootjalt.

Millele tuleks klastrite planeerimisel tähelepanu pöörata

andmebaase

Keycloak kasutab andmebaasi haldussüsteemi realmide, klientide, kasutajate jne salvestamiseks.
Toetatakse suurt hulka andmebaasisüsteeme: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak on varustatud oma sisseehitatud relatsioonilise andmebaasiga. Soovitatav on kasutada vähem koormatud keskkondades — näiteks arenduskeskkondades.

Active/Active ja Active/Passive klastrirežiimi töötamiseks tuleb tagada andmete järjepidevus relatsioonilises andmebaasis ja mõlemad andmebaasi klastrisõlmed sünkhäälestatakse andmekeskuste vahel.

Jaotatud vahemälu (Infinispan)

Klastri korrektseks on vajalik täiendav sünkroniseerimine järgmiste vahemälu tüüpide vahel JBoss Data Grid kasutades:

Autentimise seansid — kasutatakse konkreetse kasutaja autentimise andmete salvestamiseks. Selles vahemälus olevad päringud sisaldavad tavaliselt ainult veebibrauserit ja Keycloki serverit, mitte rakendust.

Tegevustokenid — kasutatakse stsenaariumides, kus kasutaja peab kinnitama toimingu asünkroonselt (e-posti teel). Näiteks parooli taastamise protsessi käigus jälgib actionTokens Infinispan seotud tegevuste tokenite metadata, mis on juba kasutatud, seega ei saa neid uuesti kasutada.

Püsivate andmete vahemälu ja kehtetuks tunnistamine – kasutatakse püsivate andmete vahemällu salvestamiseks, et vältida liigseid päringuid andmebaasile. Kui mõni Keycloki server uuendab andmeid, peavad kõik teised Keycloki serverid kõigis andmekeskustes sellest teadlikud olema.

Töö — kasutatakse ainult sõnumite edastamiseks kehtetuks tunnistamise kohta klastrite sõlmede ja andmekeskuste vahel.

Kasutaja seansid — kasutatakse kasutaja seansside andmete salvestamiseks, mis kehtivad kasutaja brauseri seansi jooksul. Vahemälu peab töötlema lõppkasutaja ja rakenduse HTTP-päringuid.

Ründeressursside kaitse — kasutatakse ebaõnnestunud sisenemiste andmete jälgimiseks.

Koormuse tasakaalustamine

Laadimise tasakaalustaja on ainus sisenepunkt Keycloki ja peab toetama sticky sessions.

Rakenduste serverid

Kasutatakse komponentide omavahelise suhtluse kontrollimiseks ning need võivad olla virtualiseeritud või konteineriseeritud olemasolevate automatiseerimise ja dynaamilise infrastruktuuri skaleerimise vahendite abil. Kõige levinumad juurutamisstsenaariumid OpenShiftis, Kubernetesis, Rancheris.

Sellega on esimene osa – teoreetiline — lõpetatud. Järgmistes artiklites käsitletakse integratsioonide näiteid erinevate identiteediteenuse pakkujatega ja seadistuse näiteid.

Allikas: habr.com