Í hvaða stóru fyrirtæki sem er, og X5 Retail Group er engin undantekning þar sem það þróast, fjölgar verkefnum sem krefjast notendaheimildar. Með tímanum þarf óaðfinnanlegur umskipti notenda úr einu forriti í annað og þá er þörf á að nota einn Single-Sing-On (SSO) netþjón. En hvað um þegar auðkennisveitendur eins og AD eða aðrir sem ekki hafa viðbótareiginleika eru þegar notaðir í ýmsum verkefnum. Flokkur kerfa sem kallast „auðkenningarmiðlarar“ mun koma til bjargar. Hagnýtust eru fulltrúar þess, svo sem Keycloak, Gravitee Access stjórnun o.fl. Oftast geta notkunartilvik verið mismunandi: vélræn samskipti, þátttaka notenda osfrv. Lausnin verður að styðja sveigjanlegan og stigstærðan virkni sem getur sameinað allar kröfur í einu, og slíkar lausnir hefur fyrirtækið okkar nú vísbendingamiðlara - Keycloak.
Keycloak er opinn auðkennis- og aðgangsstýringarvara sem er viðhaldið af RedHat. Það er grundvöllur þess að vörur fyrirtækisins noti SSO - RH-SSO.
Grunnhugtök
Áður en þú byrjar að takast á við lausnir og nálganir ættir þú að ákveða hvað varðar skilmála og röð ferla:
Auðkenning er aðferð til að þekkja einstakling með auðkenni hans (með öðrum orðum, þetta er skilgreining á nafni, innskráningu eða númeri).
Auðkenning - þetta er auðkenningarferli (notandinn er athugaður með lykilorði, bréfið er athugað með rafrænni undirskrift osfrv.)
Innskráning - þetta er að veita aðgang að auðlind (til dæmis að tölvupósti).
Identity Broker Keycloak
lyklaklæði er opinn auðkennis- og aðgangsstjórnunarlausn hönnuð til notkunar í IS þar sem hægt er að nota smáþjónustuarkitektúrmynstur.
Keycloak býður upp á eiginleika eins og staka innskráningu (SSO), miðlað auðkenni og félagslega innskráningu, notendasamband, millistykki fyrir viðskiptavini, stjórnborð og stjórnborð reikninga.
Grunnvirkni studd af Keycloak:
- Single-Sign On og Single-Sign Out fyrir vafraforrit.
- Stuðningur við OpenID/OAuth 2.0/SAML.
- Auðkennismiðlun – auðkenning með ytri OpenID Connect eða SAML auðkennisveitur.
- Félagsleg innskráning – stuðningur við Google, GitHub, Facebook, Twitter til að auðkenna notanda.
- User Federation - samstilling notenda frá LDAP og Active Directory netþjónum og öðrum auðkennisveitum.
- Kerberos brú - með Kerberos netþjóni fyrir sjálfvirka auðkenningu notenda.
- Stjórnborð - fyrir samræmda stjórnun stillinga og lausnarmöguleika í gegnum vefinn.
- Account Management Console - fyrir sjálfstjórn á notendasniðinu.
- Sérsníða lausnarinnar út frá auðkenni fyrirtækisins.
- 2FA Authentication - TOTP/HOTP stuðningur með því að nota Google Authenticator eða FreeOTP.
- Innskráningarflæði - sjálfsskráning notenda, endurheimt og endurstilling lykilorðs og fleira er mögulegt.
- Fundarstjórnun - stjórnendur geta stjórnað notendalotum frá einum stað.
- Token Mappers - bindur notendaeiginleika, hlutverk og aðra nauðsynlega eiginleika við tákn.
- Sveigjanleg stefnustjórnun þvert á svið, forrit og notendur.
- CORS stuðningur - Viðskiptavinamillistykki eru með innbyggðan CORS stuðning.
- Þjónustuveituviðmót (SPI) - Mikill fjöldi SPI sem gerir þér kleift að sérsníða ýmsa þætti þjónsins: auðkenningarflæði, auðkennisveitur, samskiptakortlagningu og fleira.
- Viðskiptavinamillistykki fyrir JavaScript forrit, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Stuðningur við að vinna með ýmis forrit sem styðja OpenID Connect Relying Party bókasafnið eða SAML 2.0 Service Provider Library.
- Stækkanlegt með viðbótum.
Fyrir CI/CD ferla, sem og sjálfvirkni stjórnunarferla í Keycloak, er hægt að nota REST API/JAVA API. Skjöl eru fáanleg rafrænt:
REST API
Java API
Fyrirtæki auðkennisveitur (á staðnum)
Geta til að auðkenna notendur í gegnum User Federation þjónustu.
Einnig er hægt að nota gegnumgangsauðkenningu - ef notendur auðkenna á vinnustöðvum með Kerberos (LDAP eða AD), þá er hægt að auðkenna þá sjálfkrafa til Keycloak án þess að þurfa að slá inn notandanafn og lykilorð aftur.
Til auðkenningar og frekari heimilda notenda er hægt að nota venslakerfiskerfi sem á best við fyrir þróunarumhverfi þar sem það felur ekki í sér langar stillingar og samþættingar á fyrstu stigum verkefna. Sjálfgefið er að Keycloak notar innbyggt DBMS til að geyma stillingar og notendagögn.
Listinn yfir studd DBMS er umfangsmikill og inniheldur: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle og fleiri. Mest prófað hingað til eru Oracle 12C Release1 RAC og Galera 3.12 þyrping fyrir MariaDB 10.1.19.
Auðkennisveitendur - félagsleg innskráning
Það er hægt að nota innskráningu frá samfélagsnetum. Til að virkja getu til að auðkenna notendur, notaðu Keycloack stjórnborðið. Breytingar á forritskóðanum eru ekki nauðsynlegar og þessi virkni er fáanleg strax og hægt er að virkja hana á hvaða stigi verkefnisins sem er.
Það er hægt að nota OpenID/SAML Identity veitendur fyrir notendavottun.
Dæmigerð heimildaratburðarás með OAuth2 í Keycloak
Heimildarkóðaflæði - notað með forritum á netþjóni. Ein algengasta tegund heimildarheimilda vegna þess að hún hentar vel fyrir netþjónaforrit þar sem frumkóði og biðlaragögn eru ekki aðgengileg utanaðkomandi. Ferlið í þessu tilfelli er byggt á tilvísun. Forritið verður að geta átt samskipti við notendaumboðsmann (notendaumboðsmann), eins og vafra - til að fá API heimildarkóða sem vísað er áfram í gegnum notendaumboðsmanninn.
óbeint flæði - notað af farsíma- eða vefforritum (forrit sem keyra á tæki notandans).
Gerð óbeinrar heimildarheimildar er notuð af farsíma- og vefforritum þar sem ekki er hægt að tryggja trúnað viðskiptavina. Óbeina heimildargerðin notar einnig tilvísun notendaumboðsmanns, þar sem aðgangslykillinn er færður til notendafulltrúans til frekari notkunar í forritinu. Þetta gerir táknið aðgengilegt fyrir notandann og önnur forrit á tæki notandans. Þessi tegund af heimildarheimild staðfestir ekki auðkenni forritsins og ferlið sjálft byggir á tilvísunarslóð (áður skráð hjá þjónustunni).
Implicit Flow styður ekki endurnýjunartákn fyrir aðgangslykil.
Viðskiptavinaskilríki Grant Flow — eru notuð þegar forritið opnar API. Þessi tegund heimildarheimilda er venjulega notuð fyrir samskipti miðlara til netþjóns sem þarf að framkvæma í bakgrunni án tafarlausra notendaviðskipta. Skilríkisstyrkstreymi viðskiptavinar gerir vefþjónustu (trúnaðarviðskiptavini) kleift að nota eigin skilríki í stað þess að líkja eftir notanda til að auðkenna þegar hringt er í aðra vefþjónustu. Fyrir hærra öryggisstig er mögulegt fyrir símaþjónustuna að nota vottorð (í stað sameiginlegs leyndarmáls) sem skilríki.
OAuth2 forskriftinni er lýst í
JWT tákn og kostir þess
JWT (JSON Web Token) er opinn staðall () sem skilgreinir þétta og sjálfstæða leið til að flytja upplýsingar á öruggan hátt milli aðila sem JSON hlut.
Samkvæmt staðlinum samanstendur tákn af þremur hlutum á grunn-64 sniði, aðskilið með punktum. Fyrsti hlutinn er kallaður hausinn, sem inniheldur tegund tákns og heiti kjötkássa reikniritsins til að fá stafrænu undirskriftina. Seinni hlutinn geymir grunnupplýsingarnar (notanda, eiginleika osfrv.). Þriðji hlutinn er stafræna undirskriftin.
. .
Geymdu aldrei tákn í DB þinn. Vegna þess að gilt tákn jafngildir lykilorði, er það að geyma táknið eins og að geyma lykilorðið í skýrum texta.
Aðgangslykill er tákn sem veitir eiganda sínum aðgang að öruggum miðlaraauðlindum. Það hefur venjulega stuttan líftíma og getur borið viðbótarupplýsingar eins og IP tölu þess aðila sem biður um táknið.
Endurnýja tákn er tákn sem gerir viðskiptavinum kleift að biðja um nýja aðgangslykil eftir að líftími þeirra er útrunninn. Þessi tákn eru venjulega gefin út í langan tíma.
Helstu kostir þess að nota í örþjónustuarkitektúr:
- Geta til að fá aðgang að ýmsum forritum og þjónustu með einu sinni auðkenningu.
- Ef ekki er um að ræða fjölda nauðsynlegra eiginleika í notendasniðinu er hægt að auðga með gögnum sem hægt er að bæta við farminn, þar með talið sjálfvirkt og á flugi.
- Það er engin þörf á að geyma upplýsingar um virkar lotur; netþjónaforritið þarf aðeins að staðfesta undirskriftina.
- Sveigjanlegri aðgangsstýring með viðbótareiginleikum í hleðslu.
- Notkun táknundirskriftar fyrir haus og hleðslu eykur öryggi lausnarinnar í heild.
JWT tákn - samsetning
Titill - sjálfgefið inniheldur hausinn aðeins tegund táknsins og reikniritið sem notað er fyrir dulkóðun.
Tegund táknsins er geymd í "typ" lyklinum. „Týpu“ lykillinn er hunsaður í JWT. Ef "typ" lykillinn er til staðar, verður gildi hans að vera JWT til að gefa til kynna að þessi hlutur sé JSON Web Token.
Annar lykillinn „alg“ skilgreinir reikniritið sem notað er til að dulkóða táknið. Það ætti að vera stillt á HS256 sjálfgefið. Hausinn er kóðaður í base64.
{ "alg": "HS256", "type": "JWT"}
farmur (innihald) - farmurinn geymir allar upplýsingar sem þarf að athuga. Hver lykill í hleðslunni er þekktur sem "krafa". Til dæmis geturðu aðeins slegið inn umsóknina með boði (lokuð kynning). Þegar við viljum bjóða einhverjum að taka þátt sendum við þeim boðspóst. Það er mikilvægt að ganga úr skugga um að netfangið tilheyri þeim sem þiggur boðið, svo við munum setja þetta netfang með í farminn með því að geyma það í "email" lyklinum.
{ "netfang": "[netvarið]"}
Lyklar í hleðslu geta verið handahófskenndir. Hins vegar eru nokkrar fráteknar:
- iss (útgefandi) - Tilgreinir forritið sem táknið er sent frá.
- undir (Subject) - skilgreinir efni táknsins.
- aud (Audience) er fylki af hástöfumnæmum strengjum eða URI sem er listi yfir viðtakendur þessa tákns. Þegar móttakandinn fær JWT með tilteknum lykli verður hún að athuga hvort hann sé til staðar í viðtakendum - annars hunsa táknið.
- exp (Expiration Time) - Gefur til kynna hvenær táknið rennur út. JWT staðallinn krefst þess að allar útfærslur hans hafni útrunnum táknum. Exp lykillinn verður að vera tímastimpill á unix sniði.
- nbf (Not Before) er tími á unix sniði sem ákvarðar augnablikið þegar táknið verður gilt.
- iat (útgefið á) - Þessi lykill táknar tímann sem táknið var gefið út og hægt er að nota til að ákvarða aldur JWT. iat lykillinn verður að vera tímastimpill á unix sniði.
- Jti (JWT ID) — strengur sem skilgreinir einkvæmt auðkenni þessa auðkennis, hástöfum.
Mikilvægt er að skilja að farmálagið er ekki sent á dulkóðuðu formi (þó hægt sé að hreiða tákn og þá er hægt að senda dulkóðuð gögn). Þess vegna getur það ekki geymt neinar leynilegar upplýsingar. Eins og hausinn er farmurinn base64 kóðaður.
Undirskrift - þegar við höfum titil og hleðslu, getum við reiknað út undirskriftina.
Hausinn og hleðslan sem eru kóðuð í base64 eru tekin og sameinuð í línu sem er aðskilin með punkti. Þessi strengur og leynilykillinn eru síðan settur inn í dulkóðunaralgrímið sem tilgreint er í hausnum (lykill „alg“). Lykillinn getur verið hvaða strengur sem er. Lengri strengir eru ákjósanlegastir þar sem þeir þurfa lengri tíma til að velja.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Að byggja upp Keycloak Failover Cluster Architecture
Þegar einn klasi er notaður fyrir öll verkefni eru auknar kröfur um SSO lausn. Þegar verkefnafjöldinn er lítill eru þessar kröfur ekki svo áberandi fyrir öll verkefni, en með fjölgun notenda og samþættingum aukast kröfur um framboð og frammistöðu.
Aukin hætta á stakri SSO bilun eykur kröfurnar til lausnararkitektúrsins og aðferðirnar sem notaðar eru fyrir óþarfa íhluti og leiðir til mjög þétts SLA. Í þessu sambandi, oftar á þróunarstigi eða fyrstu stigum innleiðingar lausna, hafa verkefni sín eigin innviði sem þolir ekki galla. Eftir því sem líður á þróunina þarf að leggja fram tækifæri til þróunar og stækkunar. Það er sveigjanlegast að byggja upp bilunarklasa með því að nota gámasýndarvæðingu eða blendingaaðferð.
Til að vinna í virkum/virkum og virkum/óvirkum klasahamum þarf að tryggja samræmi gagna í venslagagnagrunni - báðir gagnagrunnshnútar verða að vera samstilltir afritaðir á milli mismunandi landdreifðra gagnavera.
Einfaldasta dæmið um bilunarþolna uppsetningu.
Hverjir eru kostir þess að nota einn klasa:
- Mikið framboð og afköst.
- Stuðningur við rekstrarhami: Virkur / Virkur, Virkur / Óvirkur.
- Geta til að stækka á virkan hátt - þegar sýndarvæðing íláts er notuð.
- Möguleiki á miðlægri stjórnun og eftirliti.
- Samræmd nálgun til auðkenningar/auðkenningar/heimildar notenda í verkefnum.
- Gagnsærra samspil ólíkra verkefna án aðkomu notenda.
- Hæfni til að endurnýta JWT táknið í ýmsum verkefnum.
- Einn traustspunktur.
- Hraðari ræsingu verkefna með því að nota örþjónustu/gáma sýndarvæðingu (engin þörf á að lyfta og stilla viðbótaríhluti).
- Hægt er að kaupa viðskiptastuðning frá seljanda.
Hvað á að leita að þegar þú skipuleggur klasa
DBMS
Keycloak notar gagnagrunnsstjórnunarkerfi til að geyma: ríki, viðskiptavini, notendur osfrv.
Fjölbreytt úrval af DBMS er stutt: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak kemur með sinn eigin innbyggða tengslagagnagrunn. Mælt er með því að nota fyrir óhlaðna umhverfi - eins og þróunarumhverfi.
Til að vinna í virkum/virkum og virkum/óvirkum klasahamum þarf gagnasamkvæmni í tengslagagnagrunni og báðir gagnagrunnsklasahnútar eru samstilltir afritaðir á milli gagnavera.
Dreift skyndiminni (Infinspan)
Til að þyrpingin virki rétt þarf viðbótarsamstilling á eftirfarandi gerðum skyndiminni með því að nota JBoss Data Grid:
Auðkenningarlotur - notað til að vista gögn þegar tiltekinn notandi er auðkenndur. Beiðnir úr þessu skyndiminni innihalda venjulega aðeins vafrann og Keycloak netþjóninn, ekki forritið.
Aðgerðartákn eru notuð fyrir aðstæður þar sem notandinn þarf að staðfesta aðgerð ósamstillt (með tölvupósti). Til dæmis, meðan á gleymsku lykilorði stendur, er actionTokens Infinispan skyndiminni notað til að halda utan um lýsigögn um tengd aðgerðartákn sem þegar hafa verið notuð, svo það er ekki hægt að endurnýta það.
Skyndiminni og ógilding viðvarandi gagna - notað til að vista viðvarandi gögn til að forðast óþarfa fyrirspurnir í gagnagrunninn. Þegar einhver Keycloak netþjónn uppfærir gögnin þurfa allir aðrir Keycloak netþjónar í öllum gagnaverum að vita um það.
Vinna - Aðeins notað til að senda ógild skilaboð á milli klasahnúta og gagnavera.
Notendalotur - notað til að geyma gögn notendalotu sem gilda á meðan vafralotu notandans stendur yfir. Skyndiminni verður að vinna úr HTTP beiðnum frá notandanum og forritinu.
Brute force vernd – notuð til að rekja gögn um misheppnaða innskráningu.
Álagsjöfnun
Hleðslujafnari er eini inngangsstaðurinn að keycloak og verður að styðja við klístraðar lotur.
Umsóknarþjónar
Þau eru notuð til að stjórna samspili íhluta sín á milli og hægt er að gera þau sýnd eða í gáma með því að nota núverandi sjálfvirkniverkfæri og kraftmikla mælikvarða sjálfvirkniverkfæra innviða. Algengustu dreifingarsviðsmyndirnar í OpenShift, Kubernates, Rancher.
Þar með lýkur fyrsta hlutanum - þeim fræðilega. Í næstu greinaröð verða greind dæmi um samþættingu við ýmsa auðkennisveitur og dæmi um stillingar.
Heimild: www.habr.com