Mikroteenuste arhitektuuril põhinev SSO. Kasutame Keycloak'i. Osa №1

Igas suuremas ettevõttes, sealhulgas X5 Retail Groupis, suureneb projektide arv, kus on vajalik kasutajate autentimine. Aja jooksul on vajalik sujuv üleminek rakenduste vahel, millega kaasneb vajadus ühtse SSO-serveri järele. Kuid kuidas toimida, kui sellised identiteedi pakkujad nagu AD või muud, mis ei oma täiendavaid atribuute, on juba erinevates projektides kasutusel? Siin tulevad appi identiteedi vahendajate süsteemid. Kõige funktsionaalsemad neist on viimaste esindajad, nagu Keycloak, Gravitee Access management jne. Kasutusskenaarid võivad olla erinevad: masinavaheline suhtlemine, kasutajate osalemine jne. Lahendus peab toetama paindlikku ja skaleeritavat funktsionaalsust, mis suudab ühendada kõik nõuded ühte, ning meie ettevõttes on selliseks lahenduseks praegu identiteedi vahendaja – Keycloak.

Keycloak – avatud lähtekoodiga toode, mis on mõeldud identiteedi ja juurdepääsu kontrollimiseks ning mida toetab RedHat. See on aluseks ettevõtte toodetele, mis kasutavad SSO – RH-SSO.

Peamised mõisted

Enne lahenduste ja lähenemisviiside täpsustamist tuleb määratleda terminid ja protsesside järjestus:

Identifitseerimine — see on isiku tuvastamise protseduur tema identifikaatori järgi (lihtsalt öeldes, see on nime, kasutajanime või numbri määramine).

Autentimine – see on autentimise kontrollimise protseduur (kasutaja tõendatakse parooli, e-kirja digitaalse allkirja jms abil).

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

Identifitseerimisprokurör Keycloak

Keycloak — avatud lähtekoodiga identiteedi ja juurdepääsu haldamise lahendus, mõeldud kasutamiseks teabe süsteemides, kus võivad rakenduda mikroteenuste arhitektuuri mustrid.

Keycloak pakub funktsioone nagu ühekordne sisenemine (SSO), identiteedi vahendamine ja sotsiaalne sisenemine, kasutajate föderatsioon, kliendi adapterid, administraatori konsool ja konto haldamise konsool.

Keycloak toetab järgmisi põhifunktsioone:

• Ühekordne sisenemine ja ühekordne väljumine brauserirakenduste jaoks.
• OpenID/OAuth 2.0/SAML toe pakkumine.
• Identiteedi vahendamine – autentimine väliste OpenID Connect või SAML identiteedi pakkijate kaudu.
• Sotsiaalne sisenemine – tugi Google'i, GitHubi, Facebooki, Twitteri kaudu kasutajate tuvastamiseks.
• Kasutajate föderatsioon – kasutajate sünkroniseerimine LDAP ja Active Directory serveritest ja muudest identiteedi pakkijatest.
• Kerberose sild – Kerberose serveri kasutamine kasutajate automaatseks autentimiseks.
• Administraatori konsool – seadete ja lahenduse parameetrite haldamiseks veebis.
• Konto haldamise konsool – kasutajaprofiili iseseisvaks haldamiseks.
• Lahenduse kohandamine ettevõtte brändi stiilist lähtuvalt.
• 2FA autentimine – TOTP/HOTP tugi Google Authenticatori või FreeOTP abil.
• Sisselogimise vood – toetada on võimalik iseregistreerimist, parooli taastamist ja lähtestamist ning muud.
• Seansihalduse haldamine – administraatorid saavad hallata kasutajate seansse ühest kohast.
• Tokeni kaardistajad – kasutajate, rollide ja teiste nõutud atribuutide sidumine tokenitega.
• Paindlik poliitikahaldus realm'i, rakenduste ja kasutajate kaudu.
• CORSi tugi – kliendiadapteritel on sisseehitatud CORSi tugi.
• Teenusepakkuja liidesed (SPI) – suur hulk SPI-sid, mis võimaldavad kohandada serveri erinevaid aspekte: autentimistooted, identifitseerimisprotsessorid, protokollide kaardistamine ja palju muud.
• Kliendiadapterid JavaScripti rakenduste, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring jaoks.
• Toetab töö töötlemist erinevate rakendustega, mis toetavad OpenID Connect Relying Party library või SAML 2.0 Service Provider Library.
• Laienemise võimalus pluginate kasutamise kaudu.

CI/CD protsesside ning Keycloak'i haldusprotsesside automatiseerimiseks võib kasutada REST API / JAVA API. Dokumentatsioon on elektrooniliselt saadaval:

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 identifitseerimisprotsessorid (On-Premise)

