SSO par mikropakalpojumu arhitektūru. Mēs izmantojam Keycloak. Daļa Nr.1

Jebkurā lielā uzņēmumā, un X5 Retail Group nav izņēmums, jo attÄ«stÄ«bas gaitā palielinās projektu skaits, kuriem nepiecieÅ”ama lietotāja autorizācija. Laika gaitā ir nepiecieÅ”ama nemanāma lietotāju pāreja no vienas lietojumprogrammas uz citu, un tad ir jāizmanto viens vienreizējas ieslēgÅ”anas (SSO) serveris. Bet ko darÄ«t, ja dažādos projektos jau tiek izmantoti tādi identitātes nodroÅ”inātāji kā AD vai citi, kuriem nav papildu atribÅ«tu. Sistēmu klase, ko sauc par ā€œidentitātes brokeriemā€, nāks palÄ«gā. Visfunkcionālākie ir tā pārstāvji, piemēram, Keycloak, Gravitee Access pārvaldÄ«ba u.c.. Visbiežāk lietoÅ”anas scenāriji var bÅ«t dažādi: maŔīnu mijiedarbÄ«ba, lietotāju lÄ«dzdalÄ«ba u.c.. Risinājumam jāatbalsta elastÄ«ga un mērogojama funkcionalitāte, kas spēj apvienot visas prasÄ«bas vienā, un tāds risinājums MÅ«su uzņēmumam tagad ir indikāciju brokeris ā€“ Keycloak.

SSO par mikropakalpojumu arhitektūru. Mēs izmantojam Keycloak. Daļa Nr.1

Keycloak ir atvērtā pirmkoda identitātes un piekļuves kontroles produkts, ko uztur RedHat. Tas ir pamats uzņēmuma produktiem, izmantojot SSO - RH-SSO.

Pamatjēdzieni

Pirms sākat izskatīt risinājumus un pieejas, jums jāizlemj par procesu noteikumiem un secību:

SSO par mikropakalpojumu arhitektūru. Mēs izmantojam Keycloak. Daļa Nr.1

Identifikācija ir procedÅ«ra subjekta atpazÄ«Å”anai pēc tā identifikatora (citiem vārdiem sakot, Ŕī ir vārda, pieteikÅ”anās vai numura definÄ«cija).

Autentifikācija - Ŕī ir autentifikācijas procedÅ«ra (lietotājs tiek pārbaudÄ«ts ar paroli, vēstule tiek pārbaudÄ«ta ar elektronisko parakstu utt.)

Atļauja - Ŕī ir piekļuves nodroÅ”ināŔana resursam (piemēram, e-pastam).

Keycloak Identity Broker

atslēgas apmetnis ir atvērtā pirmkoda identitātes un piekļuves pārvaldÄ«bas risinājums, kas paredzēts lietoÅ”anai IS, kur var izmantot mikropakalpojumu arhitektÅ«ras modeļus.

Keycloak piedāvā tādas funkcijas kā vienotā pierakstīŔanās (SSO), starpniecības identitāte un sociālā pieteikŔanās, lietotāju federācija, klientu adapteri, administratora konsole un konta pārvaldības konsole.

