Mõni kuu tagasi juurutasin OpenID Connecti serveri, et hallata juurdepääsu sadade meie sisemiste rakenduste jaoks. Enda arendustelt, mis on väiksemas mahus mugav, läksime üle üldtunnustatud standardile. Juurdepääs keskteenuse kaudu lihtsustab oluliselt monotoonseid toiminguid, vähendab autoriseerimiste juurutamise kulusid, võimaldab leida palju valmislahendusi ja mitte ajada pead uute väljatöötamisel. Selles artiklis räägin sellest üleminekust ja konarustest, mis meil õnnestus tabada.
Kaua aega tagasi... Kust see kõik alguse sai
Mitu aastat tagasi, kui sisemisi rakendusi sai käsitsi haldamiseks liiga palju, kirjutasime ettevõttesisese juurdepääsu kontrollimiseks rakenduse. Tegemist oli lihtsa Railsi rakendusega, mis ühendus töötajate infoga andmebaasiga, kus konfigureeriti ligipääs erinevatele funktsionaalsustele. Samal ajal käivitasime esimese SSO, mis põhines žetoonide kontrollimisel kliendi ja autoriseerimisserveri poolt, token edastati mitme parameetriga krüpteeritud kujul ja kontrolliti autoriseerimisserveris. See ei olnud kõige mugavam variant, kuna iga sisemine rakendus pidi kirjeldama märkimisväärset loogikat ja töötajate andmebaasid olid autoriseerimisserveriga täielikult sünkroonitud.
Mõne aja pärast otsustasime tsentraliseeritud autoriseerimise ülesannet lihtsustada. SSO kanti üle tasakaalustajale. OpenResty abil lisati Luale mall, mis kontrollis žetoone, teadis, millisesse rakendusse päring läheb ja sai kontrollida, kas seal on juurdepääs. Selline lähenemine lihtsustas oluliselt sisemiste rakenduste juurdepääsu kontrollimise ülesannet – iga rakenduse koodis ei olnud enam vaja kirjeldada täiendavat loogikat. Selle tulemusena sulgesime liikluse väliselt, kuid rakendus ise ei teadnud autoriseerimisest midagi.
Üks probleem jäi aga lahendamata. Kuidas on lood rakendustega, mis vajavad töötajate teavet? Autoriseerimisteenuse jaoks oli võimalik kirjutada API, kuid siis tuleks iga sellise rakenduse jaoks lisada täiendav loogika. Lisaks soovisime vabaneda sõltuvusest ühest meie enda kirjutatud rakendusest, mis keskendub veelgi OpenSource'i tõlkimisele, meie sisemise autoriseerimisserveri puhul. Me räägime teile sellest mõni teine kord. Mõlema probleemi lahendus oli OAuth.
Üldtunnustatud standardite poole
OAuth on selge, üldtunnustatud autoriseerimisstandard, kuid kuna selle funktsionaalsusest üksi ei piisa, hakati kohe kaaluma OpenID Connecti (OIDC) kasutamist. OIDC ise on avatud autentimisstandardi kolmas teostus, mis on arenenud OAuth 2.0 protokolli (Open Authorization Protocol) superkomplektiks. See lahendus lahendab lõppkasutaja kohta andmete puudumise probleemi ning võimaldab muuta ka autoriseerimise pakkujat.
Kuid me ei valinud konkreetset pakkujat ja otsustasime lisada oma olemasoleva autoriseerimisserveri integratsiooni OIDC-ga. Seda otsust toetas asjaolu, et OIDC on lõppkasutaja autoriseerimise osas väga paindlik. Seega oli võimalik OIDC tugi juurutada teie praeguses autoriseerimisserveris.
Meie tee oma OIDC serveri juurutamiseks
1) Viige andmed nõutavale vormile
OIDC integreerimiseks on vaja viia jooksvad kasutajaandmed standardile arusaadavale vormile. OIDC-s nimetatakse seda väideteks. Brändid on sisuliselt viimased väljad kasutajate andmebaasis (nimi, email, telefon jne). Olemas , ja kõike, mida selles loendis ei ole, peetakse kohandatuks. Seetõttu on esimene punkt, millele peate olemasoleva OIDC pakkuja valimisel tähelepanu pöörama, võimalus uusi templeid mugavalt kohandada.
Märkide rühm on ühendatud järgmiseks alamhulgaks – Ulatus. Autoriseerimisel ei taotleta juurdepääsu mitte konkreetsetele märkidele, vaid ulatustele, isegi kui mõnda ulatuse märgist pole vaja.
2) Rakendanud vajalikud toetused
OIDC integratsiooni järgmine osa on autoriseerimistüüpide, mida nimetatakse toetusteks, valimine ja rakendamine. Valitud rakenduse ja autoriseerimisserveri vahelise suhtluse edasine stsenaarium sõltub valitud toetusest. Õige toetuse valimise ligikaudne skeem on toodud alloleval joonisel.
Esimesel taotlusel kasutasime kõige tavalisemat toetust – autoriseerimiskoodi. Selle erinevus teistest seisneb selles, et see on kolmeastmeline, s.t. läbib täiendavaid katseid. Esmalt teeb kasutaja autoriseerimisloa taotluse, saab autoriseerimiskoodi tokeni, seejärel selle märgiga, nagu reisipiletiga, taotleb juurdepääsuluba. Selle autoriseerimisstsenaariumi kogu põhiline suhtlus põhineb rakenduse ja autoriseerimisserveri vahelisel ümbersuunamisel. Selle toetuse kohta saate rohkem lugeda .
OAuth järgib põhimõtet, et pärast autoriseerimist saadud juurdepääsulubad peaksid olema ajutised ja eelistatavalt muutuma keskmiselt iga 10 minuti järel. Autoriseerimiskoodi toetus on kolmeastmeline kinnitamine ümbersuunamiste kaudu, sellise sammu sooritamine iga 10 minuti järel ei ole ausalt öeldes silmale just kõige meeldivam ülesanne. Selle probleemi lahendamiseks on veel üks toetus - Refresh Token, mida ka kasutasime. Siin on kõik lihtsam. Teiselt lubadelt verifitseerimisel väljastatakse lisaks peamisele juurdepääsuloale veel üks - Refresh Token, mida saab kasutada ainult üks kord ja selle eluiga on reeglina oluliselt pikem. Kui peamise juurdepääsuloa TTL (Time to Live) lõpeb selle värskendusloaga, saadetakse uue juurdepääsuloa taotlus mõne teise loa lõpp-punkti. Kasutatud värskendusmärk nullitakse koheselt. See kontroll on kaheastmeline ja seda saab teha taustal, kasutajale märkamatult.
3) Konfigureeritud kasutajaandmete väljundvormingud
Kui valitud toetused on rakendatud, autoriseerimine toimib, tasub mainida lõppkasutaja andmete laekumist. OIDC-l on selleks eraldi lõpp-punkt, kust saate küsida kasutajaandmeid oma praeguse juurdepääsuloaga ja kui need on ajakohased. Ja kui kasutajaandmed ei muutu nii sageli, kuid peate mitu korda käima praeguste järgi, võite jõuda sellise lahenduseni nagu JWT märgid. Standard toetab ka neid märke. JWT token ise koosneb kolmest osast: päisest (teave tokeni kohta), kasulikust koormusest (kõik vajalikud andmed) ja signatuurist (signatuur, token allkirjastatakse serveri poolt ja edaspidi saab kontrollida selle allkirja allikat).
OIDC-rakenduses nimetatakse JWT-märki id_token. Seda saab taotleda koos tavalise juurdepääsumärgiga ja jääb üle vaid allkiri kontrollida. Selleks on autoriseerimisserveril eraldi lõpp-punkt, mille vormingus on hulk avalikke võtmeid . Ja sellest rääkides tasub mainida, et on veel üks lõpp-punkt, mis põhineb standardil peegeldab OIDC serveri praegust konfiguratsiooni. See sisaldab kõiki lõpp-punkti aadresse (sh allkirjastamiseks kasutatava avaliku võtmerõnga aadressi), toetatud templeid ja ulatuseid, kasutatud krüpteerimisalgoritme, toetatud toetusi jne.
Näiteks Google'is:
{
"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"
]
}Seega saate id_tokeni abil kõik vajalikud märgid tokeni kasulikku koormusse üle kanda ja mitte iga kord kasutajaandmete küsimiseks autoriseerimisserveriga ühendust võtta. Selle lähenemisviisi miinuseks on see, et serverist ei tule muudatused kasutajaandmetes kohe, vaid koos uue juurdepääsuloaga.
Rakendamise tulemused
Niisiis, pärast oma OIDC serveri juurutamist ja sellega ühenduse loomist rakenduse poolel, lahendasime kasutajateabe edastamise probleemi.
Kuna OIDC on avatud standard, on meil nüüd võimalus valida olemasolev pakkuja või serveri rakendus. Proovisime Keycloaki, mille seadistamine osutus väga lihtsaks, peale rakenduse poolel ühenduskonfiguratsioonide seadistamist ja muutmist on see kasutusvalmis. Rakenduse poolel jääb üle vaid ühenduse konfiguratsioone muuta.
Olemasolevatest lahendustest rääkimine
Oma organisatsiooni sees kogusime esimese OIDC serverina enda juurutuse, mida vajadusel täiendasime. Pärast teiste valmislahenduste üksikasjalikku uurimist võime öelda, et see on vastuoluline punkt. Otsuse oma server kasutusele võtta ajendas pakkujate mure vajaliku funktsionaalsuse puudumise pärast, aga ka vana süsteemi olemasolu, mis sisaldas teatud teenuste jaoks erinevaid kohandatud volitusi ja salvestas juba üsna palju andmeid töötajate kohta. . Valmisrakendustes on aga integreerimiseks mugavusi. Näiteks Keycloakil on oma kasutajahaldussüsteem ja andmed salvestatakse otse sinna ning oma kasutajate teisaldamine sinna ei ole keeruline. Sel eesmärgil on Keycloakil API, mis võimaldab teil kõik vajalikud ülekandetoimingud täielikult läbi viia.
Teine näide sertifitseeritud, minu arvates huvitavast rakendamisest on Ory Hydra. See on huvitav, kuna koosneb erinevatest komponentidest. Integreerimiseks peate oma kasutajahaldusteenuse linkima nende autoriseerimisteenusega ja vajadusel laiendama.
Keycloak ja Ory Hydra pole ainsad valmislahendused. Parim on valida OpenID Foundationi poolt sertifitseeritud rakendus. Nendel lahendustel on tavaliselt OpenID sertifikaadi märk.
Ärge unustage ka olemasolevaid tasulisi teenusepakkujaid, kui te ei soovi oma OIDC serverit alles jätta. Tänapäeval on palju häid võimalusi.
mis edasi
Lähiajal sulgeme liikluse siseteenustele teistmoodi. Kavatseme oma praeguse SSO tasakaalustusseadmes OpenResty abil üle viia OAuthil põhinevale puhverserverile. Siin on ka palju valmislahendusi, näiteks:
Lisamaterjalid
– hea teenus JWT žetoonide kontrollimiseks
— OIDC sertifitseeritud rakenduste loend
Allikas: www.habr.com