OpenID Connect: sisseelementide autoriseerimine kohandatud lahendustest standardini

Mõni kuu tagasi tegelesin OpenID Connect serveri rakendamisega, et hallata ligipääsu sadadele meie sisemistele rakendustele. Omandustest, mis olid mugavad väiksematel mastaapidel, liikusime üldiselt tunnustatud standardile. Ligipääs keskse teenuse kaudu lihtsustab oluliselt tüütuid toiminguid, vähendab autoriseerimiskulude rakendamise aega, võimaldab leida palju valmis lahendusi ega pane pead vaevama uute arendamisega. Selles artiklis räägin sellest üleminekust ja vigadest, mille oleme suutnud teha.

Kaua aega tagasi… Kuidas kõik algas

Mõni aasta tagasi, kui sisemisi rakendusi oli liiga palju, et käsitsi hallata, kirjutasime ligipääsuhaldusrakenduse ettevõtte sees. See oli lihtne Rails-rakendus, mis lõpuks ühendati töötajate teabega andmebaasi, kus seadistati ligipääs erinevatele funktsioonidele. Samuti tõime esmakordselt välja SSO, mis põhines kliendi ja autoriseerimisteenuse tokenite kontrollimisel, token edastati krüpteeritud kujul mitmete parameetritega ja kontrolliti autoriseerimisteenuses. See ei olnud kõige mugavam variant, sest igas sisemises rakendus oli vaja kirjeldada märkimisväärset loogikakihti, ning töötajate andmebaasid ei sünkroonitud autoriseerimisteenusega.

Mõne aja pärast otsustasime lihtsustada tsentraliseeritud autoriseerimise ülesannet. SSO viidi koormustaseme käsitlemisele. OpenResty abil Lua-s lisasime šablooni, mis kontrollis tokenid, teadis, kuhu rakendusse päring läheb, ja sai kontrollida, kas sinna on ligipääs. Selline lähenemine lihtsustas oluliselt ligipääsu kontrollimise ülesannet sisemistes rakendustes — iga rakenduse koodis ei olnud enam vaja kirjeldada täiendavat loogikat. Lõpuks sulgesime liikluse väljastpoolt ja rakendus ei teadnud autoriseerimisest midagi.

Siiski jäi üks probleem lahendamata. Kuidas olla rakendustega, mis vajavad teavet töötajate kohta? API kirjutamine autentimisteenusele oleks võimalik, kuid sel juhul tuleks igasse taolisse rakendusse lisada täiendav loogika. Lisaks soovisime vabaneda sõltuvusest meie ühisest kohandatud rakendusest, mis oli suunatud edasisele üleminekule OpenSource'ile, meie sisemisest autentimiserverist. Räägime sellest kunagi hiljem. Lahenduseks mõlemale probleemile sai OAuth.

Tavapärased standardid

OAuth on arusaadav, laialdaselt tunnustatud autentimisstandard, kuid kuna ainult selle funktsionaalsus ei olnud piisav, hakati kaaluma ka OpenID Connect (OIDC). OIDC on avatud autentimisestandardite kolmas uus rakendus, mis on ehitatud OAuth 2.0 (avatud autoriseerimise protokoll) peale. Selline lahendus lahendab lõppkasutaja teabe puudumise probleemi ning võimaldab autoriseerimise teenuse pakkuja vahetamist.

Kuid me ei valinud konkreetset pakkujat ja otsustasime meie olemasolevale autentimisteenusele lisada OIDC integreerimise. Sellega kaasnenud eelised seisnesid OIDC paindlikkuses lõppkasutaja autoriseerimises. Nii oli meil võimalik OIDC toetust rakendada oma praeguses autentimisteenuses.

Meie tee oma OIDC-serveri rakendamiseni

1) Andmed viidi õigele kujule