Keycloak atbalstītā pamata funkcionalitāte:

  • Vienreizēja pierakstÄ«Å”anās un vienreizēja izrakstÄ«Å”anās pārlÅ«kprogrammas lietojumprogrammām.
  • OpenID/OAuth 2.0/SAML atbalsts.
  • Identitātes starpniecÄ«ba - autentifikācija, izmantojot ārējos OpenID Connect vai SAML identitātes nodroÅ”inātājus.
  • Sociālā pieteikÅ”anās ā€” Google, GitHub, Facebook, Twitter atbalsts lietotāju identifikācijai.
  • Lietotāju federācija ā€“ lietotāju sinhronizācija no LDAP un Active Directory serveriem un citiem identitātes nodroÅ”inātājiem.
  • Kerberos tilts ā€” Kerberos servera izmantoÅ”ana automātiskai lietotāja autentifikācijai.
  • Admin Console ā€” vienotai iestatÄ«jumu un risinājumu opciju pārvaldÄ«bai, izmantojot Web.
  • Konta pārvaldÄ«bas konsole ā€“ neatkarÄ«gai lietotāja profilu pārvaldÄ«bai.
  • Risinājuma pielāgoÅ”ana, pamatojoties uz uzņēmuma korporatÄ«vo identitāti.
  • 2FA autentifikācija ā€” TOTP/HOTP atbalsts, izmantojot Google autentifikatoru vai FreeOTP.
  • PieteikÅ”anās plÅ«smas ā€“ ir iespējama lietotāja paÅ”reÄ£istrācija, paroles atkopÅ”ana un atiestatÄ«Å”ana un citi.
  • Sesiju pārvaldÄ«ba ā€” administratori var pārvaldÄ«t lietotāju sesijas no viena punkta.
  • Token Mappers - lietotāja atribÅ«tu, lomu un citu nepiecieÅ”amo atribÅ«tu piesaistÄ«Å”ana marÄ·ieriem.
  • ElastÄ«ga politikas pārvaldÄ«ba, izmantojot jomu, lietojumprogrammu un lietotājus.
  • CORS atbalsts ā€” klientu adapteriem ir vietējais CORS atbalsts.
  • Pakalpojumu sniedzēja saskarnes (SPI) ā€” liels skaits SPI, kas ļauj pielāgot dažādus servera aspektus: autentifikācijas plÅ«smas, identitātes nodroÅ”inātājus, protokolu kartÄ“Å”anu un daudz ko citu.
  • Klientu adapteri JavaScript lietojumprogrammām, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
  • Atbalsts darbam ar dažādām lietojumprogrammām, kas atbalsta OpenID Connect Relying Party bibliotēku vai SAML 2.0 pakalpojumu sniedzēja bibliotēku.
  • PaplaÅ”ināms, izmantojot spraudņus.

CI / CD procesiem, kā arī vadības procesu automatizācijai Keycloak var izmantot REST API / JAVA API. Dokumentācija pieejama elektroniski:

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

Uzņēmuma identitātes nodroÅ”inātāji (uz vietas)

Iespēja autentificēt lietotājus, izmantojot lietotāju federācijas pakalpojumus.

SSO par mikropakalpojumu arhitektūru. Mēs izmantojam Keycloak. Daļa Nr.1

Var izmantot arÄ« caurlaides autentifikāciju ā€” ja lietotāji tiek autentificēti darbstacijās ar Kerberos (LDAP vai AD), tad tos var automātiski autentificēt Keycloak, atkārtoti nenorādot lietotājvārdu un paroli.

Lietotāju autentifikācijai un turpmākai autorizācijai ir iespējams izmantot relāciju DBVS, kas ir vispiemērotākā izstrādes vidēm, jo ā€‹ā€‹tā neietver ilgstoÅ”us iestatÄ«jumus un integrāciju projektu sākumposmā. Pēc noklusējuma Keycloak iestatÄ«jumu un lietotāja datu glabāŔanai izmanto iebÅ«vētu DBVS.

Atbalstīto DBVS saraksts ir plaŔs un ietver: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle un citus. Līdz Ŕim visvairāk pārbaudītie ir Oracle 12C Release1 RAC un Galera 3.12 klasteris MariaDB 10.1.19.

Identitātes nodroÅ”inātāji ā€“ sociālā pieteikÅ”anās

Ir iespējams izmantot pieteikÅ”anos no sociālajiem tÄ«kliem. Lai aktivizētu iespēju autentificēt lietotājus, izmantojiet Keycloack administratora konsoli. Izmaiņas lietojumprogrammas kodā nav nepiecieÅ”amas, un Ŕī funkcionalitāte ir pieejama jau no kastes, un to var aktivizēt jebkurā projekta posmā.

SSO par mikropakalpojumu arhitektūru. Mēs izmantojam Keycloak. Daļa Nr.1

Lai autentificētu lietotājus, ir iespējams izmantot OpenID/SAML identitātes nodroÅ”inātājus.

Tipiski autorizācijas scenāriji, izmantojot OAuth2 programmā Keycloak

