Pirms dažiem mÄneÅ”iem es ieviesu OpenID Connect serveri, lai pÄrvaldÄ«tu piekļuvi simtiem mÅ«su iekÅ”Äjo lietojumprogrammu. No mÅ«su paÅ”u izstrÄdes, kas ir Ärti mazÄkÄ mÄrogÄ, mÄs esam pÄrgÄjuÅ”i uz vispÄrpieÅemtu standartu. Piekļuve, izmantojot centrÄlo pakalpojumu, ievÄrojami vienkÄrÅ”o monotonÄs darbÄ«bas, samazina autorizÄciju ievieÅ”anas izmaksas, ļauj atrast daudz gatavu risinÄjumu un nelauzt smadzenes, izstrÄdÄjot jaunus. Å ajÄ rakstÄ es runÄÅ”u par Å”o pÄreju un izciļÅiem, kurus mums izdevÄs aizpildÄ«t.
Sen... KÄ tas viss sÄkÄs
Pirms dažiem gadiem, kad bija pÄrÄk daudz iekÅ”Äjo lietojumprogrammu manuÄlai kontrolei, mÄs uzrakstÄ«jÄm pieteikumu, lai kontrolÄtu piekļuvi uzÅÄmuma iekÅ”ienÄ. TÄ bija vienkÄrÅ”a Rails aplikÄcija, kas pieslÄdzÄs datu bÄzei ar informÄciju par darbiniekiem, kurÄ tika konfigurÄta pieeja dažÄdÄm funkcionalitÄtÄm. TajÄ paÅ”Ä laikÄ mÄs izvirzÄ«jÄm pirmo SSO, kas balstÄ«jÄs uz tokenu pÄrbaudi no klienta un autorizÄcijas servera puses, marÄ·ieris tika pÄrsÅ«tÄ«ts Å”ifrÄtÄ veidÄ ar vairÄkiem parametriem un pÄrbaudÄ«ts autorizÄcijas serverÄ«. Tas nebija ÄrtÄkais variants, jo katrai iekÅ”Äjai lietojumprogrammai bija jÄapraksta ievÄrojams loÄ£ikas slÄnis, un darbinieku datu bÄzes tika pilnÄ«bÄ sinhronizÄtas ar autorizÄcijas serveri.
PÄc kÄda laika mÄs nolÄmÄm vienkÄrÅ”ot centralizÄtÄs autorizÄcijas uzdevumu. SSO tika pÄrsÅ«tÄ«ts uz balansÄtÄju. Ar OpenResty palÄ«dzÄ«bu Lua tika pievienota veidne, kas pÄrbaudÄ«ja marÄ·ierus, zinÄja, uz kuru lietojumprogrammu tiek nosÅ«tÄ«ts pieprasÄ«jums, un varÄja pÄrbaudÄ«t, vai tur ir piekļuve. Å Ä« pieeja ievÄrojami vienkÄrÅ”oja uzdevumu kontrolÄt piekļuvi iekÅ”ÄjÄm lietojumprogrammÄm - katras lietojumprogrammas kodÄ vairs nebija jÄapraksta papildu loÄ£ika. RezultÄtÄ mÄs ÄrÄji slÄdzÄm satiksmi, un pati lietojumprogramma neko nezinÄja par autorizÄciju.
TomÄr viena problÄma palika neatrisinÄta. KÄ ar lietojumprogrammÄm, kurÄm nepiecieÅ”ama informÄcija par darbiniekiem? AutorizÄcijas pakalpojumam bija iespÄjams uzrakstÄ«t API, bet tad katrai Å”Ädai lietojumprogrammai bÅ«tu jÄpievieno papildu loÄ£ika. TurklÄt mÄs vÄlÄjÄmies atbrÄ«voties no atkarÄ«bas no vienas no mÅ«su paÅ”u rakstÄ«tajÄm lietojumprogrammÄm, kas vÄlÄk tiks pÄrtulkotas OpenSource, mÅ«su iekÅ”ÄjÄ autorizÄcijas serverÄ«. Par to runÄsim citreiz. Abu problÄmu risinÄjums bija OAuth.
kopÄjiem standartiem
OAuth ir saprotams, vispÄrpieÅemts autorizÄcijas standarts, taÄu, tÄ kÄ ar tÄ funkcionalitÄti vien nepietiek, viÅi nekavÄjoties sÄka apsvÄrt OpenID Connect (OIDC) analÄ«zi. Pati OIDC ir treÅ”Ä atvÄrtÄ autentifikÄcijas standarta ievieÅ”ana, kas ir iekļauta OAuth 2.0 protokola (atvÄrtÄ autorizÄcijas protokola) papildinÄjumÄ. Å is risinÄjums novÄrÅ” datu trÅ«kuma problÄmu par gala lietotÄju, kÄ arÄ« ļauj mainÄ«t autorizÄcijas nodroÅ”inÄtÄju.
TomÄr mÄs neizvÄlÄjÄmies konkrÄtu pakalpojumu sniedzÄju un nolÄmÄm pievienot integrÄciju ar OIDC mÅ«su esoÅ”ajam autorizÄcijas serverim. Par labu Å”im lÄmumam bija tas, ka OIDC ir ļoti elastÄ«gs galalietotÄju autorizÄcijas ziÅÄ. TÄdÄjÄdi bija iespÄjams ieviest OIDC atbalstu jÅ«su paÅ”reizÄjÄ autorizÄcijas serverÄ«.
MÅ«su veids, kÄ ieviest savu OIDC serveri
1) Atnesa datus vÄlamajÄ formÄ
Lai integrÄtu OIDC, ir nepiecieÅ”ams ieviest paÅ”reizÄjos lietotÄja datus standartam saprotamÄ formÄ. OIDC to sauc par pretenzijÄm. Pretenzijas bÅ«tÄ«bÄ ir galÄ«gie lauki lietotÄju datubÄzÄ (vÄrds, e-pasts, tÄlruÅa numurs utt.). PastÄv , un viss, kas nav iekļauts Å”ajÄ sarakstÄ, tiek uzskatÄ«ts par pasÅ«tÄ«jumu. TÄpÄc pirmais punkts, kam jÄpievÄrÅ” uzmanÄ«ba, ja vÄlaties izvÄlÄties esoÅ”u OIDC nodroÅ”inÄtÄju, ir iespÄja Ärti pielÄgot jaunus zÄ«molus.
PazÄ«mes grupa ir apvienota Å”ÄdÄ apakÅ”kopÄ - DarbÄ«bas joma. AutorizÄcijas laikÄ tiek pieprasÄ«ta piekļuve nevis konkrÄtiem zÄ«moliem, bet tvÄrumiem, pat ja daži no tvÄruma zÄ«moliem nav nepiecieÅ”ami.
2) Ieviesa nepiecieÅ”amÄs dotÄcijas
NÄkamÄ OIDC integrÄcijas daļa ir autorizÄcijas veidu, tÄ saukto grantu, izvÄle un ievieÅ”ana. TurpmÄkais mijiedarbÄ«bas scenÄrijs starp atlasÄ«to lietojumprogrammu un autorizÄcijas serveri bÅ«s atkarÄ«gs no izvÄlÄtÄs dotÄcijas. ParaugshÄma pareizÄs dotÄcijas izvÄlei ir parÄdÄ«ta attÄlÄ zemÄk.
PirmajÄ pieteikumÄ mÄs izmantojÄm visizplatÄ«tÄko dotÄciju ā AutorizÄcijas kodu. TÄ atŔķirÄ«ba no citiem ir tÄ, ka tÄ ir trÄ«spakÄpju, t.i. tiek veikta papildu pÄrbaude. PirmkÄrt, lietotÄjs veic autorizÄcijas atļaujas pieprasÄ«jumu, saÅem tokenu - AutorizÄcijas kodu, pÄc tam ar Å”o marÄ·ieri, it kÄ ar ceļojuma biļeti, pieprasa piekļuves pilnvaru. Visa Ŕī autorizÄcijas skripta galvenÄ mijiedarbÄ«ba ir balstÄ«ta uz novirzÄ«Å”anu starp lietojumprogrammu un autorizÄcijas serveri. JÅ«s varat lasÄ«t vairÄk par Å”o stipendiju .
OAuth ievÄro koncepciju, ka piekļuves marÄ·ieriem, kas iegÅ«ti pÄc autorizÄcijas, jÄbÅ«t Ä«slaicÄ«giem un jÄmainÄs, vÄlams vidÄji ik pÄc 10 minÅ«tÄm. AutorizÄcijas koda pieŔķirÅ”ana ir trÄ«s soļu pÄrbaude, izmantojot novirzÄ«Å”anu, ik pÄc 10 minÅ«tÄm pagriezt Å”Ädu soli, atklÄti sakot, nav tas patÄ«kamÄkais uzdevums acÄ«m. Lai atrisinÄtu Å”o problÄmu, ir vÄl viens grants - Refresh Token, ko izmantojÄm arÄ« mÅ«su valstÄ«. Å eit viss ir vieglÄk. Veicot verifikÄciju no cita granta, papildus galvenajam piekļuves pilnvaram tiek izsniegts vÄl viens - Refresh Token, kuru var izmantot tikai vienu reizi un tÄ kalpoÅ”anas laiks parasti ir daudz ilgÄks. Izmantojot Å”o atsvaidzinÄÅ”anas pilnvaru, kad beidzas galvenÄs piekļuves pilnvaras TTL (Time to Live), jaunas piekļuves pilnvaras pieprasÄ«jums nonÄks citas pieŔķirÅ”anas galapunktÄ. IzmantotÄ atsvaidzinÄÅ”anas pilnvara tiek nekavÄjoties atiestatÄ«ta uz nulli. Å Ä« pÄrbaude ir divpakÄpju, un to var veikt fonÄ, lietotÄjam nemanÄmi.
3) Iestatiet pielÄgotus datu izvades formÄtus
PÄc izvÄlÄto grantu ievieÅ”anas, autorizÄcijas nostrÄdÄÅ”anas, ir vÄrts pieminÄt datu iegÅ«Å”anu par gala lietotÄju. OIDC Å”im nolÅ«kam ir atseviŔķs galapunkts, kurÄ varat pieprasÄ«t lietotÄja datus ar savu paÅ”reizÄjo piekļuves pilnvaru un ja tie ir atjauninÄti. Un, ja lietotÄja dati nemainÄs tik bieži, un daudzkÄrt ir jÄseko lÄ«dzi esoÅ”ajiem, varat nonÄkt pie tÄda risinÄjuma kÄ JWT marÄ·ieri. Å os marÄ·ierus atbalsta arÄ« standarts. Pats JWT marÄ·ieris sastÄv no trim daļÄm: galvenes (informÄcija par marÄ·ieri), slodzes (jebkuri nepiecieÅ”amie dati) un paraksta (paraksts, marÄ·ieri paraksta serveris un vÄlÄk varat pÄrbaudÄ«t tÄ paraksta avotu).
OIDC ievieÅ”anÄ JWT marÄ·ieri sauc par id_token. To var pieprasÄ«t kopÄ ar parasto piekļuves pilnvaru, un atliek tikai pÄrbaudÄ«t parakstu. AutorizÄcijas serverim ir atseviŔķs galapunkts ar virkni publisko atslÄgu formÄtÄ . Un runÄjot par to, ir vÄrts pieminÄt, ka ir vÄl viens galapunkts, kas, pamatojoties uz standartu atspoguļo paÅ”reizÄjo OIDC servera konfigurÄciju. TajÄ ir visas galapunktu adreses (tostarp parakstÄ«Å”anai izmantotÄ publiskÄs atslÄgas gredzena adrese), atbalstÄ«tie zÄ«moli un tvÄrumi, izmantotie Å”ifrÄÅ”anas algoritmi, atbalstÄ«tÄs dotÄcijas utt.
PiemÄram, 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"
]
}TÄdÄjÄdi, izmantojot id_token, jÅ«s varat pÄrsÅ«tÄ«t visas nepiecieÅ”amÄs iezÄ«mes uz marÄ·iera lietderÄ«go slodzi un katru reizi nesazinÄties ar autorizÄcijas serveri, lai pieprasÄ«tu lietotÄja datus. Å Ä«s pieejas trÅ«kums ir tÄds, ka lietotÄja datu izmaiÅas no servera nenotiek uzreiz, bet kopÄ ar jaunu piekļuves pilnvaru.
ÄŖstenoÅ”anas rezultÄti
TÄtad, pÄc mÅ«su paÅ”u OIDC servera ievieÅ”anas un savienojumu konfigurÄÅ”anas ar to lietojumprogrammas pusÄ, mÄs atrisinÄjÄm informÄcijas pÄrsÅ«tÄ«Å”anas problÄmu par lietotÄjiem.
TÄ kÄ OIDC ir atvÄrts standarts, mums ir iespÄja izvÄlÄties esoÅ”u pakalpojumu sniedzÄju vai servera ievieÅ”anu. IzmÄÄ£inÄjÄm Keycloak, kas izrÄdÄ«jÄs ļoti Ärti konfigurÄjams, pÄc savienojuma konfigurÄciju iestatÄ«Å”anas un maiÅas aplikÄcijas pusÄ tas ir gatavs darbam. Lietojumprogrammas pusÄ atliek tikai mainÄ«t savienojuma konfigurÄcijas.
RunÄ par esoÅ”ajiem risinÄjumiem
MÅ«su organizÄcijas ietvaros kÄ pirmais OIDC serveris samontÄjÄm savu implementÄciju, kas tika papildinÄta pÄc nepiecieÅ”amÄ«bas. PÄc detalizÄtas citu gatavo risinÄjumu apskates varam teikt, ka tas ir strÄ«dÄ«gs jautÄjums. Par labu lÄmumam ieviest savu serveri, pakalpojumu sniedzÄji pauda bažas par vajadzÄ«gÄs funkcionalitÄtes trÅ«kumu, kÄ arÄ« par vecas sistÄmas klÄtbÅ«tni, kurÄ dažiem pakalpojumiem bija dažÄdas pielÄgotas autorizÄcijas un diezgan daudz. dati par darbiniekiem jau bija saglabÄti. TomÄr gatavÄs implementÄcijÄs ir integrÄcijas ÄrtÄ«bas. PiemÄram, Keycloak ir sava lietotÄju pÄrvaldÄ«bas sistÄma un dati tiek glabÄti tieÅ”i tajÄ, un apsteigt savus lietotÄjus tur nebÅ«s grÅ«ti. Lai to izdarÄ«tu, Keycloak ir API, kas ļaus pilnÄ«bÄ veikt visas nepiecieÅ”amÄs pÄrsÅ«tÄ«Å”anas darbÄ«bas.
VÄl viens sertificÄtas, interesantas, manuprÄt, ievieÅ”anas piemÄrs ir Ory Hydra. Tas ir interesanti, jo sastÄv no dažÄdÄm sastÄvdaļÄm. Lai integrÄtu, jums bÅ«s jÄsaista savs lietotÄju pÄrvaldÄ«bas pakalpojums ar viÅu autorizÄcijas pakalpojumu un pÄc vajadzÄ«bas jÄpaplaÅ”ina.
Keycloak un Ory Hydra nav vienÄ«gie pieejamie risinÄjumi. VislabÄk ir izvÄlÄties OpenID Foundation sertificÄtu ievieÅ”anu. Å iem risinÄjumiem parasti ir OpenID sertifikÄcijas emblÄma.
Neaizmirstiet arÄ« par esoÅ”ajiem maksas pakalpojumu sniedzÄjiem, ja nevÄlaties paturÄt savu OIDC serveri. Å odien ir daudz labu iespÄju.
Kas ir nÄkamais
TuvÄkajÄ laikÄ iekÅ”Äjiem pakalpojumiem slÄgsim satiksmi citÄdÄ veidÄ. MÄs plÄnojam pÄrsÅ«tÄ«t mÅ«su paÅ”reizÄjo SSO balansÄtÄjÄ, izmantojot OpenResty, uz starpniekserveri, kura pamatÄ ir OAuth. Å eit jau ir daudz gatavu risinÄjumu, piemÄram:
Papildu materiÄli
ā labs serviss JWT marÄ·ieru apstiprinÄÅ”anai
- sertificÄtu OIDC ievieÅ”anu saraksts
Avots: www.habr.com