Dina sagala parusahaan badag, sarta X5 Retail Grup aya iwal, sakumaha kamajuan progresses, jumlah proyék nu merlukeun otorisasina pamaké nambahan. Kana waktosna, transisi anu lancar tina pangguna tina hiji aplikasi ka aplikasi anu sanés diperyogikeun teras peryogi nganggo server Single-Sing-On (SSO) tunggal. Tapi naon anu kudu dilakukeun nalika panyadia identitas sapertos AD atanapi anu sanés anu henteu ngagaduhan atribut tambahan parantos dianggo dina sababaraha proyék. Hiji kelas sistem disebut "calo idéntifikasi" bakal datang ka nyalametkeun teh. Anu paling fungsional nyaéta wawakilna, sapertos Keycloak, manajemén Aksés Gravitee, jsb. Paling sering, skenario pamakean tiasa bénten-béda: interaksi mesin, partisipasi pangguna, jsb. sareng solusi sapertos perusahaan urang ayeuna gaduh calo indikasi - Keycloak.
Keycloak mangrupikeun identitas sumber terbuka sareng produk kontrol aksés anu dijaga ku RedHat. Éta mangrupikeun dasar pikeun produk perusahaan nganggo SSO - RH-SSO.
konsep dasar
Sateuacan anjeun ngawitan ngartos solusi sareng pendekatan, anjeun kedah ngartikeun istilah sareng urutan prosés:
pangenalan mangrupa prosedur pikeun ngakuan hiji subyek ku identifier na (dina basa sejen, ieu nangtukeun ngaran, login atawa nomer).
Konfirmasi - ieu mangrupikeun prosedur auténtikasi (pamaké diverifikasi nganggo kecap akses, suratna diverifikasi nganggo tanda tangan éléktronik, jsb.)
mieun kuwasa - nyadiakeun aksés ka sumber daya (contona, email).
Keycloak Identity calo
keycloak mangrupa identitas open source sarta solusi manajemén aksés dirancang pikeun pamakéan di IS dimana pola arsitéktur microservice bisa dipaké.
Keycloak nawiskeun fitur sapertos single sign-on (SSO), identitas brokered sareng login sosial, federasi pangguna, adaptor klien, konsol admin sareng konsol manajemén akun.
Fungsi dasar anu dirojong ku Keycloak:
- Single-Sign On sareng Single-Sign Out pikeun aplikasi browser.
- OpenID / OAuth 2.0 / rojongan SAML.
- Identity Brokering - auténtikasi nganggo OpenID Connect éksternal atanapi panyadia identitas SAML.
- Login Sosial - rojongan pikeun Google, GitHub, Facebook, Twitter pikeun idéntifikasi pamaké.
- Féderasi Pamaké - singkronisasi pangguna tina server LDAP sareng Active Directory sareng panyadia identitas sanés.
- sasak Kerberos - ngagunakeun server Kerberos pikeun auténtikasi pamaké otomatis.
- Konsol Admin - pikeun manajemén ngahijikeun setelan sareng parameter solusi liwat Wéb.
- Konsol Manajemén Akun - pikeun manajemén profil pangguna mandiri.
- Kustomisasi solusi dumasar kana identitas perusahaan perusahaan.
- Auténtikasi 2FA - Pangrojong TOTP / HOTP nganggo Google Authenticator atanapi FreeOTP.
- Aliran Login - pendaptaran diri pangguna, pamulihan kecap konci sareng reset, sareng anu sanésna mungkin.
- Manajemén Sesi - pangurus tiasa ngatur sesi pangguna tina hiji titik.
- Token Mappers - atribut pamaké mengikat, kalungguhan jeung atribut sejenna diperlukeun pikeun tokens.
- manajemén kawijakan fléksibel ngaliwatan realm, aplikasi tur pamaké.
- Rojongan CORS - Adaptor klien ngagaduhan dukungan CORS asli.
- Antarmuka Panyadia Ladénan (SPI) - Sajumlah ageung SPI anu ngamungkinkeun anjeun ngaluyukeun sagala rupa aspék server: aliran auténtikasi, panyadia identitas, pemetaan protokol, sareng seueur deui.
- Adaptor klien pikeun aplikasi JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Rojongan pikeun gawé bareng rupa-rupa aplikasi nu ngarojong OpenID Connect Relying Party library atawa SAML 2.0 Service Provider Library.
- Expandable ngagunakeun plugins.
Pikeun prosés CI/CD, ogé otomatisasi prosés manajemén dina Keycloak, REST API/JAVA API tiasa dianggo. Dokuméntasi sayogi sacara éléktronik:
sesa API
API JAVA
Panyadia Idéntitas Perusahaan (Di Tempat)
Kamungkinan auténtikasi pamaké ngaliwatan jasa Federation pamaké.
Auténtikasi pass-through ogé tiasa dianggo - upami pangguna dioténtikasi dina stasiun kerja nganggo Kerberos (LDAP atanapi AD), maka aranjeunna tiasa otomatis dioténtikasi kana Keycloak tanpa kedah masihan nami pangguna sareng kecap konci deui.
Pikeun auténtikasi jeung otorisasi salajengna pamaké, kasebut nyaéta dimungkinkeun pikeun ngagunakeun DBMS relational, nu paling lumaku pikeun lingkungan ngembangkeun, sabab teu ngalibetkeun setelan lengthy sarta integrations dina tahap awal proyék. Sacara standar, Keycloak ngagunakeun DBMS anu diwangun pikeun nyimpen setélan sareng data pangguna.
Daptar DBMS anu dirojong sacara éksténsif sareng kalebet: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle sareng anu sanésna. Anu paling diuji ayeuna nyaéta Oracle 12C Release1 RAC sareng Galera 3.12 klaster pikeun MariaDB 10.1.19.
Panyadia identitas - login sosial
Kasebut nyaéta dimungkinkeun pikeun ngagunakeun login tina jaringan sosial. Pikeun ngaktifkeun kamampuan ngaoténtikasi pangguna, paké konsol admin Keycloack. Taya parobahan kode aplikasi diperlukeun tur fungsionalitas ieu sadia out of the box tur bisa diaktipkeun dina sagala tahapan proyek.
Pikeun ngaoténtikasi pangguna, anjeun tiasa nganggo panyadia OpenID/SAML Identity.
Skenario otorisasina biasa nganggo OAuth2 di Keycloak
Aliran Kode Otorisasi - dipaké kalawan aplikasi server-sisi. Salah sahiji jinis idin otorisasi anu paling umum sabab éta cocog pikeun aplikasi server dimana kode sumber aplikasi sareng data klien henteu sayogi pikeun urang luar. Prosés dina hal ieu dumasar kana redirection. Aplikasina kedah tiasa berinteraksi sareng agén pangguna (agén-pamaké), sapertos browser wéb - pikeun nampi kode otorisasi API anu dialihkeun ngalangkungan agén pangguna.
Aliran Implisit - dianggo ku aplikasi sélulér atanapi wéb (aplikasi anu dijalankeun dina alat pangguna).
Jinis idin otorisasi implisit dianggo ku aplikasi mobile sareng wéb dimana privasi klien teu tiasa dijamin. Jenis idin implisit ogé ngagunakeun alihan agén pamaké, dimana token aksés disalurkeun ka agén pamaké pikeun pamakéan engké dina aplikasi. Hal ieu ngajadikeun token sadia pikeun pamaké sarta aplikasi sejenna dina alat pamaké. Jenis idin otorisasi ieu henteu ngabuktoskeun kaaslianana idéntitas aplikasi, sareng prosésna sorangan ngandelkeun URL alihan (saméméhna didaptarkeun sareng jasa).
Aliran implisit henteu ngadukung token refresh token aksés.
Aliran hibah Kapercayaan klien - dipaké nalika aplikasi ngakses API. Jenis idin otorisasi ieu biasana dianggo pikeun interaksi server-to-server anu kedah lumangsung di latar tukang tanpa interaksi pangguna langsung. Aliran hibah kredensial klien ngamungkinkeun hiji layanan wéb (klien rahasia) ngagunakeun kredensial sorangan tinimbang niru pamaké pikeun auténtikasi nalika nelepon jasa wéb anu sanés. Pikeun tingkat kaamanan anu langkung luhur, tiasa waé jasa nelepon nganggo sertipikat (tinimbang rahasia anu dibagikeun) salaku kapercayaan.
Spésifikasi OAuth2 dijelaskeun dina
Token JWT sareng kauntunganana
JWT (JSON Web Token) mangrupikeun standar terbuka (), anu netepkeun cara anu kompak sareng mandiri pikeun mindahkeun inpormasi anu aman antara pihak-pihak dina bentuk objék JSON.
Numutkeun standar, token diwangun ku tilu bagian dina format base-64, dipisahkeun ku titik-titik. Bagian kahiji disebut lulugu, anu ngandung jinis token sareng nami algoritma hash pikeun kéngingkeun tandatangan digital. Bagian kadua nyimpen informasi dasar (pamaké, atribut, jsb). Bagian katilu nyaéta tanda tangan digital.
. .
Pernah nyimpen token dina DB Anjeun. Kusabab token valid sarua jeung kecap akses, nyimpen token sarua jeung nyimpen kecap akses dina téks jelas.
token aksés mangrupikeun token anu masihan aksés anu gaduhna pikeun ngamankeun sumber daya server. Biasana hirupna pondok sareng tiasa nyandak inpormasi tambahan sapertos alamat IP pihak anu menta token.
Refresh token mangrupakeun token anu ngamungkinkeun para klien pikeun menta token aksés anyar sanggeus umur maranéhanana kadaluwarsa. Token ieu biasana dikaluarkeun kanggo waktos anu lami.
Kaunggulan utama ngagunakeun arsitéktur microservice:
- Kamampuhan pikeun ngaksés rupa-rupa aplikasi sareng jasa ngaliwatan auténtikasi hiji-waktos.
- Dina henteuna sababaraha atribut diperlukeun dina profil pamaké, kasebut nyaéta dimungkinkeun pikeun enrich ku data nu bisa ditambahkeun kana payload nu, kaasup otomatis tur on-the-fly.
- Henteu kedah nyimpen inpormasi ngeunaan sési aktip; aplikasi server ngan ukur kedah pariksa tandatangan.
- kontrol aksés leuwih fléksibel ngaliwatan atribut tambahan dina payload nu.
- Pamakéan tanda tangan token pikeun header sareng payload ningkatkeun kaamanan solusi sacara gembleng.
JWT token - komposisi
lulugu — sacara standar, lulugu ngan ngandung jinis token sareng algoritma anu dianggo pikeun énkripsi.
Jinis token disimpen dina konci "typ". The "typ" konci teu dipaliré di JWT. Upami konci "typ" aya, nilaina kedah JWT pikeun nunjukkeun yén objék ieu mangrupikeun Token Wéb JSON.
Konci kadua "alg" netepkeun algoritma anu dianggo pikeun énkripsi token. Sacara standar kudu disetel ka HS256. Lulugu disandikeun dina base64.
{ "alg": "HS256", "typ": "JWT"}
Payload (eusi) - payload nyimpen inpormasi naon waé anu kedah diverifikasi. Unggal konci dina payload katelah "pernyataan". Contona, Anjeun bisa ngasupkeun aplikasi ngan ku uleman (promosi katutup). Nalika urang hoyong ngajak batur pikeun ilubiung, urang ngirimkeun email uleman. Penting pikeun pariksa yén alamat email éta milik jalma anu nampi uleman, janten kami bakal ngalebetkeun alamat ieu dina payload ku cara nyimpenna dina konci "email".
{ "surélék": "[email dijaga]"}
Konci dina payload tiasa sawenang-wenang. Sanajan kitu, aya sababaraha ditangtayungan:
- iss (Pamedal) - nangtukeun aplikasi ti mana token dikirim.
- sub (Subject) - ngahartikeun subyek token nu.
- aud (Audience) - hiji Asép Sunandar Sunarya hal-sénsitip string atawa URIs nu mangrupa daptar panarima tina token ieu. Nalika pihak anu nampi nampi JWT kalayan konci anu dipasihkeun, éta kedah parios nyalira dina panarima - upami henteu malire token.
- exp (Waktu béakna) - Nunjukkeun nalika token kadaluwarsa. Standar JWT ngabutuhkeun yén sadaya palaksanaan nampik token anu kadaluwarsa. Konci Exp kedah janten stempel waktos dina format unix.
- nbf (Henteu Sateuacan) mangrupikeun waktos dina format unix anu nangtukeun momen nalika token janten sah.
- iat (Dikaluarkeun Dina) - Konci ieu ngagambarkeun waktos token dikaluarkeun sareng tiasa dianggo pikeun nangtukeun umur JWT. Konci iat kedah janten timestamp dina format unix.
- Jti (JWT ID) mangrupikeun senar anu ngahartikeun identifier sénsitip hal-hal unik pikeun token ieu.
Kadé ngartos yen payload teu dikirimkeun énkripsi (sanajan tokens bisa nested lajeng kasebut nyaéta dimungkinkeun pikeun ngirimkeun data énkripsi). Ku alatan éta, anjeun teu bisa nyimpen sagala informasi rusiah di dinya. Sapertos header, payload nyaéta base64 disandi.
tekenan - sakali kami boga lulugu jeung payload, urang bisa ngitung signature nu.
Lulugu jeung payload disandikeun dina base64 dicokot tur digabungkeun kana garis dipisahkeun ku titik. Ieu string jeung konci rusiah lajeng input kana algoritma enkripsi dieusian dina lulugu (konci "alg"). Koncina tiasa waé senar. Senar anu langkung panjang bakal langkung dipikaresep sabab peryogi langkung waktos pikeun milih.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Ngawangun Arsitéktur Kluster Keycloak Failover
Lamun maké klaster tunggal pikeun sakabéh proyék, aya ngaronjat sarat pikeun solusi SSO. Nalika jumlah proyék leutik, sarat ieu teu jadi pinunjul pikeun sakabéh proyék, kumaha oge, sakumaha jumlah pamaké sarta integrations naek, sarat pikeun kasadiaan sarta kinerja ningkat.
Ngaronjatna résiko gagalna SSO tunggal ningkatkeun syarat pikeun arsitéktur solusi sareng metode anu dianggo pikeun redundansi komponén sareng nyababkeun SLA anu ketat pisan. Dina hal ieu, langkung sering nalika pangwangunan atanapi tahap awal palaksanaan solusi, proyék-proyék gaduh infrastruktur anu henteu toleran-lepat sorangan. Nalika pangwangunan maju, diperyogikeun pikeun iklas kasempetan pikeun pangwangunan sareng skala. Cara anu paling fleksibel pikeun ngawangun klaster failover nyaéta ngagunakeun virtualisasi wadahna atanapi pendekatan hibrida.
Pikeun digawé di Active / Active jeung Active / Pasif mode klaster, perlu pikeun mastikeun konsistensi data dina database relational - duanana titik database kudu synchronously replicated antara puseur data geo-disebarkeun béda.
Conto pangbasajanna tina instalasi toleran kasalahan.
Naon kaunggulan ngagunakeun klaster tunggal:
- kasadiaan tinggi jeung kinerja.
- Modeu operasi Rojongan: Aktif / Aktif, Aktif / Pasip.
- Kamampuhan pikeun skala dinamis - nalika nganggo virtualisasi wadahna.
- Kamungkinan manajemén terpusat sareng ngawaskeun.
- Pendekatan anu ngahijikeun pikeun ngaidentipikasi / ngaoténtikasi / otorisasi pangguna dina proyék.
- Interaksi anu langkung transparan antara proyék anu béda tanpa interaksi pangguna.
- Kamungkinan ngagunakeun deui token JWT dina sababaraha proyék.
- Hiji titik kapercayaan.
- Peluncuran proyék anu langkung gancang nganggo microservices / virtualization wadahna (teu kedah masang sareng ngonpigurasikeun komponén tambahan).
- Kasebut nyaéta dimungkinkeun pikeun mésér dukungan komérsial ti anu ngajual.
Naon Anu Dipilarian Nalika Ngarencanakeun Kluster
DBMS
Keycloak ngagunakeun sistem manajemen DBMS pikeun nyimpen: realms, klien, pamaké, jsb.
Rupa-rupa DBMS dirojong: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak hadir kalawan database relational diwangun-di sorangan. Disarankeun pikeun dianggo dina lingkungan anu ringan, sapertos lingkungan pamekaran.
Pikeun digawé di Active / Active jeung Active / Pasif mode klaster, perlu pikeun mastikeun konsistensi data dina database relational sarta duanana titik tina klaster database anu synchronously replicated antara puseur data.
Cache anu disebarkeun (Infinspan)
Pikeun kluster tiasa dianggo leres, singkronisasi tambahan tina jinis cache ieu nganggo JBoss Data Grid diperyogikeun:
Sesi auténtikasi - dipaké pikeun nyimpen data nalika ngaoténtikasi pamaké husus. Paménta ti cache ieu biasana ngan ukur ngalibatkeun browser sareng server Keycloak, sanés aplikasi.
Token aksi - dipaké pikeun skenario dimana pamaké kudu mastikeun hiji aksi asynchronously (via email). Contona, dina mangsa aliran poho sandi, Infinispan actionTokens cache dipaké pikeun ngalacak metadata ngeunaan tokens aksi pakait nu geus dipaké, jadi teu bisa dipaké deui.
Caching jeung invalidation data pengkuh - dipaké pikeun cache data pengkuh pikeun nyegah queries perlu kana database. Nalika sagala server Keycloak ngamutahirkeun data, sadaya server Keycloak sejenna dina sakabéh puseur data kudu nyaho ngeunaan eta.
Gawé - Dipaké ngan pikeun ngirim pesen invalidation antara titik klaster jeung puseur data.
Sesi pamaké - dipaké pikeun nyimpen data sési pamaké nu valid pikeun durasi sési browser pamaké. Cache kedah ngadamel pamundut HTTP ti pangguna akhir sareng aplikasi.
Perlindungan gaya brute - dipaké pikeun ngalacak data ngeunaan logins gagal.
Balancing beban
Load balancer mangrupikeun titik éntri tunggal pikeun keycloak sareng kedah ngadukung sési caket.
Pangladén aplikasi
Éta dipaké pikeun ngadalikeun interaksi komponén saling sarta bisa virtualized atanapi containerized ngagunakeun parabot automation aya na skala dinamis tina parabot automation infrastruktur. Skenario panyebaran anu paling umum dina OpenShift, Kubernates, Rancher.
Ieu ngalengkepan bagian kahiji - hiji teoritis. Dina runtuyan artikel di handap ieu, conto integrasi jeung sagala rupa panyadia idéntifikasi jeung conto setelan bakal dibahas.
sumber: www.habr.com