Disa muajve më parë isha i angazhuar në realizimin e një serveri OpenID Connect për menaxhimin e aksesit në qindra nga aplikacionet tona të brendshme. Nga zhvillimet tona të brendshme, të përshtatshme për shkallë të vogla, kaluam në standardin e njohur. Qasja përmes një shërbimi qendror e thjeshton ndjeshëm operacionet monotone, redukton kostot e implementimit të autorizimeve, lejon të gjejmë shumë zgjidhje të gatshme dhe na shpëton nga mendimi gjatë zhvillimit të të rejave. Në këtë artikull do të flas për këtë kalim dhe për sfidat që kemi pasur.
Njëherë e një kohë⊠Si nisi gjithçka
Disa vite më parë, kur aplikacionet e brendshme u bënë shumë për t'i menaxhuar manualisht, shkruam një aplikacion për kontrollin e aksesit brenda kompanisë. Ishte një aplikacion i thjeshtë në Rails, që lidhej me një bazë të dhënash me informacion rreth punonjësve, ku konfiguronte aksesin në funksionalitete të ndryshme. Atëherë ngritëm SSO-në e parë, e cila bazohej në verifikimin e tokenëve nga ana e klientit dhe serverit të autorizimit, tokeni dërgohej në një format të koduar me disa parametra dhe verifikohej në serverin e autorizimit. Kjo nuk ishte opsioni më i përshtatshëm pasi për çdo aplikacion të brendshëm duhej të përshkruhej një shtresë e konsiderueshme logjike, dhe bazat e të dhënave të punonjësve duhej të sinkronizoheshin me serverin e autorizimit.
Pas njĂ« kohe, vendosĂ«m ta thjeshtonim detyrĂ«n e autorizimit qendror. SSO kaloi nĂ« balancer. Me ndihmĂ«n e OpenResty nĂ« Lua, shtuam njĂ« model qĂ« kontrollonte tokenĂ«t, dinte nĂ« cilin aplikacion bĂ«hej kĂ«rkesa dhe mund tĂ« kontrollonte nĂ«se kishte akses atje. Ky qasje e thjeshtoi ndjeshĂ«m detyrĂ«n e kontrollit tĂ« aksesit pĂ«r aplikacionet e brendshme â nĂ« kodin e çdo aplikacioni nuk ishte mĂ« e nevojshme tĂ« pĂ«rshkruhej logjika shtesĂ«. NĂ« fund, ne e mbyllĂ«m trafikun pĂ«rjashtueshĂ«m, ndĂ«rsa vetĂ« aplikacioni nuk dinte asgjĂ« pĂ«r autorizimin.
Megjithatë, një nga problemet mbetet e pazgjidhur. Si të veprohet me aplikacionet që kanë nevojë për informacion mbi punonjësit? Mund të shkruhej një API për shërbimin e autorizimit, por do të duhej të shtonim logjikë të shtuar për çdo aplikacion të tillë. Ndaj, ne do të dëshironim të heqim varësinë nga një aplikacioni ynë të zhvilluar vetë, i cili do të orientohet më vonë drejt kalimit në OpenSource, nga serveri ynë të brendshëm të autorizimit. Ne do të flasim për të njëherë tjetër. Zgjidhja për të dy problemet ishte OAuth.
Standardet e pranuara gjerësisht
OAuth është një standard i pranuar dhe i kuptueshëm i autorizimit, por sepse funksionaliteti i tij nuk ishte i mjaftueshëm, filluan të shqyrtohen menjëherë edhe OpenID Connect (OIDC). Vetë OIDC është implementimi i tretë i standardit të hapur të autentifikimit, i cili ka kaluar në një shtresë mbi protokollin OAuth 2.0 (protokoll i hapur autorizimi). Ky zgjidhje mbyll problemin e mungesës së të dhënave për përdoruesin e fundit dhe gjithashtu mundëson ndryshimin e ofruesit të autorizimit.
Megjithatë, ne nuk zgjodhëm një ofrues konkret dhe vendosëm të shtojmë integrimin me OIDC në serverin tonë ekzistues të autorizimit. Pjesa në mbështetje të këtij vendimi ishte se OIDC është shumë fleksibile në marrëdhëniet e autorizimit të përdoruesit të fundit. Kështu, u bë e mundur të implementohej mbështetje OIDC në serverin tonë aktual të autorizimit.
Rruga jonë për realizimin e një OIDC-serveri të vetin
1) Mënyra e organizimit të të dhënave
Për integrimin OIDC, është e nevojshme të organizohen të dhënat aktuale për përdoruesit në një formë të kuptueshme sipas standardit. Në OIDC, kjo quhet Claims. Claims në thelb janë fushat përfundimtare në bazën e të dhënave për përdoruesit (emri, email, telefoni, etj.). Ekziston , dhe gjithçka që nuk përfshihet në këtë listë konsiderohet personalizim. Prandaj, pika e parë në të cilën duhet të jepni vëmendje nëse vendosni të zgjidhni një ofrues të ekzistueshëm OIDC është mundësia e lehtë për personalizimin e claims të reja.
Grupi i claims bashkohet në nënpjesën e mëposhtme - Scope. Gjatë autorizimit, kërkohet qasje jo në claims specifike, por pikërisht në scopes, edhe nëse një pjesë e claims nga scope-i nuk është e nevojshme.
2) Implementuam grantet e nevojshme
Pjesa tjetër e integrimit OIDC është zgjedhja dhe implementimi i tipeve të autorizimit, të njohur si grantet. Scenari i mëtejshëm i bashkëpunimit mes aplikacionit të zgjedhur dhe serverit të autorizimit do të varet nga granti i zgjedhur. Një skemë e përafërt e zgjedhjes së grantit të duhur paraqitet më poshtë.
Për aplikacionin tonë të parë, ne përdorëm grantin më të përhapur - Kodin e Autorizimit. Dallimi i tij nga të tjerët është se ai është një proces në tri hapa, pra kalon një verifikim shtesë. Së pari, përdoruesi bën një kërkesë për lejen e autorizimit, merr një token - Kodin e Autorizimit, pastaj me këtë token, si me një biletë udhëtimi, kërkon një token akses. Të gjitha bashkëpunimet kryesore të këtij skenari autorizimi bazohen në ridirektime midis aplikacionit dhe serverit të autorizimit. Mund të lexoni më shumë rreth këtij granti. .
OAuth ndjek konceptin që tokenet e aksesit, të marra pas autorizimit, duhet të jenë të përkohshme dhe të ndryshojnë preferohet çdo 10 minuta. Granti i Kodit të Autorizimit është një proces verifikimi në tri hapa përmes ridirektimeve, çdo 10 minuta për të bërë një hap të tillë, për të qenë e sinqertë, nuk është një qytetari e këndshme për sytë. Për të zgjidhur këtë problem, ekziston një grant tjetër - Tokeni i Rifreskimit, i cili gjithashtu e kemi përdorur. Këtu është më e thjeshtë. Gjatë verifikimit me një grant tjetër, përveç tokenit kryesor të aksesit jepet edhe një tjetër - Tokeni i Rifreskimit, i cili mund të përdoret vetëm një herë dhe koha e tij e jetës, zakonisht, është dukshëm më e gjatë. Me këtë Token të Rifreskimit, kur të përfundojë TTL (Koha e Jetës) e tokenit kryesor të aksesit, kërkesa për një token të ri akses do të vijë në endpoint tashmë të granteve të tjera. Tokeni i Rifreskimit i përdorur menjëherë anulohet. Ky proces verifikimi është në dy hapa dhe mund të kryhet në sfond, pa u vënë re nga përdoruesi.
3) Konfigurimi i formateve të daljes së të dhënave të përdoruesve
Pas pasqyra e grantit të zgjedhur, autorizimi funksionon, është e rëndësishme të përmendet marrja e të dhënave mbi përdoruesin përfundimtar. Në OIDC, ka një endpoint të veçantë për këtë, ku me tokenin tuaj aktual të aksesit dhe duke qenë i rëndësishëm, mund të kërkoni të dhënat e përdoruesve. Nëse të dhënat e përdoruesit nuk ndryshojnë shpesh, por ne duhet të shkojmë për të dhënat aktuale shumë herë, mund të arrihet në një zgjidhje siç janë tokenët JWT. Këta tokenë gjithashtu mbështeten nga standardi. JWT-në vetë përbëhet nga tri pjesë: header (informacion mbi tokenin), payload (të dhënat e nevojshme) dhe signature (nënshkrimi, tokeni nënshkruhet nga serveri dhe më pas mund të verifikohet burimi i nënshkrimit të tij).
NĂ« implementimin e OIDC, JWT quhet id_token. Ai mund tĂ« kĂ«rkohet sĂ« bashku me tokenin normal tĂ« aksesit dhe e vetmja gjĂ« qĂ« mbetet â Ă«shtĂ« tĂ« verifikohet nĂ«nshkrimi. PĂ«r kĂ«tĂ«, serveri i autorizimit ka njĂ« endpoint tĂ« veçantĂ« me njĂ« lidhje tĂ« çelĂ«save publikĂ« nĂ« formatin . Dhe duke folur pĂ«r kĂ«tĂ«, Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« pĂ«rmendet se ekziston njĂ« endpoint tjetĂ«r, i cili bazuar nĂ« standardin reflekton konfigurimin aktual tĂ« serverit OIDC. NĂ« tĂ« pĂ«rfshihen tĂ« gjitha adresat e endpoint-eve (pĂ«rfshirĂ« adresĂ«n e lidhjes pĂ«r çelĂ«sat publikĂ« tĂ« pĂ«rdorur pĂ«r nĂ«nshkrim), kĂ«rkesat e mbĂ«shtetura dhe skopet, algoritmet e kodimit tĂ« mbĂ«shtetur, grantet etj.
Për shembull në Google:
{
"issuer": "https://accounts.google.com",
"authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
"device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
"token_endpoint": "https://oauth2.googleapis.com/token",
"userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
"revocation_endpoint": "https://oauth2.googleapis.com/revoke",
"jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
"response_types_supported": [
"code",
"token",
"id_token",
"code token",
"code id_token",
"token id_token",
"code token id_token",
"none"
],
"subject_types_supported": [
"public"
],
"id_token_signing_alg_values_supported": [
"RS256"
],
"scopes_supported": [
"openid",
"email",
"profile"
],
"token_endpoint_auth_methods_supported": [
"client_secret_post",
"client_secret_basic"
],
"claims_supported": [
"aud",
"email",
"email_verified",
"exp",
"family_name",
"given_name",
"iat",
"iss",
"locale",
"name",
"picture",
"sub"
],
"code_challenge_methods_supported": [
"plain",
"S256"
],
"grant_types_supported": [
"authorization_code",
"refresh_token",
"urn:ietf:params:oauth:grant-type:device_code",
"urn:ietf:params:oauth:grant-type:jwt-bearer"
]
}Kështu, me ndihmën e id_token-it, është e mundur të dërgoni të gjitha përmbajtjet e nevojshme në payload-in e tokenit dhe të mos i drejtoheni serverit të autorizimit për të kërkuar të dhëna mbi përdoruesin çdo herë. Një disavantazh i këtij qasjeje është se ndryshimet në të dhënat e përdoruesit nga serveri nuk vijnë menjëherë, por me token-in e ri të qasjes.
PĂ«rfundimet e realizimit
Kështu, pas realizimit të serverit tonë OIDC dhe konfigurimit të lidhjeve të tij nga ana e aplikacioneve, ne zgjidhëm problemin e transmetimit të informacionit mbi përdoruesit.
Pasi që OIDC është një standard i hapur, ne patëm mundësinë të zgjidhnim një ofrues ekzistues ose të realizonim serverin tonë. Provuam Keycloak, i cili rezultoi shumë i përshtatshëm për konfigurim, pas konfigurimit dhe ndryshimit të konfigureve të lidhjes nga ana e aplikacioneve, ai është gati për t'u përdorur. Nga ana e aplikacioneve mbetet vetëm të ndryshojmë konfigurimet e lidhjes.
Duke folur mbi zgjidhjet ekzistuese
Brenda organizatës tonë, si serverin e parë OIDC, ne krijuam realizimin tonë, i cili u plotësua sipas nevojës. Pas një shqyrtimi të hollësishëm të zgjidhjeve të tjera të gatshme, mund të themi se kjo është një çështje e diskutueshme. Në favor të zgjidhjes së realizmit të serverit tonë ndihmoi shqetësimi nga ofruesit për mungesën e funksionaliteteve të nevojshme, si dhe ekzistencën e një sistemi të vjetër në të cilin kishim divergjenca të personalizuara për disa shërbime dhe ishim mbledhur tashmë shumë të dhëna mbi punonjësit. Megjithatë, në realizimet e gatshme, ka lehtësira për integrim. Për shembull, në Keycloak ka një sistem menaxhimi të përdoruesve dhe të dhënat ruajnë direkt atje, dhe kalimi i përdoruesve tanë atje nuk është një punë e vështirë. Për këtë, në Keycloak ka një API që do të lejojë të realizoni të gjitha veprimet e nevojshme për transférimin.
Një shembull tjetër i një realizimi të certifikuar, të interesant në mendimin tim, është Ory Hydra. Ajo është interesante sepse përbëhet nga komponentë të ndryshëm. Për integrimin do t'ju nevojitet të lidhni shërbimin tuaj të menaxhimit të përdoruesve me shërbimin e tyre të autorizimit dhe ta zgjeroni sipas nevojës.
Keycloak dhe Ory Hydra nuk janë zgjidhjet e vetme të gatshme. Më mirë është të zgjidhni një realizim të certifikuar nga OpenID Foundation. Zakonisht, këto zgjidhje kanë një simbol të certifikimit OpenID.
Mos harroni edhe ofruesit e paguar ekzistues nëse nuk dëshironi të mbani serverin tuaj OIDC. Sot, ka shumë mundësi të mira.
ĂfarĂ« pason
Në të ardhmen e afërt, ne planifikojmë të mbyllim trafikun në shërbimet tona të brendshme me një mënyrë tjetër. Po planifikojmë të transferojmë SSO-në tonë aktuale në një balancer me ndihmën e OpenResty mbi një prokuror, që bazohet në OAuth. Këtu gjithashtu ekzistojnë shumë zgjidhje të gatshme, për shembull:
Materiale shtesë
â njĂ« shĂ«rbim i mirĂ« pĂ«r verifikimin e JWT-tokens
â lista e zbatimeve tĂ« certifikuara OIDC
Burimi: habr.com
