Prieš kelis mėnesius įdiegiau OpenID Connect serverį, kad galėčiau valdyti šimtų vidinių programų prieigą. Iš mūsų pačių sukurtų, patogių mažesniu mastu, perėjome prie visuotinai priimto standarto. Prieiga per centrinę paslaugą labai supaprastina monotoniškas operacijas, sumažina autorizacijų diegimo kaštus, leidžia rasti daug paruoštų sprendimų ir nesukelti galvos kuriant naujus. Šiame straipsnyje kalbėsiu apie šį perėjimą ir iškilimus, kuriuos pavyko užpildyti.
Seniai... Kaip viskas prasidėjo
Prieš keletą metų, kai buvo per daug vidinių programų rankiniam valdymui, mes parašėme prašymą kontroliuoti prieigą įmonės viduje. Tai buvo paprasta Rails programa, kuri prisijungė prie duomenų bazės su informacija apie darbuotojus, kur buvo sukonfigūruota prieiga prie įvairių funkcijų. Tuo pačiu metu iškėlėme pirmąjį SSO, kuris buvo pagrįstas žetonų patikrinimu iš kliento ir autorizacijos serverio pusės, tokenas buvo perduotas šifruota forma su keliais parametrais ir patikrintas autorizacijos serveryje. Tai nebuvo pats patogiausias variantas, nes kiekviena vidinė programa turėjo aprašyti nemažą logikos sluoksnį, o darbuotojų duomenų bazės buvo visiškai sinchronizuojamos su autorizacijos serveriu.
Po kurio laiko nusprendėme supaprastinti centralizuoto autorizavimo užduotį. SSO buvo perkeltas į balansuotoją. „OpenResty“ pagalba „Lua“ buvo pridėtas šablonas, kuris patikrino žetonus, žinojo, į kurią programą nukreipia užklausa, ir galėjo patikrinti, ar ten yra prieiga. Toks požiūris labai supaprastino prieigos prie vidinių programų valdymo užduotį – kiekvienos programos kode nebereikėjo aprašyti papildomos logikos. Dėl to srautą uždarėme išoriškai, o pati programa nieko nežinojo apie autorizavimą.
Tačiau viena problema liko neišspręsta. Ką apie programas, kurioms reikia informacijos apie darbuotojus? Buvo galima parašyti API autorizavimo paslaugai, bet tada kiekvienai tokiai programai tektų pridėti papildomos logikos. Be to, norėjome atsikratyti priklausomybės nuo vienos iš mūsų pačių parašytų programų, kurios ateityje bus skirtos vertimui į atvirąjį kodą, mūsų vidiniame autorizacijos serveryje. Apie tai pakalbėsime kitą kartą. Abiejų problemų sprendimas buvo OAuth.
pagal bendrus standartus
„OAuth“ yra suprantamas, visuotinai priimtas autorizacijos standartas, tačiau kadangi vien jo funkcionalumo neužtenka, jie iškart pradėjo svarstyti „OpenID Connect“ (OIDC). Pats OIDC yra trečiasis atvirojo autentifikavimo standarto įgyvendinimas, kuris buvo įtrauktas į priedą per OAuth 2.0 protokolą (atviras autorizacijos protokolas). Šis sprendimas pašalina duomenų apie galutinį vartotoją trūkumo problemą, taip pat leidžia pakeisti autorizacijos teikėją.
Tačiau mes nepasirinkome konkretaus teikėjo ir nusprendėme pridėti integraciją su OIDC prie esamo autorizacijos serverio. Šį sprendimą palankiai įvertino tai, kad OIDC yra labai lanksti galutinio vartotojo autorizavimo atžvilgiu. Taigi buvo įmanoma įdiegti OIDC palaikymą jūsų dabartiniame autorizacijos serveryje.
Mūsų būdas įdiegti savo OIDC serverį
1) Pateikite duomenis į norimą formą
Norint integruoti OIDC, būtina pateikti dabartinius vartotojo duomenis į standartui suprantamą formą. OIDC tai vadinama pretenzijomis. Pretenzijos iš esmės yra galutiniai naudotojų duomenų bazės laukai (vardas, el. pašto adresas, telefonas ir kt.). Egzistuoja , o viskas, kas neįtraukta į šį sąrašą, laikoma įprasta. Todėl pirmas dalykas, į kurį turite atkreipti dėmesį, jei norite pasirinkti esamą OIDC tiekėją, yra galimybė patogiai pritaikyti naujus prekės ženklus.
Skirtingų ženklų grupė sujungiama į tokį poaibį – Apimtis. Prieigos metu prašoma prieigos ne prie konkrečių prekių ženklų, o prie apimties, net jei kai kurie prekės ženklai iš aprėpties nėra reikalingi.
2) Įgyvendino reikiamas dotacijas
Kita OIDC integracijos dalis – autorizacijos tipų, vadinamųjų dotacijų, parinkimas ir įgyvendinimas. Tolesnis pasirinktos programos ir autorizacijos serverio sąveikos scenarijus priklausys nuo pasirinktos suteikimo. Pavyzdinė tinkamos dotacijos pasirinkimo schema parodyta paveikslėlyje žemiau.
Teikdami pirmąją paraišką, naudojome labiausiai paplitusią dotaciją – leidimo kodą. Jo skirtumas nuo kitų yra tas, kad tai yra trijų pakopų, t.y. atliekami papildomi tyrimai. Pirmiausia vartotojas pateikia užklausą dėl autorizacijos leidimo, gauna žetoną - Autorizacijos kodą, tada su šiuo žetonu, tarsi su kelionės bilietu, prašo prieigos žetono. Visa pagrindinė šio autorizacijos scenarijaus sąveika yra pagrįsta peradresavimu tarp programos ir autorizacijos serverio. Daugiau apie šią dotaciją galite perskaityti .
„OAuth“ laikosi koncepcijos, kad prieigos prieigos raktai, gauti po prieigos teisės, turėtų būti laikini ir keistis, pageidautina vidutiniškai kas 10 minučių. Autorizacijos kodo dotacija – tai patvirtinimas trimis žingsniais per nukreipimus, kas 10 minučių pasukti tokį žingsnį, atvirai kalbant, akiai ne pati maloniausia užduotis. Šiai problemai išspręsti yra dar viena dotacija – Refresh Token, kurią naudojome ir savo šalyje. Čia viskas paprasčiau. Tikrinant iš kitos dotacijos, be pagrindinio prieigos prieigos rakto, išduodamas dar vienas - Refresh Token, kurį galima naudoti tik vieną kartą ir jo tarnavimo laikas paprastai yra daug ilgesnis. Naudojant šį atnaujinimo prieigos raktą, kai baigiasi pagrindinės prieigos prieigos rakto TTL (Time to Live), naujo prieigos prieigos rakto užklausa pateks į kitos suteikimo galutinį tašką. Naudotas atnaujinimo prieigos raktas iš karto nustatomas į nulį. Šis patikrinimas yra dviejų etapų ir gali būti atliekamas fone, vartotojui nepastebimai.
3) Nustatykite pasirinktinius duomenų išvesties formatus
Įgyvendinus pasirinktas dotacijas, suveikia autorizacija, verta paminėti duomenų apie galutinį vartotoją gavimą. OIDC tam turi atskirą galutinį tašką, kuriame galite prašyti naudotojo duomenų naudodami dabartinį prieigos raktą ir jei jis yra atnaujintas. O jei vartotojo duomenys keičiasi ne taip dažnai, o reikia daug kartų sekti esamus, galite prieiti prie tokio sprendimo kaip JWT tokenai. Šiuos žetonus taip pat palaiko standartas. Pats JWT tokenas susideda iš trijų dalių: antraštės (informacija apie žetoną), naudingos apkrovos (bet kokie reikalingi duomenys) ir parašo (parašas, žetoną pasirašo serveris ir vėliau galėsite patikrinti jo parašo šaltinį).
OIDC diegime JWT prieigos raktas vadinamas id_token. Jo galima paprašyti kartu su įprastu prieigos raktu, o belieka tik patikrinti parašą. Prieigos serveris tam turi atskirą galutinį tašką su daugybe viešųjų raktų formatu . Ir kalbant apie tai, verta paminėti, kad yra dar vienas galutinis taškas, kuris, remiantis standartu atspindi dabartinę OIDC serverio konfigūraciją. Jame yra visi galinių taškų adresai (įskaitant pasirašymui naudojamo viešojo rakto žiedo adresą), palaikomi prekių ženklai ir apimtis, naudojami šifravimo algoritmai, palaikomos dotacijos ir kt.
Pavyzdžiui, 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"
]
}Taigi, naudodami id_token, galite perkelti visus reikalingus skiriamuosius ženklus į naudingąjį žetono apkrovą ir kiekvieną kartą nesikreipti į autorizacijos serverį prašydami vartotojo duomenų. Šio metodo trūkumas yra tas, kad vartotojo duomenų pakeitimas iš serverio ateina ne iš karto, o kartu su nauju prieigos raktu.
Įgyvendinimo rezultatai
Taigi, įdiegę savo OIDC serverį ir sukonfigūravę ryšius su juo programos pusėje, išsprendėme informacijos apie vartotojus perdavimo problemą.
Kadangi OIDC yra atviras standartas, turime galimybę pasirinkti esamą teikėją arba serverį. Išbandėme Keycloak, kurį konfigūruoti pasirodė labai patogu, sukonfigūravus ir pakeitus ryšio konfigūracijas aplikacijos pusėje, jis paruoštas darbui. Programos pusėje belieka pakeisti ryšio konfigūracijas.
Kalbama apie esamus sprendimus
Savo organizacijoje, kaip pirmasis OIDC serveris, surinkome savo diegimą, kuris pagal poreikį buvo papildytas. Išsamiai apžvelgę kitus paruoštus sprendimus, galime pasakyti, kad tai ginčytina. Priėmus sprendimą įdiegti savo serverį, tiekėjai susirūpino dėl to, kad nėra reikiamų funkcijų, taip pat dėl senos sistemos, kurioje kai kurioms paslaugoms buvo skirtingi pasirinktiniai leidimai ir gana daug. duomenų apie darbuotojus jau buvo saugoma. Tačiau jau paruoštuose diegimuose yra patogumų, susijusių su integravimu. Pavyzdžiui, „Keycloak“ turi savo vartotojų valdymo sistemą ir duomenys saugomi tiesiogiai joje, o ten aplenkti savo vartotojus nebus sunku. Norėdami tai padaryti, „Keycloak“ turi API, kuri leis visiškai atlikti visus būtinus perdavimo veiksmus.
Kitas sertifikuoto, įdomaus, mano nuomone, įgyvendinimo pavyzdys yra Ory Hydra. Tai įdomu, nes susideda iš skirtingų komponentų. Norėdami integruoti, turėsite susieti savo vartotojų valdymo paslaugą su jų autorizacijos paslauga ir prireikus išplėsti.
„Keycloak“ ir „Ory Hydra“ nėra vieninteliai parduodami sprendimai. Geriausia pasirinkti diegimą, sertifikuotą OpenID Foundation. Šie sprendimai paprastai turi OpenID sertifikavimo ženklelį.
Taip pat nepamirškite apie esamus mokamus tiekėjus, jei nenorite pasilikti savo OIDC serverio. Šiandien yra daug gerų variantų.
Kas toliau?
Artimiausiu metu ketiname kitu būdu uždaryti srautą į vidines paslaugas. Planuojame perkelti dabartinį SSO balansavimo priemonėje naudodami „OpenResty“ į tarpinį serverį, pagrįstą „OAuth“. Čia jau yra daug paruoštų sprendimų, pavyzdžiui:
Papildomos medžiagos
– gera paslauga JWT žetonų patvirtinimui
- sertifikuotų OIDC diegimų sąrašas
Šaltinis: www.habr.com