Mewn unrhyw gwmni mawr, ac nid yw X5 Retail Group yn eithriad, wrth iddo ddatblygu, mae nifer y prosiectau sydd angen awdurdodiad defnyddwyr yn cynyddu. Dros amser, mae angen trosglwyddo defnyddwyr yn ddi-dor o un rhaglen i'r llall, ac yna mae angen defnyddio un gweinydd Un-Sing-On (SSO). Ond beth am pan fydd darparwyr hunaniaeth fel AD neu eraill nad oes ganddynt rinweddau ychwanegol eisoes yn cael eu defnyddio mewn amrywiol brosiectau. Bydd dosbarth o systemau o'r enw "broceriaid adnabod" yn dod i'r adwy. Y rhai mwyaf swyddogaethol yw ei gynrychiolwyr, megis Keycloak, rheoli Mynediad Gravitee, ac ati Yn fwyaf aml, gall achosion defnydd fod yn wahanol: rhyngweithio peiriant, cyfranogiad defnyddwyr, ac ati Rhaid i'r ateb gefnogi ymarferoldeb hyblyg a graddadwy a all gyfuno'r holl ofynion mewn un, ac atebion o'r fath bellach mae gan ein cwmni frocer arwydd - Keycloak.
Mae Keycloak yn gynnyrch hunaniaeth ffynhonnell agored a rheoli mynediad a gynhelir gan RedHat. Mae'n sail i gynnyrch y cwmni ddefnyddio SSO - RH-SSO.
Cysyniadau sylfaenol
Cyn i chi ddechrau delio â datrysiadau a dulliau, dylech benderfynu yn nhermau a dilyniant prosesau:
Adnabod yn weithdrefn ar gyfer adnabod gwrthrych wrth ei ddynodwr (mewn geiriau eraill, dyma'r diffiniad o enw, mewngofnodi neu rif).
Dilysu - gweithdrefn ddilysu yw hon (mae'r defnyddiwr yn cael ei wirio â chyfrinair, mae'r llythyr yn cael ei wirio gyda llofnod electronig, ac ati)
Awdurdodi - hyn yw darparu mynediad i adnodd (er enghraifft, e-bost).
Cloak Cloak Brocer Hunaniaeth
clogyn yn ddatrysiad rheoli mynediad a hunaniaeth ffynhonnell agored a ddyluniwyd i'w ddefnyddio yn GG lle gellir defnyddio patrymau pensaernïaeth microwasanaeth.
Mae Keycloak yn cynnig nodweddion fel mewngofnodi sengl (SSO), hunaniaeth froceredig a mewngofnodi cymdeithasol, ffederasiwn defnyddwyr, addaswyr cleientiaid, consol gweinyddol a chonsol rheoli cyfrifon.
Swyddogaeth sylfaenol a gefnogir gan Keycloak:
- Arwyddo Sengl ac Sengl-Allgofnodi ar gyfer cymwysiadau porwr.
- Cefnogaeth i OpenID / OAuth 2.0 / SAML.
- Broceru Hunaniaeth - dilysu gan ddefnyddio darparwyr hunaniaeth allanol OpenID Connect neu SAML.
- Mewngofnodi Cymdeithasol - Cefnogaeth Google, GitHub, Facebook, Twitter ar gyfer adnabod defnyddwyr.
- Ffederasiwn Defnyddwyr - cydamseru defnyddwyr o weinyddion LDAP a Active Directory a darparwyr hunaniaeth eraill.
- Pont Kerberos - defnyddio gweinydd Kerberos ar gyfer dilysu defnyddwyr yn awtomatig.
- Consol Gweinyddol - ar gyfer rheolaeth unedig o osodiadau ac opsiynau datrysiadau trwy'r We.
- Consol Rheoli Cyfrif - ar gyfer hunanreoli proffil y defnyddiwr.
- Addasu'r datrysiad yn seiliedig ar hunaniaeth gorfforaethol y cwmni.
- Dilysu 2FA - Cefnogaeth TOTP/HOTP gan ddefnyddio Google Authenticator neu FreeOTP.
- Llifau Mewngofnodi - hunan-gofrestru defnyddiwr, adfer cyfrinair ac ailosod, ac eraill yn bosibl.
- Rheoli Sesiynau - gall gweinyddwyr reoli sesiynau defnyddwyr o un pwynt.
- Mapwyr Tocynnau - priodoleddau defnyddiwr rhwymol, rolau a phriodoleddau gofynnol eraill i docynnau.
- Rheoli polisi hyblyg ar draws y maes, cymhwysiad a defnyddwyr.
- Cefnogaeth CORS - Mae gan addaswyr cleient gefnogaeth CORS wedi'i hymgorffori.
- Rhyngwynebau Darparwr Gwasanaeth (SPI) - Nifer fawr o SPIau sy'n eich galluogi i addasu gwahanol agweddau ar y gweinydd: llifau dilysu, darparwyr hunaniaeth, mapio protocol, a mwy.
- Addaswyr cleient ar gyfer cymwysiadau JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Cefnogaeth ar gyfer gweithio gyda rhaglenni amrywiol sy'n cefnogi llyfrgell OpenID Connect Relying Party neu Lyfrgell Darparwr Gwasanaeth SAML 2.0.
- Gellir ei ehangu gan ddefnyddio ategion.
Ar gyfer prosesau CI / CD, yn ogystal ag awtomeiddio prosesau rheoli yn Keycloak, gellir defnyddio'r API REST / JAVA API. Mae dogfennau ar gael yn electronig:
REST API
Java API
Darparwyr Hunaniaeth Menter (Ar y Safle)
Y gallu i ddilysu defnyddwyr trwy wasanaethau Ffederasiwn Defnyddwyr.
Gellir defnyddio dilysiad pasio drwodd hefyd - os yw defnyddwyr yn dilysu yn erbyn gweithfannau gyda Kerberos (LDAP neu AD), yna gellir eu dilysu'n awtomatig i Keycloak heb orfod nodi eu henw defnyddiwr a'u cyfrinair eto.
Ar gyfer dilysu ac awdurdodi defnyddwyr ymhellach, mae'n bosibl defnyddio DBMS perthynol, sydd fwyaf perthnasol ar gyfer amgylcheddau datblygu, gan nad yw'n cynnwys gosodiadau ac integreiddiadau hirfaith yng nghamau cynnar prosiectau. Yn ddiofyn, mae Keycloak yn defnyddio DBMS adeiledig i storio gosodiadau a data defnyddwyr.
Mae'r rhestr o DBMS a gefnogir yn helaeth ac yn cynnwys: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle ac eraill. Y rhai a brofwyd fwyaf hyd yn hyn yw Oracle 12C Release1 RAC a chlwstwr Galera 3.12 ar gyfer MariaDB 10.1.19.
Darparwyr hunaniaeth - mewngofnodi cymdeithasol
Mae'n bosibl defnyddio mewngofnodi o rwydweithiau cymdeithasol. I actifadu'r gallu i ddilysu defnyddwyr, defnyddiwch y consol gweinyddol Keycloack. Nid oes angen newidiadau yn y cod cais ac mae'r swyddogaeth hon ar gael allan o'r bocs a gellir ei actifadu ar unrhyw gam o'r prosiect.
Mae'n bosibl defnyddio darparwyr OpenID/SAML Identity ar gyfer dilysu defnyddwyr.
Senarios awdurdodi nodweddiadol gan ddefnyddio OAuth2 yn Keycloak
Llif Cod Awdurdodi - ei ddefnyddio gyda chymwysiadau ochr y gweinydd. Un o'r mathau mwyaf cyffredin o ganiatâd awdurdodi oherwydd ei fod yn addas iawn ar gyfer cymwysiadau gweinydd lle nad yw cod ffynhonnell a data cleient y rhaglen ar gael i bobl o'r tu allan. Mae'r broses yn yr achos hwn yn seiliedig ar ailgyfeirio. Rhaid i'r rhaglen allu rhyngweithio ag asiant defnyddiwr (asiant defnyddiwr), megis porwr gwe - i dderbyn codau awdurdodi API sy'n cael eu hailgyfeirio trwy'r asiant defnyddiwr.
llif ymhlyg - a ddefnyddir gan gymwysiadau symudol neu we (cymwysiadau sy'n rhedeg ar ddyfais y defnyddiwr).
Defnyddir y math o ganiatâd awdurdodi ymhlyg gan gymwysiadau symudol a gwe lle na ellir gwarantu cyfrinachedd cleient. Mae'r math o ganiatâd ymhlyg hefyd yn defnyddio ailgyfeirio asiant defnyddiwr, lle mae'r tocyn mynediad yn cael ei drosglwyddo i'r asiant defnyddiwr i'w ddefnyddio ymhellach yn y rhaglen. Mae hyn yn sicrhau bod y tocyn ar gael i'r defnyddiwr a chymwysiadau eraill ar ddyfais y defnyddiwr. Nid yw'r math hwn o ganiatâd awdurdodi yn dilysu hunaniaeth y cais, ac mae'r broses ei hun yn dibynnu ar URL ailgyfeirio (a gofrestrwyd yn flaenorol gyda'r gwasanaeth).
Nid yw Implicit Flow yn cefnogi tocynnau adnewyddu tocyn mynediad.
Llif Grant Manylion Cleient - yn cael eu defnyddio pan fydd y rhaglen yn cyrchu'r API. Mae'r math hwn o ganiatâd awdurdodi yn cael ei ddefnyddio fel arfer ar gyfer rhyngweithiadau gweinydd-i-weinydd y mae'n rhaid eu perfformio yn y cefndir heb ryngweithio defnyddiwr ar unwaith. Mae llif grant tystlythyrau cleient yn caniatáu i wasanaeth gwe (cleient cyfrinachol) ddefnyddio ei rinweddau ei hun yn hytrach na dynwared defnyddiwr i ddilysu wrth ffonio gwasanaeth gwe arall. Ar gyfer lefel uwch o ddiogelwch, mae'n bosibl i'r gwasanaeth galw ddefnyddio tystysgrif (yn hytrach na chyfrinach a rennir) fel cymhwyster.
Disgrifir y fanyleb OAuth2 yn
Tocyn JWT a'i fanteision
Mae JWT (JSON Web Token) yn safon agored () sy'n diffinio ffordd gryno a hunangynhwysol o drosglwyddo gwybodaeth yn ddiogel rhwng partïon fel gwrthrych JSON.
Yn ôl y safon, mae'r tocyn yn cynnwys tair rhan ar ffurf sylfaen-64, wedi'u gwahanu gan ddotiau. Gelwir y rhan gyntaf yn bennawd, sy'n cynnwys y math o docyn ac enw'r algorithm hash ar gyfer cael llofnod digidol. Mae'r ail ran yn storio'r wybodaeth sylfaenol (defnyddiwr, priodoleddau, ac ati). Y drydedd ran yw'r llofnod digidol.
. .
Peidiwch byth â storio tocyn yn eich DB. Oherwydd bod tocyn dilys yn cyfateb i gyfrinair, mae storio'r tocyn fel storio'r cyfrinair mewn testun clir.
Tocyn mynediad yn arwydd sy'n rhoi mynediad i'w berchennog i adnoddau gweinydd diogel. Fel arfer mae ganddo oes fer a gall gynnwys gwybodaeth ychwanegol megis cyfeiriad IP y parti sy'n gofyn am y tocyn.
Tocyn adnewyddu yn tocyn sy'n galluogi cleientiaid i ofyn am docynnau mynediad newydd ar ôl i'w hoes ddod i ben. Mae'r tocynnau hyn fel arfer yn cael eu cyhoeddi am gyfnod hir.
Prif fanteision defnyddio mewn pensaernïaeth microwasanaeth:
- Y gallu i gael mynediad at amrywiol gymwysiadau a gwasanaethau trwy ddilysu un-amser.
- Yn absenoldeb nifer o briodoleddau gofynnol yn y proffil defnyddiwr, mae'n bosibl cyfoethogi â data y gellir ei ychwanegu at y llwyth tâl, gan gynnwys awtomataidd ac ar-y-hedfan.
- Nid oes angen storio gwybodaeth am sesiynau gweithredol, dim ond y llofnod sydd ei angen ar raglen y gweinydd.
- Rheoli mynediad mwy hyblyg trwy briodoleddau ychwanegol yn y llwyth tâl.
- Mae defnyddio llofnod tocyn ar gyfer y pennawd a'r llwyth tâl yn cynyddu diogelwch y datrysiad cyfan.
Tocyn JWT - cyfansoddiad
Teitl - yn ddiofyn, dim ond y math o docyn a'r algorithm a ddefnyddir ar gyfer amgryptio y mae'r pennawd yn ei gynnwys.
Mae math y tocyn yn cael ei storio yn yr allwedd "teip". Mae'r allwedd 'math' yn cael ei hanwybyddu yn y JWT. Os yw'r allwedd "tip" yn bresennol, rhaid i'w werth fod yn JWT i nodi mai Tocyn Gwe JSON yw'r gwrthrych hwn.
Mae'r ail allwedd "alg" yn diffinio'r algorithm a ddefnyddir i amgryptio'r tocyn. Dylid ei osod i HS256 yn ddiofyn. Mae'r pennawd wedi'i amgodio yn base64.
{ " alg " : " HS256 " , " type " : " JWT " }
llwyth tâl (cynnwys) - mae'r llwyth tâl yn storio unrhyw wybodaeth y mae angen ei gwirio. Gelwir pob allwedd yn y llwyth tâl yn "hawliad". Er enghraifft, dim ond trwy wahoddiad y gallwch chi nodi'r cais (hyrwyddiad caeedig). Pan fyddwn am wahodd rhywun i gymryd rhan, rydym yn anfon llythyr gwahoddiad atynt. Mae'n bwysig gwirio bod y cyfeiriad e-bost yn perthyn i'r person sy'n derbyn y gwahoddiad, felly byddwn yn cynnwys y cyfeiriad hwn yn y llwyth tâl, ar gyfer hyn rydym yn ei storio yn yr allwedd "e-bost"
{ "e-bost": "[e-bost wedi'i warchod]" }
Gall allweddi yn y llwyth tâl fod yn fympwyol. Fodd bynnag, mae yna rai neilltuedig:
- iss (Cyhoeddwr) - Yn nodi'r cais y mae'r tocyn yn cael ei anfon ohono.
- sub (Pwnc) - yn diffinio pwnc y tocyn.
- Mae aud (Cynulleidfa) yn amrywiaeth o linynnau achos-sensitif neu URIs sy'n rhestr o dderbynwyr y tocyn hwn. Pan fydd yr ochr sy'n derbyn yn derbyn JWT gyda'r allwedd a roddir, rhaid iddo wirio am bresenoldeb ei hun yn y derbynwyr - fel arall anwybyddwch y tocyn.
- exp (Amser Dod i Ben) - Yn dynodi pryd y daw'r tocyn i ben. Mae safon JWT yn ei gwneud yn ofynnol i'w holl weithrediadau wrthod tocynnau sydd wedi dod i ben. Rhaid i'r allwedd exp fod yn stamp amser mewn fformat unix.
- Mae nbf (Nid Cyn) yn amser mewn fformat unix sy'n pennu'r foment pan ddaw'r tocyn yn ddilys.
- iat (Cyhoeddwyd At) - Mae'r allwedd hon yn cynrychioli'r amser y cyhoeddwyd y tocyn a gellir ei ddefnyddio i bennu oedran y JWT. Rhaid i'r allwedd iat fod yn stamp amser mewn fformat unix.
- Jti (ID JWT) - llinyn sy'n diffinio dynodwr unigryw'r tocyn hwn, sy'n sensitif i achos.
Mae'n bwysig deall nad yw'r llwyth tâl yn cael ei drosglwyddo ar ffurf wedi'i amgryptio (er y gellir nythu tocynnau ac yna mae'n bosibl trosglwyddo data wedi'i amgryptio). Felly, ni all storio unrhyw wybodaeth gyfrinachol. Fel y pennawd, mae'r llwyth tâl wedi'i amgodio base64.
Llofnod - pan fydd gennym deitl a llwyth tâl, gallwn gyfrifo'r llofnod.
Wedi'i amgodio gan base64: cymerir y pennawd a'r llwyth tâl, cânt eu cyfuno'n llinyn trwy ddot. Yna mae'r llinyn hwn a'r allwedd gyfrinachol yn cael eu mewnbynnu i'r algorithm amgryptio a nodir yn y pennawd (allwedd "alg"). Gall yr allwedd fod yn unrhyw linyn. Bydd llinynnau hirach yn cael eu ffafrio fwyaf gan y bydd yn cymryd mwy o amser i'w codi.
{" alg":"RSA1_5", "llwyth tâl":"A128CBC-HS256"}
Adeiladu Cloak Cloak Pensaernïaeth Clwstwr Methiant
Wrth ddefnyddio un clwstwr ar gyfer pob prosiect, mae gofynion cynyddol am ddatrysiad SSO. Pan fydd nifer y prosiectau yn fach, nid yw'r gofynion hyn mor amlwg ar gyfer pob prosiect, fodd bynnag, gyda chynnydd yn nifer y defnyddwyr ac integreiddiadau, mae'r gofynion ar gyfer argaeledd a pherfformiad yn cynyddu.
Mae cynyddu'r risg o fethiant SSO unigol yn cynyddu'r gofynion ar gyfer pensaernïaeth datrysiadau a'r dulliau a ddefnyddir ar gyfer cydrannau segur ac yn arwain at CLG tynn iawn. Yn hyn o beth, yn amlach yn ystod datblygiad neu gamau cynnar gweithredu datrysiadau, mae gan brosiectau eu seilwaith di-fai eu hunain. Wrth i'r datblygiad fynd rhagddo, mae'n ofynnol gosod cyfleoedd ar gyfer datblygu a graddio. Mae'n fwyaf hyblyg adeiladu clwstwr methu drosodd gan ddefnyddio rhithwiroli cynhwysydd neu ddull hybrid.
Er mwyn gweithio yn y moddau clwstwr Actif/Gweithredol ac Actif/Goddefol, mae'n ofynnol sicrhau cysondeb data mewn cronfa ddata berthynol - rhaid i'r ddau nod cronfa ddata gael eu hailadrodd yn gydamserol rhwng gwahanol ganolfannau data geo-ddosbarthu.
Yr enghraifft symlaf o osodiad sy'n goddef namau.
Beth yw manteision defnyddio un clwstwr:
- Argaeledd a pherfformiad uchel.
- Cefnogaeth ar gyfer dulliau gweithredu: Active / Active, Active / Goddefol.
- Y gallu i raddfa ddynamig - wrth ddefnyddio rhithwiroli cynhwysydd.
- Posibilrwydd o reolaeth a monitro canolog.
- Dull unedig o adnabod/dilysu/awdurdodi defnyddwyr mewn prosiectau.
- Rhyngweithio mwy tryloyw rhwng gwahanol brosiectau heb gynnwys defnyddwyr.
- Y gallu i ailddefnyddio tocyn JWT mewn prosiectau amrywiol.
- Pwynt sengl o ymddiriedaeth.
- Lansio prosiectau yn gyflymach gan ddefnyddio microwasanaethau / rhithwiroli cynhwysydd (nid oes angen codi a ffurfweddu cydrannau ychwanegol).
- Mae'n bosibl prynu cefnogaeth fasnachol gan y gwerthwr.
Beth i chwilio amdano wrth gynllunio clwstwr
DBMS
Mae Keycloak yn defnyddio system rheoli cronfa ddata i storio: meysydd, cleientiaid, defnyddwyr, ac ati.
Cefnogir ystod eang o DBMS: MS SQL, Oracle, MySQL, PostgreSQL. Daw Keycloak gyda'i gronfa ddata berthynol adeiledig ei hun. Argymhellir ei ddefnyddio ar gyfer amgylcheddau heb eu llwytho - megis amgylcheddau datblygu.
I weithio mewn moddau clwstwr Actif/Gweithredol ac Actif/Goddefol, mae angen cysondeb data mewn cronfa ddata berthynol, a chaiff y ddau nod clwstwr cronfa ddata eu hailadrodd yn gydamserol rhwng canolfannau data.
Celc wedi'i ddosbarthu (Infinspan)
Er mwyn i'r clwstwr weithio'n gywir, mae angen cydamseru ychwanegol o'r mathau canlynol o caches gan ddefnyddio Grid Data JBoss:
Sesiynau dilysu - a ddefnyddir i gadw data wrth ddilysu defnyddiwr penodol. Mae ceisiadau o'r storfa hon fel arfer yn cynnwys y porwr a'r gweinydd Keycloak yn unig, nid y rhaglen.
Defnyddir tocynnau gweithredu ar gyfer senarios lle mae angen i'r defnyddiwr gadarnhau gweithred yn anghydamserol (trwy e-bost). Er enghraifft, yn ystod llif anghofio cyfrinair, defnyddir storfa actionTokens Infinispan i gadw golwg ar fetadata am docynnau gweithredu cysylltiedig sydd eisoes wedi'u defnyddio, felly ni ellir ei ailddefnyddio.
Caching ac annilysu data parhaus - a ddefnyddir i storio data parhaus er mwyn osgoi ymholiadau diangen i'r gronfa ddata. Pan fydd unrhyw weinydd Keycloak yn diweddaru'r data, mae angen i bob gweinydd Keycloak arall ym mhob canolfan ddata wybod amdano.
Gwaith - Dim ond yn cael ei ddefnyddio i anfon negeseuon annilys rhwng nodau clwstwr a chanolfannau data.
Sesiynau defnyddwyr - a ddefnyddir i storio data am sesiynau defnyddwyr sy'n ddilys am gyfnod sesiwn porwr y defnyddiwr. Rhaid i'r storfa brosesu ceisiadau HTTP gan y defnyddiwr terfynol a'r rhaglen.
Amddiffyniad grym cryf - a ddefnyddir i olrhain data am fewngofnodi a fethwyd.
Cydbwyso llwyth
Y cydbwysedd llwyth yw'r pwynt mynediad sengl i glogyn bysell a rhaid iddo gefnogi sesiynau gludiog.
Gweinyddion Cais
Fe'u defnyddir i reoli rhyngweithio cydrannau â'i gilydd a gellir eu rhitholi neu eu gosod mewn cynhwysyddion gan ddefnyddio offer awtomeiddio presennol a graddio offer awtomeiddio seilwaith yn ddeinamig. Y senarios defnyddio mwyaf cyffredin yn OpenShift, Kubernates, Rancher.
Mae hyn yn cloi'r rhan gyntaf - yr un ddamcaniaethol. Yn y gyfres nesaf o erthyglau, bydd enghreifftiau o integreiddio â darparwyr hunaniaeth amrywiol ac enghreifftiau o leoliadau yn cael eu dadansoddi.
Ffynhonnell: hab.com