Autorizācijas koda plÅ«sma ā€” izmanto ar servera puses lietojumprogrammām. Viens no visizplatÄ«tākajiem autorizācijas atļauju veidiem, jo ā€‹ā€‹tas ir labi piemērots servera puses lietojumprogrammām, kurās lietojumprogrammas pirmkods un klienta dati nav pieejami citiem. Process Å”ajā gadÄ«jumā ir balstÄ«ts uz novirzÄ«Å”anu. Lietojumprogrammai ir jāspēj sazināties ar lietotāja aÄ£entu (lietotāja aÄ£entu), piemēram, tÄ«mekļa pārlÅ«kprogrammu, lai saņemtu API autorizācijas kodus, kas pārsÅ«tÄ«ti caur lietotāja aÄ£entu.

netieŔā plÅ«sma ā€” izmanto mobilās vai tÄ«mekļa lietojumprogrammas (lietotāja ierÄ«cē darbojas lietojumprogrammas).

NetieŔās autorizācijas atļaujas veids tiek izmantots mobilajās un tÄ«mekļa lietojumprogrammās, kurās nevar garantēt klienta konfidencialitāti. NetieÅ”ajā atļaujas tipā tiek izmantota arÄ« lietotāja aÄ£enta novirzÄ«Å”ana, kur piekļuves pilnvara tiek nodota lietotāja aÄ£entam vēlākai lietoÅ”anai lietojumprogrammā. Tādējādi marÄ·ieris ir pieejams lietotājam un citām lietojumprogrammām lietotāja ierÄ«cē. Šāda veida autorizācijas atļauja neautentificē lietojumprogrammas identitāti, un pats process balstās uz novirzÄ«Å”anas URL (iepriekÅ” reÄ£istrēts pakalpojumā).

Implicit Flow neatbalsta piekļuves pilnvaras atsvaidzināŔanas pilnvaras.

Klienta akreditācijas datu pieŔķirÅ”anas plÅ«sma ā€” izmanto, kad lietojumprogramma piekļūst API. Šāda veida autorizācijas atļauja parasti tiek izmantota mijiedarbÄ«bai starp serveriem, kam jānotiek fonā bez tÅ«lÄ«tējas lietotāja mijiedarbÄ«bas. Klienta akreditācijas datu pieŔķirÅ”anas plÅ«sma ļauj tÄ«mekļa pakalpojumam (konfidenciālam klientam) izmantot savus akreditācijas datus, nevis uzdoties par lietotāju autentifikācijai, izsaucot citu tÄ«mekļa pakalpojumu. Lai nodroÅ”inātu augstāku droŔības lÄ«meni, zvanÄ«Å”anas dienestam ir iespējams izmantot sertifikātu (nevis koplietojamo noslēpumu) kā akreditācijas datus.

OAuth2 specifikācija ir aprakstīta
RFC-6749
RFC-8252
RFC-6819

JWT marķieris un tā priekŔrocības