OIDC integreerimiseks on oluline viia olemasolevad kasutajaandmed vormingusse, mis on standardile arusaadav. OIDC-s nimetatakse seda Claims'iks. Kleepsud on põhimõtteliselt lõplikud väljad kasutajate andmebaasis (nimi, e-post, telefon jne). On olemas standardne nimekiri kleepsudest, ja kõik, mis ei kuulu sellesse nimekirja, peetakse kohandatuks. Seetõttu on esimene punkt, millele peate tähelepanu pöörama, kui soovite valida olemasoleva OIDC pakkuja – uute kleepsude mugav kohandamise võimalus.

Kleepsute rühm koondub järgnevasse alamkogusse – Scope. Autoriseerimisel esitatakse juurdepääsu taotlus mitte konkreetsetele kleepsudele, vaid just nimelt skoopidele, isegi kui osa skoopi kleepsudest pole vajalikud.

2) Rakendati vajalikud grant'id

OIDC integreerimise järgmine osa on autoriseerimise tüüpide valik ja rakendamine, nn grant'id. Valitud grant mõjutab edasist koostoime stseeni valitud rakenduse ja autoriseerimisserveri vahel. Sobiva grant'i valimise ligikaudne skeem on esitatud alloleval joonisel.

Meie esimese rakenduse jaoks kasutasime kõige levinumat grant'i – Autoriseerimiskood. Selle erinevus teistest on see, et see on kolmeastmeline, st see läbib täiendava kontrolli. Esiteks esitab kasutaja autoriseerimise loa taotluse, saab tokeni – Autoriseerimiskoodi, seejärel küsib ta selle tokeniga, nagu piletiga, juurdepääsu tokenit. Kõik põhikoostöö selle autoriseerimistootmis stseeniga põhineb ümbersuunangutel rakenduse ja autoriseerimisserveri vahel. Lisainfot selle grant'i kohta saab lugeda siin.

OAuth järgib kontseptsiooni, et autoriseerimise käigus saadud juurdepääsu tokenid peaksid olema ajutised ja neid tuleks muuta, eelistatavalt iga 10 minuti tagant. Autoriseerimiskoodi grant on kolmeastmeline kontroll ümbersuunangute kaudu, iga 10 minuti tagant sellise sammu läbimine ei ole ausalt öeldes kõige meeldivam ajaviide. Selle probleemi lahendamiseks on olemas veel üks grant – Refresh Token, mida oleme ka enda juures kasutanud. Siin on kõik lihtsam. Teise grant'i kontrolli käigus, peale peamise juurdepääsu tokeni, antakse välja veel üks – Refresh Token, mida saab kasutada ainult üks kord ja mille eluiga on reeglina oluliselt pikem. Selle Refresh Token'iga, kui peamise juurdepääsu tokeni TTL (Time to Live) lõppeb, tuleb uue juurdepääsu tokeni taotlus juba teise grant'i endpoint'ile. Kasutatud Refresh Token nullitakse kohe. Selline kontroll on kaheastmeline ja seda saab teostada taustal, kasutajale märkamatult.

3) Kohandatud kasutajateabe väljastamise formaadid on seadistatud

Pärast projekti elluviimist ja autentimise korraldamist tasub mainida lõppkasutaja andmete saamist. OIDCi puhul on selle jaoks eraldi lõpp-punkt, kus saab oma praeguse juurdepäsutunnuse kehtivuse korral taotleda kasutajate andmeid. Ja kui kasutaja andmed ei muutu nii tihti, kuid nende järele on tihti vajadus, võib lahenduseks olla JWT-tunnused. Need tunnused on samuti standardiga kooskõlas. Igal JWT-tunnusel on kolm osa: header (tunnuse teave), payload (vajalikud andmed) ja signature (tunnus, mille allkirjastab server ja mida saab hiljem allkirja kehtivust kontrollida).

