Sawetara sasi kepungkur aku ngetrapake server OpenID Connect kanggo ngatur akses kanggo atusan aplikasi internal kita. Saka pangembangan kita dhewe, trep ing skala sing luwih cilik, kita pindhah menyang standar sing ditampa umum. Akses liwat layanan pusat kanthi nyata nyederhanakake operasi sing monoton, nyuda biaya kanggo ngetrapake wewenang, ngidini sampeyan nemokake akeh solusi sing wis siap lan ora ngrusak otak nalika ngembangake sing anyar. Ing artikel iki aku bakal ngomong babagan transisi iki lan benjolan sing bisa ditindakake.
Jaman biyen... Endi kabeh diwiwiti
Sawetara taun kepungkur, nalika aplikasi internal dadi akeh banget kanggo ngatur kanthi manual, kita nulis aplikasi kanggo ngontrol akses ing perusahaan. Iku aplikasi Rails prasaja sing nyambung menyang database karo informasi bab karyawan, ngendi akses kanggo macem-macem fungsi wis diatur. Ing wektu sing padha, kita ngluncurake SSO pisanan, sing adhedhasar verifikasi token ing bagean klien lan server wewenang; token kasebut dikirim ing wangun enkripsi kanthi sawetara parameter lan diverifikasi ing server wewenang. Iki ora pilihan sing paling trep, amarga saben aplikasi internal kudu njlèntrèhaké lapisan owahan saka logika, lan database pegawe padha rampung diselarasake karo server wewenang.
Sawise sawetara wektu, kita mutusake kanggo nyederhanakake tugas wewenang terpusat. SSO ditransfer menyang balancer. Kanthi bantuan OpenResty, cithakan ditambahake menyang Lua sing mriksa token, ngerti aplikasi sing arep dijaluk, lan bisa mriksa manawa ana akses ing kana. Pendekatan iki nyederhanakake tugas ngontrol akses menyang aplikasi internal - ora ana maneh perlu kanggo njlèntrèhaké logika tambahan ing kode saben aplikasi. Akibaté, kita nutup lalu lintas externally, nanging aplikasi dhewe ora ngerti apa-apa bab wewenang.
Nanging, siji masalah tetep ora rampung. Kepiye babagan aplikasi sing mbutuhake informasi karyawan? Sampeyan bisa nulis API kanggo layanan wewenang, nanging sampeyan kudu nambah logika tambahan kanggo saben aplikasi kasebut. Kajaba iku, kita pengin nyingkirake katergantungan ing salah sawijining aplikasi sing ditulis dhewe, sing luwih fokus ing terjemahan menyang OpenSource, ing server wewenang internal. Kita bakal ngandhani babagan iki ing wektu liyane. Solusi kanggo loro masalah kasebut yaiku OAuth.
Menyang standar sing ditampa umum
OAuth minangka standar wewenang sing jelas lan ditampa kanthi umum, nanging amarga fungsine ora cukup, OpenID Connect (OIDC) langsung dianggep. OIDC dhewe minangka implementasi katelu saka standar otentikasi mbukak, sing wis berkembang dadi superset protokol OAuth 2.0 (Open Authorization Protocol). Solusi iki ngatasi masalah kekurangan data babagan pangguna pungkasan, lan uga bisa ngganti panyedhiya wewenang.
Nanging, kita ora milih panyedhiya tartamtu lan mutusake kanggo nambah integrasi karo OIDC kanggo server wewenang sing wis ana. Kaputusan iki didhukung dening kasunyatan manawa OIDC fleksibel banget babagan wewenang pangguna pungkasan. Mangkono, sampeyan bisa ngetrapake dhukungan OIDC ing server wewenang sampeyan saiki.
Path kita kanggo ngleksanakake server OIDC kita dhewe
1) Nggawa data menyang formulir sing dibutuhake
Kanggo nggabungake OIDC, perlu kanggo nggawa data pangguna saiki menyang wangun sing bisa dingerteni standar. Ing OIDC iki diarani Klaim. Merek sejatine minangka kolom pungkasan ing basis data pangguna (jeneng, email, telpon, lsp.). ana , lan kabeh sing ora kalebu ing dhaftar iki dianggep adat. Mulane, titik pisanan sing kudu digatekake yen sampeyan pengin milih panyedhiya OIDC sing ana yaiku kemampuan kanggo ngatur prangko anyar kanthi gampang.
Klompok tandha digabungake menyang subset ing ngisor iki - Scope. Sajrone wewenang, akses dijaluk ora kanggo tandha tartamtu, nanging kanggo ruang lingkup, sanajan sawetara tandha saka ruang lingkup ora dibutuhake.
2) Dilaksanakake hibah sing dibutuhake
Bagian sabanjure integrasi OIDC yaiku pilihan lan implementasine jinis wewenang, sing diarani hibah. Skenario luwih saka interaksi antarane aplikasi sing dipilih lan server wewenang bakal gumantung saka hibah sing dipilih. Skema perkiraan kanggo milih hibah sing tepat ditampilake ing gambar ing ngisor iki.
Kanggo aplikasi pisanan, kita nggunakake hibah sing paling umum - Kode Wewenang. Bedane karo liyane yaiku telung langkah, yaiku. ngalami testing tambahan. Kaping pisanan, pangguna njaluk ijin ijin, nampa token Kode Otorisasi, banjur nganggo token iki, kaya tiket lelungan, njaluk token akses. Kabeh interaksi utama skenario wewenang iki adhedhasar pangalihan antarane aplikasi lan server wewenang. Sampeyan bisa maca liyane babagan hibah iki .
OAuth netepi konsep yen token akses sing ditampa sawise wewenang kudu sementara lan luwih becik ganti rata-rata saben 10 menit. Grant Kode Wewenang minangka verifikasi telung langkah liwat pangalihan; kanggo nindakake langkah kasebut saben 10 menit, terus terang, dudu tugas sing paling nyenengake. Kanggo ngatasi masalah iki, ana hibah liyane - Refresh Token, sing uga digunakake. Kabeh luwih prasaja ing kene. Sajrone verifikasi saka hibah liyane, saliyane token akses utama, siji liyane diterbitake - Token Refresh, sing mung bisa digunakake sapisan lan umure, minangka aturan, luwih suwe. Kanthi Token Refresh iki, nalika TTL (Wektu kanggo Urip) saka token akses utama rampung, panjalukan kanggo token akses anyar bakal teka ing titik pungkasan saka hibah liyane. Token Refresh sing digunakake langsung direset menyang nol. Priksa iki rong langkah lan bisa ditindakake ing latar mburi, tanpa digatekake pangguna.
3) Dikonfigurasi format output data pangguna
Sawise hibah sing dipilih dileksanakake, wewenang kasebut bisa digunakake, kudu disebutake panrimo data pangguna pungkasan. OIDC nduweni titik pungkasan sing kapisah kanggo iki, ing ngendi sampeyan bisa njaluk data pangguna nganggo token akses sampeyan saiki lan yen nganyari. Lan yen data pangguna ora asring owah-owahan, nanging sampeyan kudu golek sing saiki kaping pirang-pirang, sampeyan bisa nemokake solusi kayata token JWT. Token iki uga didhukung dening standar. Token JWT dhewe dumadi saka telung bagean: header (informasi babagan token), muatan (data sing dibutuhake) lan teken (tanda tangan, token ditandatangani dening server lan ing mangsa ngarep sampeyan bisa mriksa sumber teken).
Ing implementasine OIDC, token JWT diarani id_token. Bisa dijaluk bebarengan karo token akses biasa lan sing isih ana yaiku verifikasi teken. Kanggo tujuan iki, server wewenang duwe titik pungkasan sing kapisah kanthi pirang-pirang kunci umum ing format kasebut . Lan ngomong babagan iki, kudu dicathet yen ana titik pungkasan liyane, sing adhedhasar standar kasebut nggambarake konfigurasi saiki saka server OIDC. Isine kabeh alamat endpoint (kalebu alamat ring kunci umum digunakake kanggo mlebu), prangko didhukung lan orane katrangan, digunakake algoritma enkripsi, didhukung hibah, etc.
Contone ing 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"
]
}Mangkono, nggunakake id_token sampeyan bisa nransfer kabeh tandha sing perlu menyang payload token lan ora ngubungi server wewenang saben wektu kanggo njaluk data pangguna. Kerugian saka pendekatan iki yaiku owah-owahan data pangguna saka server ora langsung teka, nanging bebarengan karo token akses anyar.
Asil implementasine
Dadi, sawise ngleksanakake server OIDC dhewe lan nyetel sambungan menyang sisih aplikasi, kita ngrampungake masalah ngirim informasi pangguna.
Wiwit OIDC minangka standar mbukak, saiki kita duwe pilihan kanggo milih panyedhiya utawa implementasi server sing wis ana. Kita nyoba Keycloak, sing gampang banget dikonfigurasi; sawise nyetel lan ngganti konfigurasi sambungan ing sisih aplikasi, wis siyap. Ing sisih aplikasi, sing isih ana yaiku ngganti konfigurasi sambungan.
Ngomong babagan solusi sing wis ana
Ing organisasi kita, minangka server OIDC pisanan, kita ngumpulake implementasine dhewe, sing ditambah yen perlu. Sawise mriksa rinci babagan solusi siap liyane, kita bisa ujar manawa iki minangka titik kontroversial. Kaputusan kanggo ngetrapake server kita dhewe didorong dening keprihatinan saka panyedhiya babagan kekurangan fungsi sing dibutuhake, uga ana sistem lawas sing ngemot macem-macem wewenang khusus kanggo sawetara layanan lan wis disimpen cukup akeh data babagan karyawan. . Nanging, ing implementasine sing wis siap, ana kemudahan kanggo integrasi. Contone, Keycloak duwe sistem manajemen pangguna dhewe lan data disimpen langsung ing kono, lan mindhah pangguna sampeyan ora bakal angel. Kanggo maksud iki, Keycloak duwe API sing ngidini sampeyan nindakake kabeh tumindak transfer sing dibutuhake.
Conto liyane sing disertifikasi, menarik, miturut pendapatku, implementasine yaiku Ory Hydra. Iku menarik amarga kasusun saka komponen beda. Kanggo nggabungake, sampeyan kudu ngubungake layanan manajemen pangguna menyang layanan wewenang lan nggedhekake yen perlu.
Keycloak lan Ory Hydra ora mung solusi sing wis siap. Luwih becik milih implementasine sing disertifikasi dening OpenID Foundation. Solusi kasebut biasane duwe lencana Sertifikasi OpenID.
Uga aja lali babagan panyedhiya mbayar sing wis ana yen sampeyan ora pengin njaga server OIDC. Dina iki ana akeh pilihan apik.
Apa mbesuk
Ing mangsa ngarep, kita bakal nutup lalu lintas menyang layanan internal kanthi cara sing beda. Kita ngrencanakake migrasi SSO saiki ing balancer nggunakake OpenResty menyang proxy adhedhasar OAuth. Ana uga akeh solusi sing wis digawe ing kene, contone:
Bahan tambahan
- layanan apik kanggo mriksa token JWT
- dhaptar implementasi OIDC sing disertifikasi
Source: www.habr.com