Kasutajate autentimise võimalus User Federation teenuste kaudu.

Samuti võib kasutada ühtset autentimist — kui kasutajad logivad sisse tööstustes Kerberos (LDAP või AD) kaudu, saavad nad automaatselt autentida Keycloak'is, ilma et peaksid uuesti sisestama oma kasutajanime ja parooli.

Kasutajate autentimiseks ja järgnevaks autoriseerimiseks on võimalik kasutada relatsioonilist andmebaasi, mis on kõige sobivam arenduskeskkondades, kuna see ei nõua pikaajalisi seadistusi ja integreerimisi projekti varases etapis. Keycloak kasutab vaikimisi sisseehitatud andmebaasi seadete ja kasutajaandmete salvestamiseks.

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

Identiteedipakkujad — sotsiaalne sisselogimine

Sotsiaalmeedia sisselogimise kasutamine on võimalik. Kasutajate autentimise aktiveerimiseks kasutatakse Keycloak'i administreerimiskonsooli. Rakenduste koodis muudatusi ei küsita, ning see funktsionaalsus on saadaval "välja pakutud" ja seda saab aktiveerida projekti igas etapis.

Kasutajate autentimiseks on võimalik kasutada OpenID/SAML identiteeditarnijaid.

Tüüpilised autoriseerimisstsenaariumid OAuth2 kasutamisel Keycloak'is

Autoriseerimisvõti voog — kasutatakse serveripõhistes rakendustes (server-side applications). Üks levinumaid võtmemeetodeid, kuna see sobib hästi serveripõhistele rakendustele, mille lähtekood ja kliendiandmed ei ole kolmandatele isikutele kergesti kättesaadavad. Protsess põhineb sel juhul ümbersuunamisel (redirection). Rakendus peab olema võimeline suhtlema kasutajaagendi (user-agent), näiteks veebibrauseriga — saama autoriseerimise koode, mis on ümbersuunatud läbi kasutajaagendi.

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

Kaudne autoriseerimise tüüp on mõeldud mobiil- ja veebirakendustele, kus kliendi konfidentsiaalsust ei saa garantiida. Kaudne autoriseerimise tüüp kasutab ka kasutajaagendi ümber suunamist, mille käigus edastatakse juurdepääsutoken kasutajaagendile rakenduses edasiseks kasutamiseks. See muudab tokeni kergesti kättesaadavaks kasutajale ja teistele rakendustele tema seadmes. Selle autoriseerimise tüübi puhul ei toimu rakenduse autentimise kontrollimist ning kogu protsess toetub ümber suunamise URL-ile (mis on eelnevalt teenuses registreeritud).

Kaudne voog ei toeta juurdepääsutokeni värskendustokenite (refresh tokens) kasutamist.

Kliendi mandaadi autoriseerimise voog — kasutatakse rakenduste juurdepääsuks API-le. See autoriseerimise tüüp on tavaliselt mõeldud server-server interaktsioonideks, mis peavad toimuma taustal ilma otsese kasutajaga suhtlemiseta. Klientide mandaadi voog võimaldab veebiteenustel (privaatsetel klientidel) kasutada oma mandaate ilma kasutaja autentimise vajaduseta, kui kutsutakse teist veebiteenust. Kõrgema turvalisuse tagamiseks võib kutse teenus kasutada sertifikaati (üldise salajase asemel) mandaadina.

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

JWT token ja selle eelised