OIDC rakenduses nimetatakse JWT-tunnust id_token. Seda saab taotleda koos tavalisel juurdepäsutunnusega ning ainus, mis jääb, on allkirja kontrollimine. Autoriseerimisserveril on selle jaoks eraldi lõpp-punkt, mis sisaldab avalike võtmete seotust formaadis JWK. Rääkides sellest, tasub mainida, et eksisteerib veel üks lõpp-punkt, mis standardi alusel RFC5785 peegeldab praegust OIDC-serveri konfiguratsiooni. Seal on loetletud kõik lõpp-punktide aadressid (sealhulgas avalike võtmete seotuse aadress, mida kasutatakse allkirjastamiseks), toetatud claim'id ja ulatused, kasutatavad krüptimisalgoritmid, toetatud grant'id 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 saab id_token'i abil edastada kõik vajalikud väidetud payload'i ja ei pea iga kord volituse serveri poole pöörduma, et kasutaja andmeid küsida. Selle lähenemise miinuseks on see, et muudatused kasutaja andmetes serverist ei saabu kohe, vaid koos uue juurdepääsu tokeniga.

Teostuse tulemused

Nii, pärast oma OIDC serveri rakendamist ja selle seadistamist rakenduste küljel, lahendasime kasutaja teabe edastamise probleemi.
Kuna OIDC on avatud standard, on meil võimalus valida olemasolev teenusepakkuja või rakendada server. Proovisime Keycloak'i, mis osutus väga mugavaks konfigureerimiseks; pärast seadistamise ja ühenduskonfiguratsioonide muutmist rakenduste küljel on see tööks valmis. Rakenduste küljel jääb ainult muuta ühenduskonfiguratsioonid.

Rääkides olemasolevatest lahendustest

Meie organisatsiooni raames kogusime esimese OIDC serverina oma implementatsiooni, mida täiendati vajadusel. Pärast teiste olemasolevate lahenduste põhjalikku uurimist võib öelda, et see on vaieldav teema. Oma serveri rakenduse kasuks mängisid rolli teenusepakkujate mured vajaliku funktsionaalsuse puudumise üle, samuti olemasoleva vanade süsteemide tõttu, kus oli erinevaid kohandatud volitusi mõne teenuse jaoks ja kus on juba kogunenud palju töötajate andmeid. Kuid valmislahendustes on integreerimise mugavused. Näiteks Keycloak'il on oma kasutajate haldamise süsteem ja andmed hoitakse otse seal; oma kasutajate sinna toimetamine ei ole suur probleem. Selleks on Keycloak'is API, mis võimaldab täielikult teostada kõiki vajalikke toiminguid andmete edastamiseks.

Veel üks sertifitseeritud ja huvitav, minu arvates, rakendus — Ory Hydra. See on huvitav kuna see on üles ehitatud erinevatest komponentidest. Integreerimiseks peate siduma oma kasutajahaldus teenuse nende autoriseerimise teenusega ja laiendama seda vajadusel.

Keycloak ja Ory Hydra ei ole ainus valmis lahendused. Parim on valida sertifitseeritud OpenID Foundation'i lahendus. Loomulikult on sellistel lahendustel OpenID sertifitseerimise märge.

Ärge unustage olemasolevaid tasulisi teenusepakkujaid, kui te ei soovi hoida oma OIDC serverit. Tänapäeval on palju häid võimalusi.

Mis edasi

Peatselt plaanime suunata liikluse siseteenustele muul viisil. Kavatseme viia meie praeguse SSO koormustasakaidiku OpenResty kaudu proxisse, mille aluseks on OAuth. Siin on juba palju valmis lahendusi, näiteks:
github.com/bitly/oauth2_proxy
github.com/ory/oathkeeper
github.com/keycloak/keycloak-gatekeeper

Lisaressursid

jwt.io – hea teenus JWT-tokenite kontrollimiseks
openid.net/developers/certified — sertifitseeritud OIDC rakenduste nimekiri

Allikas: habr.com