JWT (JSON Web Token) ir atvērts standarts (https://tools.ietf.org/html/rfc7519), kas definē kompaktu un autonomu veidu, kā droÅ”i pārsÅ«tÄ«t informāciju starp pusēm kā JSON objektu.

Saskaņā ar standartu marÄ·ieris sastāv no trim daļām base-64 formātā, kas atdalÄ«tas ar punktiem. Pirmo daļu sauc par galveni, kurā ir marÄ·iera tips un jaukÅ”anas algoritma nosaukums ciparparaksta iegÅ«Å”anai. Otrajā daļā tiek glabāta pamatinformācija (lietotājs, atribÅ«ti utt.). TreŔā daļa ir digitālais paraksts.

. .
Nekad neuzglabājiet marÄ·ieri savā datu bāzē. Tā kā derÄ«gs marÄ·ieris ir lÄ«dzvērtÄ«gs parolei, marÄ·iera glabāŔana ir tāda pati kā paroles saglabāŔana skaidrā tekstā.
Pieejas atslēga ir marÄ·ieris, kas pieŔķir tā Ä«paÅ”niekam piekļuvi droÅ”iem servera resursiem. Parasti tam ir Ä«ss kalpoÅ”anas laiks, un tajā var bÅ«t papildu informācija, piemēram, tās puses IP adrese, kura pieprasa pilnvaru.

Atsvaidzināt pilnvaru ir marÄ·ieris, kas ļauj klientiem pieprasÄ«t jaunus piekļuves marÄ·ierus pēc to kalpoÅ”anas laika beigām. Å ie žetoni parasti tiek izsniegti uz ilgu laiku.

Galvenās izmantoŔanas priekŔrocības mikropakalpojumu arhitektūrā:

  • Iespēja piekļūt dažādām lietojumprogrammām un pakalpojumiem, izmantojot vienreizēju autentifikāciju.
  • Ja lietotāja profilā nav vairāku nepiecieÅ”amo atribÅ«tu, ir iespējams bagātināt ar datiem, ko var pievienot lietderÄ«gajai slodzei, tostarp automatizētiem un lidojuma laikā.
  • Nav nepiecieÅ”ams uzglabāt informāciju par aktÄ«vajām sesijām, servera lietojumprogrammai ir tikai jāpārbauda paraksts.
  • ElastÄ«gāka piekļuves kontrole, izmantojot papildu atribÅ«tus kravnesÄ«bā.
  • Izmantojot marÄ·iera parakstu galvenei un lietderÄ«gajai slodzei, tiek palielināta kopējā risinājuma droŔība.

JWT žetons - sastāvs

Virsraksts - pēc noklusējuma galvenē ir tikai marÄ·iera veids un Å”ifrÄ“Å”anai izmantotais algoritms.

MarÄ·iera veids tiek saglabāts taustiņā "Typ". Atslēga ā€œtipsā€ JWT tiek ignorēta. Ja ir atslēga "typ", tās vērtÄ«bai ir jābÅ«t JWT, lai norādÄ«tu, ka Å”is objekts ir JSON tÄ«mekļa marÄ·ieris.

Otrā atslēga "alg" nosaka algoritmu, ko izmanto marÄ·iera Å”ifrÄ“Å”anai. Pēc noklusējuma tam jābÅ«t iestatÄ«tam uz HS256. Galvene ir kodēta base64.

{ "alg": "HS256", "typ": "JWT"}
Krava (saturs) - krava glabā visu informāciju, kas ir jāpārbauda. Katra lietderÄ«gās kravas atslēga ir pazÄ«stama kā "prasÄ«ba". Piemēram, jÅ«s varat ievadÄ«t pieteikumu tikai ar ielÅ«gumu (slēgta akcija). Kad vēlamies kādu uzaicināt piedalÄ«ties, nosÅ«tām viņam uzaicinājuma vēstuli. Ir svarÄ«gi pārbaudÄ«t, vai e-pasta adrese pieder personai, kura pieņem uzaicinājumu, tāpēc mēs iekļausim Å”o adresi kravnesÄ«, Å”im nolÅ«kam mēs to saglabājam atslēgā "e-pasts".

{ "e-pasts": "[e-pasts aizsargāts]"}

Kravas atslēgas var būt patvaļīgas. Tomēr ir daži rezervēti:

  • iss (izdevējs) ā€” identificē lietojumprogrammu, no kuras tiek nosÅ«tÄ«ts marÄ·ieris.
  • sub (Subject) - definē marÄ·iera priekÅ”metu.
  • aud (Audience) ā€” reÄ£istrjutÄ«gu virkņu vai URI masÄ«vs, kas ir Ŕīs pilnvaras saņēmēju saraksts. Kad saņēmēja puse saņem JWT ar doto atslēgu, tai paÅ”ai ir jāpārbauda saņēmēji ā€” pretējā gadÄ«jumā marÄ·ieri tiek ignorēti.
  • exp (derÄ«guma laiks) ā€” norāda, kad beidzas marÄ·iera derÄ«guma termiņŔ. JWT standarts pieprasa, lai visas tā ievieÅ”anas tiktu noraidÄ«tas marÄ·ierus, kuriem beidzies derÄ«guma termiņŔ. Atslēgai exp ir jābÅ«t unix formāta laikspiedolam.
  • nbf (Not Before) ir laiks unix formātā, kas nosaka brÄ«di, kad marÄ·ieris kļūst derÄ«gs.
  • iat (Issued At) ā€” Ŕī atslēga norāda laiku, kad marÄ·ieris tika izdots, un to var izmantot, lai noteiktu JWT vecumu. Iat atslēgai ir jābÅ«t unix formāta laikspiedogam.
  • Jti (JWT ID) ā€” virkne, kas definē Ŕī marÄ·iera unikālo identifikatoru, reÄ£istrjutÄ«ga.

Ir svarÄ«gi saprast, ka lietderÄ«gā slodze netiek pārsÅ«tÄ«ta Å”ifrēta (lai gan marÄ·ieri var bÅ«t ligzdoti un tad ir iespējams pārsÅ«tÄ«t Å”ifrētus datus). Tāpēc tajā nevar glabāt nekādu slepenu informāciju. Tāpat kā galvene, lietderÄ«gā slodze ir kodēta base64.
Paraksts - kad mums ir nosaukums un slodze, mēs varam aprēķināt parakstu.

Base64 kodēts: tiek ņemta galvene un lietderÄ«gā slodze, tās tiek apvienotas virknē caur punktu. Pēc tam Ŕī virkne un slepenā atslēga tiek ievadÄ«ta galvenē norādÄ«tajā Å”ifrÄ“Å”anas algoritmā ("alg" atslēga). Atslēga var bÅ«t jebkura virkne. Visvairāk priekÅ”roka tiks dota garākām stÄ«gām, jo ā€‹ā€‹to uzņemÅ”ana prasÄ«s ilgāku laiku.

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

Keycloak kļūmjpārlēces klastera arhitektūras izveide

Izmantojot vienu klasteru visiem projektiem, SSO risinājumam tiek izvirzÄ«tas paaugstinātas prasÄ«bas. Kad projektu skaits ir neliels, Ŕīs prasÄ«bas nav tik bÅ«tiskas visiem projektiem, taču, pieaugot lietotāju un integrāciju skaitam, pieaug prasÄ«bas pieejamÄ«bai un veiktspējai.

Palielinot vienas SSO kļūmes risku, palielinās prasÄ«bas risinājuma arhitektÅ«rai un liekajiem komponentiem izmantotajām metodēm, un tas noved pie ļoti saspringta SLA. Å ajā sakarā biežāk risinājumu izstrādes vai ievieÅ”anas sākumposmā projektiem ir sava nevainojama infrastruktÅ«ra. AttÄ«stÄ«bai progresējot, ir jānosaka attÄ«stÄ«bas un mērogoÅ”anas iespējas. ViselastÄ«gāk ir izveidot kļūmjpārlēces klasteri, izmantojot konteinera virtualizāciju vai hibrÄ«da pieeju.

Lai strādātu klasteru režīmā AktÄ«vs/AktÄ«vs un AktÄ«vs/PasÄ«vs, ir jānodroÅ”ina datu konsekvence relāciju datu bāzē - abiem datu bāzes mezgliem jābÅ«t sinhroni replicētiem starp dažādiem Ä£eogrāfiski sadalÄ«tiem datu centriem.

VienkārŔākais defektu izturÄ«gas instalācijas piemērs.

SSO par mikropakalpojumu arhitektūru. Mēs izmantojam Keycloak. Daļa Nr.1

Kādas ir viena klastera izmantoŔanas priekŔrocības:

  • Augsta pieejamÄ«ba un veiktspēja.
  • Atbalsta darbÄ«bas režīmus: aktÄ«vs/aktÄ«vs, aktÄ«vs/pasÄ«vs.
  • Dinamiskās mērogoÅ”anas iespēja - izmantojot konteinera virtualizāciju.
  • Centralizētas vadÄ«bas un uzraudzÄ«bas iespēja.
  • Vienota pieeja lietotāju identificÄ“Å”anai/autentifikācijai/autorizācijai projektos.
  • Caurskatāmāka mijiedarbÄ«ba starp dažādiem projektiem bez lietotāja mijiedarbÄ«bas.
  • Iespēja atkārtoti izmantot JWT marÄ·ieri dažādos projektos.
  • Viens uzticÄ«bas punkts.
  • Ātrāka projektu palaiÅ”ana, izmantojot mikropakalpojumus/konteineru virtualizāciju (nav nepiecieÅ”ams pacelt un konfigurēt papildu komponentus).
  • Ir iespējams iegādāties komerciālu atbalstu no pārdevēja.

Kas jāņem vērā, plānojot kopu

DBVS

Keycloak izmanto datu bāzes pārvaldības sistēmu, lai saglabātu: sfēras, klientus, lietotājus utt.
Tiek atbalstÄ«ts plaÅ”s DBVS klāsts: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak nāk ar savu iebÅ«vēto relāciju datu bāzi. Ieteicams izmantot neielādētām vidēm - piemēram, izstrādes vidēm.

Lai strādātu aktÄ«vo/aktÄ«vo un aktÄ«vo/pasÄ«vo klasteru režīmos, ir nepiecieÅ”ama datu konsekvence relāciju datu bāzē, un abi datu bāzes klasteru mezgli tiek sinhroni replicēti starp datu centriem.

Izkliedētā keÅ”atmiņa (Infinspan)

Lai klasteris darbotos pareizi, ir nepiecieÅ”ama tālāk norādÄ«to veidu keÅ”atmiņu papildu sinhronizācija, izmantojot JBoss Data Grid:

Autentifikācijas sesijas ā€” izmanto datu saglabāŔanai, autentificējot konkrētu lietotāju. PieprasÄ«jumi no Ŕīs keÅ”atmiņas parasti attiecas tikai uz pārlÅ«kprogrammu un Keycloak serveri, nevis uz lietojumprogrammu.

DarbÄ«bas marÄ·ieri tiek izmantoti gadÄ«jumiem, kad lietotājam ir jāapstiprina darbÄ«ba asinhroni (pa e-pastu). Piemēram, aizmirst paroles plÅ«smas laikā actionTokens Infinispan keÅ”atmiņa tiek izmantota, lai sekotu metadatiem par saistÄ«tajiem darbÄ«bas marÄ·ieriem, kas jau ir izmantoti, tāpēc tos nevar izmantot atkārtoti.

PastāvÄ«go datu saglabāŔana keÅ”atmiņā un nederÄ«guma atcelÅ”ana ā€” izmanto, lai saglabātu keÅ”atmiņu noturÄ«giem datiem, lai izvairÄ«tos no nevajadzÄ«giem vaicājumiem datu bāzē. Kad jebkurÅ” Keycloak serveris atjaunina datus, par to ir jāzina visiem citiem Keycloak serveriem visos datu centros.

Darbs ā€” tiek izmantots tikai nederÄ«gu ziņojumu sÅ«tÄ«Å”anai starp klasteru mezgliem un datu centriem.

Lietotāju sesijas ā€” izmanto, lai saglabātu datus par lietotāju sesijām, kas ir derÄ«gas lietotāja pārlÅ«kprogrammas sesijas laikā. KeÅ”atmiņai ir jāapstrādā HTTP pieprasÄ«jumi no gala lietotāja un lietojumprogrammas.

Brutālā spēka aizsardzÄ«ba ā€” izmanto, lai izsekotu datus par neveiksmÄ«gām pieteikÅ”anās vietām.

Slodzes balansēŔana

Slodzes līdzsvarotājs ir vienīgais ieejas punkts taustiņu apmetnī, un tam ir jāatbalsta lipīgās sesijas.

Lietojumprogrammu serveri

Tos izmanto, lai kontrolētu komponentu mijiedarbÄ«bu savā starpā, un tos var virtualizēt vai konteinerizēt, izmantojot esoÅ”os automatizācijas rÄ«kus un infrastruktÅ«ras automatizācijas rÄ«ku dinamisku mērogoÅ”anu. VisizplatÄ«tākie izvietoÅ”anas scenāriji OpenShift, Kubernates, Rancher.

Ar to noslēdzas pirmā daļa ā€“ teorētiskā. Nākamajā rakstu sērijā tiks analizēti piemēri integrācijai ar dažādiem identitātes nodroÅ”inātājiem un iestatÄ«jumu piemēri.

Avots: www.habr.com

Pievieno komentāru