JWT (JSON Web Token) on avatud standard (https://tools.ietf.org/html/rfc7519), mis määratleb kompaktsed ja iseseisvad viisid teabe turvaliseks edastamiseks osapoolte vahel JSON-objekti kujul.

Standardi kohaselt koosneb token kolmest osast, mis on jagatud punktidega base-64 formaadis. Esimene osa on pealkiri (header), mis sisaldab tokeni tüüpi ja digitaalallkirja genereerimiseks kasutatava räsi algoritmi nime. Teine osa sisaldab põhiteavet (kasutaja, atribuudid jne). Kolmas osa on digitaalallkiri.

..
Ärge salvestage tokenit oma andmebaasi. Kuna kehtiv token on ekvivalentne parooliga, on tokeni salvestamine sama, mis parooli avatud kujul salvestamine.
Access-token on token, mis annab oma omanikule juurdepääsu serveri kaitstud ressurssidele. Tavaliselt on sellel lühike kehtivusaeg ja see võib sisaldada täiendavat teavet, näiteks IP-aadressi, mis küsib antud tokenit.

Refresh-token on token, mis võimaldab klientidel taotleda uusi access-token'e nende kehtivuse lõppemise järel. Need tokenid väljastatakse tavaliselt pikemaks ajaks.

Mikroteenuste arhitektuuris rakendamise peamised eelised:

• Võimalus pääseda erinevatele rakendustele ja teenustele ühekordse autentimise kaudu.
• Kui kasutajaprofiilides puuduvad mitmed vajalikud atribuudid, on võimalik andmete täiendamine, sealhulgas automatiseeritult ja „reaalajas“.
• Pole vajalik aktiveeritud sessioonide teabe säilitamine, serverirakendus peab lihtsalt kontrollima allkirja.
• Paindlikum juurdepääsuhaldus lisatud atribuutide kaudu kannetes.
• Tokeni allkirja rakendamine päises ja kasulikus koormuses suurendab lahenduse üldist turvalisust.

JWT token — koostis

Päis — vaikimisi sisaldab päis vaid tokeni tüüpi ja algoritmi, mis on kasutusel krüptimiseks.

Tokeni tüüp salvestatakse võtmes „typ“. Võtit „typ“ ignoreeritakse JWT-s. 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 algoritmi, mis on kasutusel tokeni krüptimiseks. Vaikimisi peab see olema seatud HS256. Päis kodeeritakse base64.

{ "alg": "HS256", "typ": "JWT" }
Payload (sisu) — koormas hoitakse igasugust teavet, mida on vaja kontrollida. Iga võtme nimi koormas tuntakse kui „deklaratsioon”. Näiteks saab rakendusse siseneda ainult kutsega (suletud kampaania). Kui soovime kedagi osalema kutsuda, saadame talle kutse. Oluline on kontrollida, et e-posti aadress kuulub kutset vastu võtvale isikule, seetõttu lisame selle aadressi koormasse, salvestades selle võtmesse „e-mail”.

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

Koormas olevad võtmed võivad olla suvalised. Siiski on mõned reserveeritud:

• iss (Issuer) — määratleb rakenduse, kust token saadetakse.
• sub (Subject) — määratleb tokeni teema.
• aud (Audience) – juhtumiga tundlikest stringidest või URI-st koosnev massiiv, mis on lõpetajate nimekiri selle tokeni saamiseks. Kui vastuvõtja saab antud võtmega JWT, peab ta kontrollima, kas ta on lõpetajate seas — muidu ignoreeritakse tokenit.
• exp (Aegumistumine) — näitab, millal märgendi kehtivusaeg lõppeb. JWT standard nõuab, et kõikide selle rakenduste kehtetuks muutunud märgid tuleks tagasi lükata. Exp võti peab olema ajatemperatuur unix-format.
• nbf (Ei Enne) — unix-formaadis aeg, mis määrab hetke, mil token muutub kehtivaks.
• iat (Välja Antud Aeg) — see võti esindab aega, mil märgend anti välja ja seda saab kasutada JWT vanuse määramiseks. iat võti peab olema ajatemperatuur unix-format.
• Jti (JWT ID) — string, mis määrab antud tokeni unikaalse identifikaatori, arvestades suur- ja väiketähti.

Oluline on mõista, et kasulikkoormus ei edastata krüpteeritud kujul (kuigi, tokenid võivad olla pesakestes ning siis on võimalik edastada krüpteeritud andmeid). Seetõttu ei saa selle sees hoida mingeid salajasi andmeid. Nagu ka pealkiri, kodeeritakse kasulikkoormus base64.
Allkiri — kui meil on pealkiri ja kasulikkoormus, saame arvutada allkirja.

Base64-s varjatud: päis ja payload ühendatakse punktiga. Seejärel antakse see string ja salajane võti šifreerimise algoritmi, mis on määratud päises (võti „alg”). Võtmena võib kasutada mistahes stringi. Pikemad stringid on eelistatavad, kuna nende lahti harutamine nõuab rohkem aega.

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

Kaheksateistkümnenda võtme jaoks ilma katkestusteta arhitektuuri loomine

Ühe klastriga, mis pärast väljatõstmist alates tehtud projektidest tuleb SSO lahendust kasutada, on nõuded suurenenud. Kui projektide arv on väike, ei ole need nõuded kõikide projektide jaoks kiivalt tajutavad, kuid kasutajate ja integratsioonide arvu suurenedes tõusevad nõuded kättesaadavusele ja jõudlusele.

Ühtse SSO rikkumisriskide suurenemine tõstab lahenduse arhitektuuri ja kasutatavate komponentide varukoopia meetodite nõudmisi, tuues kaasa väga range SLA. Seetõttu on tõenäolisem, et lahenduste arendamise või varajases rakendamisfaasis on projektidel oma mitte-ei-rafika infrastruktuur. Arengu käigus tuleb sisse ehitada arendamise ja laiendamise võimalused. Kõige paindlikum on ehitada katkestusteta klaster konteinerite virtualiseerimise või hübriidse lähenemise abil.

Active/Active ja Active/Passive klasterežiimide tööks on vajalik tagada andmete järjepidevus relatsioonilises andmebaasis – mõlemad andmebaasi sõlmed peavad olema erinevate geograafiliste andmekeskuste vahel sünkroonselt replitseeritud.

Lihtsaim katkestusteta installatsiooni näide.

Millised on ühtse klustru kasutamise eelised:

• Kõrge kättesaadavus ja jõudlus.
• Töörežiimide toetamine: Active/Active, Active/Passive.
• Dünaamilise skaleerimise võimalus — konteinerite virtualiseerimise kasutamisel.
• Tsentraliseeritud halduse ja jälgimise võimalus.
• Üksne lähenemine kasutajate tuvastamiseks/autentimiseks/autoriseerimiseks projektides.
• Selgem koostöö erinevate projektide vahel ilma kasutajate osaluseta.
• Võimalus jagada JWT tokenit erinevates projektides.
• Üksne usalduspunkt.
• Kiirem projektide käivitamine mikroteenuste/konteinervirtualiseerimise abil (ei ole vaja täiendavate komponentide ülesseadmist ja konfigureerimist).
• Võimalik osta kaubanduslikku tuge tootjalt.

Millele tähelepanu pöörata klastrit planeerides

ANDMEBAASIDE haldamiseks.

Keycloak kasutab andmehalduse süsteemi realmide, klientide, kasutajate jms salvestamiseks.
Toetatakse suurt valikut andmebaasidüsteeme: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak on varustatud oma sisseehitatud relatsioonilise andmebaasiga. Soovitatav kasutada madala koormusega keskkondades, nagu arenduskeskkonnad.

Active/Active ja Active/Passive klasstri tööks on vajalik andmete järjepidevuse tagamine relatsioonilises andmebaasis ning mõlemad andmebaasi klastriga sõlmed replikatakse sünkroonselt andmekeskuste vahel.

Jaotatud vahemälu (Infinispan)

Klasteri nõuetekohaseks toimimiseks on vajalik täiendav sünkroniseerimine järgmiste vahemälu tüüpidega, kasutades JBoss Data Grid:

Autentimisistungid — kasutatakse konkreetse kasutaja autentimise andmete salvestamiseks. Selle vahemälu päringud hõlmavad tavaliselt ainult veebibrauserit ja Keycloak serverit, mitte rakendust.

Tegevusmargid — kasutatakse stsenaariumides, kus kasutaja peab toimingu kinnitama asünkroonselt (e-posti teel). Näiteks parooli unustamise voos kasutatakse actionTokens vahemälu Infinispan, et jälgida seotud tegevusmärkide metaandmeid, mis on juba kasutatud, seetõttu ei saa neid uuesti kasutada.

Püsiva andmete vahemälu ja tühistamine – kasutatakse püsivate andmete vahemällu salvestamiseks, et vältida liigseid päringuid andmebaasile. Kui mõni Keycloak server värskendab andmeid, peavad kõik ülejäänud Keycloak serverid kõigis andmekeskustes sellest teadma.

Töö — kasutatakse ainult teate edastamiseks tühistamisest klastris sõlmede ja andmekeskuste vahel.

Kasutaja seansid — kasutatakse selleks, et salvestada andmeid kasutaja seansist, mis on kehtivad kasutaja brauseri seansi jooksul. Vahemälu peab töötlema lõppkasutaja ja rakenduse HTTP-päringuid.

Jõhkrate rünnakute kaitse — kasutatakse, et jälgida andmeid ebaõnnestunud sissetuleku katsetest.

Koormuse jaotamine

Koormuse jaotaja on keycloaki ainus sisenemispunkt ja see peab toetama liigseid seansse.

Rakenduste serverid

Kasutatakse komponentide omavahelise suhtluse kontrollimiseks ning need võivad olla virtualiseeritud või konteineriseeritud, kasutades olemasolevaid automatiseerimise vahendeid ja infrastruktuuri dünaamilist skaleerimist. Kõige levinumad juurutusskeemid OpenShiftis, Kubernates, Rancheris.

Sellega on esimene osa – teoreetiline — lõpetatud. Järgmistes artiklite tsüklites käsitletakse erinevate identiteedi pakkujatega integreerimise näiteid ja seadistuse näiteid.

Allikas: habr.com