Duela hilabete batzuk, OpenID Connect zerbitzari bat ezartzen ari nintzen gure barneko ehunka aplikazioren sarbidea kudeatzeko. Gure garapenetatik, eskala txikiagoan erosoa, orokorrean onartutako estandarrera pasatu gara. Zerbitzu zentralaren bidez sartzeak eragiketa monotonoak asko errazten ditu, baimenak ezartzearen kostua murrizten du, prest dauden irtenbide asko aurkitzeko aukera ematen du eta berriak garatzerakoan buru-belarri ez piztu. Artikulu honetan, trantsizio honi eta betetzea lortu genuen kolpeei buruz hitz egingo dut.
Aspaldi... Nola hasi zen dena
Duela urte batzuk, eskuzko kontrolerako barne aplikazio gehiegi zeudenean, enpresa barruan sarbidea kontrolatzeko aplikazio bat idatzi genuen. Langileei buruzko informazioa duen datu-base batera konektatzen zen Rails aplikazio sinple bat zen, non hainbat funtzionalitatetarako sarbidea konfiguratzen zen. Aldi berean, lehen SSOa planteatu genuen, bezeroaren eta baimen-zerbitzariaren tokenen egiaztapenean oinarritzen zena, tokena forma enkriptatuta transmititu zen hainbat parametrorekin eta baimen-zerbitzarian egiaztatu zen. Hau ez zen aukerarik erosoena, barne aplikazio bakoitzak logika geruza nabarmen bat deskribatu behar baitzuen, eta langileen datu-baseak baimen-zerbitzariarekin guztiz sinkronizatuta zeuden.
Denbora pixka bat igaro ondoren, baimen zentralizatuaren zeregina erraztea erabaki genuen. SSO balantzaileari transferitu zaio. OpenResty-ren laguntzaz, Lua-ri txantiloi bat gehitu zitzaion, tokenak egiaztatzen zituena, eskaera zein aplikaziotara joango zen bazekien eta han sarbidea zegoen ala ez egiaztatzeko. Ikuspegi honek asko erraztu zuen barne aplikazioetarako sarbidea kontrolatzeko zeregina - aplikazio bakoitzaren kodean, jada ez zen beharrezkoa logika gehigarria deskribatzea. Ondorioz, kanpotik trafikoa itxi genuen, eta aplikazioak berak ez zekien baimenari buruz ezer.
Hala ere, arazo bat konpondu gabe zegoen. Zer gertatzen da langileei buruzko informazioa behar duten aplikazioekin? Baimen zerbitzurako API bat idaztea posible zen, baina gero logika gehigarria gehitu beharko zenioke aplikazio bakoitzerako. Horrez gain, gure barneko baimen-zerbitzarian, gerora, OpenSource-ra itzuliko zen gure auto-idatzitako aplikazio baten menpekotasuna kendu nahi izan dugu. Beste noizbait hitz egingo dugu horretaz. Bi arazoen irtenbidea OAuth izan zen.
estandar komunetara
OAuth baimen estandar ulergarria eta orokorrean onartua da, baina bere funtzionaltasuna nahikoa ez denez, berehala hasi ziren kontuan hartzen OpenID Connect (OIDC). OIDC bera autentifikazio irekiko estandarraren hirugarren inplementazioa da, OAuth 2.0 protokoloaren (baimen irekiko protokoloa) gehigarri batean sartu dena. Irtenbide honek amaierako erabiltzaileari buruzko datu faltaren arazoa ixten du, eta baimen-hornitzailea aldatzea ere ahalbidetzen du.
Hala ere, ez dugu hornitzaile zehatz bat aukeratu eta lehendik dagoen baimen-zerbitzariari OIDC-rekin integrazioa gehitzea erabaki dugu. Erabaki horren alde zegoen OIDC oso malgua dela azken erabiltzaileen baimenari dagokionez. Horrela, OIDC euskarria ezartzea posible zen zure egungo baimen-zerbitzarian.
Gure OIDC zerbitzari propioa ezartzeko gure modua
1) Datuak nahi duzun formara ekarri
OIDC integratzeko, beharrezkoa da egungo erabiltzailearen datuak estandarrak ulergarria den forma batera ekartzea. OIDC-n honi Erreklamazioak deitzen zaio. Erreklamazioak erabiltzailearen datu-baseko azken eremuak dira funtsean (izena, posta elektronikoa, telefonoa, etab.). Existitzen da , eta zerrenda honetan sartzen ez dena ohituratzat hartzen da. Hori dela eta, lehendik dagoen OIDC hornitzaile bat aukeratu nahi baduzu arreta jarri behar duzun lehen puntua marka berriak eroso pertsonalizatzeko aukera da.
Ezaugarrien taldea honako azpimultzo honetan konbinatzen da - Eremua. Baimenaren garaian, ez da marka zehatzetarako sarbidea eskatzen, esparruetarako baizik, nahiz eta esparruko marka batzuk behar ez izan.
2) Beharrezko diru-laguntzak ezarri ditu
OIDC integrazioaren hurrengo zatia baimen motak hautatzea eta ezartzea da, diru-laguntzak deiturikoak. Hautatutako aplikazioaren eta baimen-zerbitzariaren arteko elkarrekintza gehiago aukeratutako diru-laguntzaren araberakoa izango da. Beka egokia aukeratzeko eskema eredugarria beheko irudian ageri da.
Gure lehen eskaera egiteko, diru-laguntzarik ohikoena erabili dugu, Baimen Kodea. Besteekiko aldea hiru urratsa dela da, hau da. proba osagarriak egiten ari da. Lehenik eta behin, erabiltzaileak baimen-baimen eskaera bat egiten du, token bat jasotzen du - Baimen-kodea, gero token honekin, bidaiarako txartel batekin bezala, sarbide-token bat eskatzen du. Baimen-script honen interakzio nagusi guztia aplikazioaren eta baimen-zerbitzariaren arteko birzuzenketetan oinarritzen da. Beka honi buruzko informazio gehiago irakur dezakezu .
OAuth-ek onartzen du baimenaren ondoren lortutako sarbide-tokenak aldi baterakoak izan behar direla eta aldatu behar direla, ahal izanez gero, batez beste 10 minutuz behin. Baimen-kodearen diru-laguntza birzuzenbideen bidez hiru urratseko egiaztapena da, 10 minuturo urrats hori emateko, egia esanda, ez da begientzako zereginik atseginena. Arazo hau konpontzeko, beste beka bat dago - Refresh Token, gure herrialdean ere erabili genuena. Hemen dena errazagoa da. Beste diru-laguntza baten egiaztapenean, sarbide-token nagusiaz gain, beste bat jaulkitzen da - Fresh Token, behin bakarrik erabil daitekeena eta bere iraupena askoz luzeagoa izan ohi da. Fresh Token honekin, sarbide-token nagusiaren TTL (Time to Live) amaitzen denean, sarbide-token berri baten eskaera beste beka baten amaierara iritsiko da. Erabilitako Freskatzeko Tokena berehala berrezartzen da zerora. Egiaztapen hau bi urratsekoa da eta atzeko planoan egin daiteke, erabiltzailearentzat oharkabean.
3) Konfiguratu datuen irteerako formatu pertsonalizatuak
Aukeratutako diru-laguntzak ezarri ondoren, baimenak funtzionatzen du, aipatzekoa da azken erabiltzaileari buruzko datuak eskuratzea. OIDC-k amaierako puntu bereizi bat du horretarako, non erabiltzaile-datuak eska ditzakezu zure uneko sarbide-tokenarekin eta eguneratuta badago. Eta erabiltzailearen datuak hainbestetan aldatzen ez badira eta egungoak askotan jarraitu behar badituzu, JWT tokenak bezalako irtenbide batera iritsi zaitezke. Token hauek estandarrak ere onartzen ditu. JWT tokenak berez hiru zati ditu: goiburua (tokenari buruzko informazioa), karga (beharrezko edozein datu) eta sinadura (sinadura, tokena zerbitzariak sinatzen du eta gero bere sinaduraren iturria egiaztatu dezakezu).
OIDC inplementazioan, JWT tokena id_token deitzen da. Sarbide arrunteko token batekin batera eska daiteke eta sinadura egiaztatzea besterik ez da geratzen. Baimen zerbitzariak amaierako puntu bereizi bat du horretarako formatuan dauden gako publiko mordo batekin . Eta honetaz hitz egitean, aipatzekoa da beste amaiera-puntu bat dagoela, hau da, estandarrean oinarrituta OIDC zerbitzariaren egungo konfigurazioa islatzen du. Amaiera-puntuen helbide guztiak (sinatzeko erabiltzen den gako-eraztun publikoaren helbidea barne), onartzen diren marka eta esparruak, erabilitako enkriptazio algoritmoak, onartzen diren diru-laguntzak, etab.
Adibidez, Googlen:
{
"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"
]
}Horrela, id_token erabiliz, beharrezkoak diren bereizgarri guztiak tokenaren kargara transferitu ditzakezu eta baimen-zerbitzariarekin ez harremanetan jarri erabiltzailearen datuak eskatzeko. Ikuspegi honen desabantaila zerbitzaritik erabiltzaileen datuen aldaketa ez dela berehala etortzen da, sarbide-token berri batekin baizik.
Ezarpenaren emaitzak
Beraz, gure OIDC zerbitzaria inplementatu eta aplikazioaren aldetik harekin konexioak konfiguratu ondoren, erabiltzaileei buruzko informazioa transferitzearen arazoa konpondu genuen.
OIDC estandar irekia denez, lehendik dagoen hornitzaile edo zerbitzariaren ezarpena aukeratzeko aukera dugu. Keycloak probatu genuen, konfiguratzeko oso erosoa izan zena, aplikazioaren aldean konexio konfigurazioak konfiguratu eta aldatu ondoren, prest dago. Aplikazioaren aldetik, konexioaren konfigurazioak aldatzea besterik ez da geratzen.
Dauden irtenbideei buruz hitz egitea
Gure erakundearen barruan, lehen OIDC zerbitzari gisa, gure inplementazio propioa muntatu genuen, beharrezko moduan osatu zena. Prestatutako beste irtenbide batzuen berrikuspen zehatza egin ondoren, hau eztabaidagarria dela esan dezakegu. Zerbitzari propioa ezartzeko erabakiaren alde, hornitzaileen aldetik kezkak zeuden beharrezko funtzionalitaterik ez izateagatik, baita sistema zahar baten presentzia ere, non zerbitzu batzuetarako baimen pertsonalizatu desberdinak zeuden eta dezente. langileei buruzko datuak gordeta zeuden jada. Hala ere, prest egindako inplementazioetan, integratzeko erosotasunak daude. Adibidez, Keycloak-ek erabiltzaileak kudeatzeko sistema propioa du eta datuak zuzenean bertan gordetzen dira, eta ez da zaila izango zure erabiltzaileak gainditzea bertan. Horretarako, Keycloak-ek beharrezko transferentzia-ekintza guztiak bete-betean egiteko aukera emango dizun API bat dauka.
Ziurtatutako, interesgarri, nire ustez, ezarpenaren beste adibide bat Ory Hydra da. Interesgarria da osagai ezberdinez osatuta dagoelako. Integratzeko, zure erabiltzaileen kudeaketa-zerbitzua haien baimen-zerbitzuarekin lotu eta behar den hedatu beharko duzu.
Keycloak eta Ory Hydra ez dira eskuragarri dauden irtenbide bakarrak. Hobe da OpenID Fundazioak ziurtatutako inplementazio bat aukeratzea. Irtenbide hauek OpenID Ziurtagiriaren bereizgarria izan ohi dute.
Gainera, ez ahaztu lehendik dauden ordaindutako hornitzaileez zure OIDC zerbitzaria mantendu nahi ez baduzu. Gaur egun aukera on asko daude.
Zer da hurrengoa
Etorkizun hurbilean, barruko zerbitzuetarako trafikoa beste era batera itxiko dugu. OpenResty erabiliz orekatzailean gure egungo SSOa OAuth-en oinarritutako proxy batera transferitzeko asmoa dugu. Hemen dagoeneko prest dauden irtenbide asko daude, adibidez:
Material osagarriak
- JWT tokenak baliozkotzeko zerbitzu ona
- Ziurtatutako OIDC inplementazioen zerrenda
Iturria: www.habr.com