Sa anumang malaking kumpanya, at ang X5 Retail Group ay walang pagbubukod, habang umuunlad ito, ang bilang ng mga proyekto na nangangailangan ng pahintulot ng user ay tumataas. Sa paglipas ng panahon, kinakailangan ang tuluy-tuloy na paglipat ng mga user mula sa isang application patungo sa isa pa, at pagkatapos ay kailangan na gumamit ng solong Single-Sing-On (SSO) server. Ngunit paano kapag ang mga tagapagbigay ng pagkakakilanlan tulad ng AD o iba pa na walang karagdagang mga katangian ay ginagamit na sa iba't ibang mga proyekto. Isang klase ng mga system na tinatawag na "mga broker ng pagkakakilanlan" ay darating upang iligtas. Ang pinaka-functional ay ang mga kinatawan nito, tulad ng Keycloak, Gravitee Access management, atbp. Kadalasan, ang mga kaso ng paggamit ay maaaring magkakaiba: pakikipag-ugnayan ng makina, pakikilahok ng user, atbp. Dapat na sinusuportahan ng solusyon ang flexible at scalable na functionality na maaaring pagsamahin ang lahat ng kinakailangan sa isa, at ang mga ganitong solusyon ang aming kumpanya ay mayroon na ngayong indication broker - Keycloak.
Ang Keycloak ay isang open source identity at access control na produkto na pinananatili ng RedHat. Ito ang batayan para sa mga produkto ng kumpanya gamit ang SSO - RH-SSO.
Mga pangunahing konsepto
Bago ka magsimulang makitungo sa mga solusyon at diskarte, dapat kang magpasya sa mga tuntunin at pagkakasunud-sunod ng mga proseso:
Pagkakakilanlan ay isang pamamaraan para sa pagkilala sa isang paksa sa pamamagitan ng kanyang identifier (sa madaling salita, ito ang kahulugan ng isang pangalan, login o numero).
Pagpapatunay - ito ay isang pamamaraan ng pagpapatunay (ang user ay sinuri gamit ang isang password, ang liham ay sinuri gamit ang isang electronic na lagda, atbp.)
Awtorisasyon - ito ay ang pagkakaloob ng access sa isang mapagkukunan (halimbawa, sa e-mail).
Keycloak ng Identity Broker
keycloak ay isang open source na pagkakakilanlan at solusyon sa pamamahala ng pag-access na idinisenyo para gamitin sa IS kung saan maaaring gamitin ang mga pattern ng arkitektura ng microservice.
Nag-aalok ang Keycloak ng mga feature gaya ng single sign-on (SSO), brokered identity at social login, user federation, client adapters, admin console at account management console.
Pangunahing pag-andar na sinusuportahan ng Keycloak:
- Single-Sign On at Single-Sign Out para sa mga application ng browser.
- Suporta para sa OpenID/OAuth 2.0/SAML.
- Identity Brokering - pagpapatunay gamit ang panlabas na OpenID Connect o mga tagapagbigay ng pagkakakilanlan ng SAML.
- Social Login - Suporta ng Google, GitHub, Facebook, Twitter para sa pagkakakilanlan ng user.
- User Federation - pag-synchronize ng mga user mula sa LDAP at Active Directory server at iba pang identity provider.
- Kerberos bridge - gamit ang isang Kerberos server para sa awtomatikong pagpapatunay ng user.
- Admin Console - para sa pinag-isang pamamahala ng mga setting at mga opsyon sa solusyon sa pamamagitan ng Web.
- Account Management Console - para sa sariling pamamahala ng profile ng user.
- Pag-customize ng solusyon batay sa pagkakakilanlan ng kumpanya ng kumpanya.
- 2FA Authentication - suporta sa TOTP/HOTP gamit ang Google Authenticator o FreeOTP.
- Mga Daloy ng Pag-login - self-registration ng user, pagbawi at pag-reset ng password, at iba pa ay posible.
- Pamamahala ng Session - maaaring pamahalaan ng mga administrator ang mga session ng user mula sa isang punto.
- Mga Token Mapper - nagbubuklod sa mga katangian ng user, tungkulin at iba pang kinakailangang katangian sa mga token.
- Flexible na pamamahala ng patakaran sa buong larangan, application at mga user.
- Suporta sa CORS - Ang mga adaptor ng kliyente ay may built-in na suporta sa CORS.
- Mga Service Provider Interface (SPI) - Isang malaking bilang ng mga SPI na nagbibigay-daan sa iyong i-customize ang iba't ibang aspeto ng server: mga daloy ng pagpapatotoo, mga tagapagbigay ng pagkakakilanlan, pagmamapa ng protocol, at higit pa.
- Mga adaptor ng kliyente para sa mga application ng JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Suporta para sa pagtatrabaho sa iba't ibang mga application na sumusuporta sa OpenID Connect Relying Party library o SAML 2.0 Service Provider Library.
- Napapalawak gamit ang mga plugin.
Para sa mga proseso ng CI / CD, pati na rin ang automation ng mga proseso ng pamamahala sa Keycloak, maaaring gamitin ang REST API / JAVA API. Ang dokumentasyon ay magagamit sa elektronikong paraan:
REST API
Java API
Enterprise Identity Provider (Nasa Nasasakupan)
Kakayahang i-authenticate ang mga user sa pamamagitan ng mga serbisyo ng User Federation.
Magagamit din ang pass-through na pagpapatotoo - kung magpapatotoo ang mga user laban sa mga workstation na may Kerberos (LDAP o AD), maaari silang awtomatikong ma-authenticate sa Keycloak nang hindi na kailangang ipasok muli ang kanilang username at password.
Para sa pagpapatunay at karagdagang awtorisasyon ng mga user, posibleng gumamit ng relational na DBMS, na pinaka-angkop para sa mga development environment, dahil hindi ito nagsasangkot ng mahahabang setting at integration sa mga unang yugto ng mga proyekto. Bilang default, gumagamit ang Keycloak ng built-in na DBMS upang mag-imbak ng mga setting at data ng user.
Ang listahan ng mga sinusuportahang DBMS ay malawak at kasama ang: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle at iba pa. Ang pinakasubok sa ngayon ay ang Oracle 12C Release1 RAC at Galera 3.12 cluster para sa MariaDB 10.1.19.
Mga tagapagbigay ng pagkakakilanlan - social login
Posibleng gumamit ng pag-login mula sa mga social network. Upang i-activate ang kakayahang patotohanan ang mga user, gamitin ang Keycloack admin console. Ang mga pagbabago sa code ng aplikasyon ay hindi kinakailangan at ang pagpapaandar na ito ay magagamit sa labas ng kahon at maaaring i-activate sa anumang yugto ng proyekto.
Posibleng gumamit ng mga provider ng OpenID/SAML Identity para sa pagpapatunay ng user.
Mga karaniwang senaryo ng awtorisasyon gamit ang OAuth2 sa Keycloak
Daloy ng Authorization Code - ginagamit sa mga application sa gilid ng server. Isa sa mga pinaka-karaniwang uri ng pahintulot sa awtorisasyon dahil angkop ito para sa mga application ng server kung saan hindi available sa mga tagalabas ang source code ng application at data ng kliyente. Ang proseso sa kasong ito ay batay sa pag-redirect. Ang application ay dapat na makipag-ugnayan sa isang user agent (user-agent), tulad ng isang web browser - upang makatanggap ng mga API authorization code na na-redirect sa pamamagitan ng user agent.
implicit na daloy - ginagamit ng mga mobile o web application (mga application na tumatakbo sa device ng user).
Ang implicit na uri ng pahintulot sa pagpapahintulot ay ginagamit ng mga mobile at web application kung saan hindi matitiyak ang pagiging kumpidensyal ng kliyente. Ang implicit na uri ng pahintulot ay gumagamit din ng user agent redirection, kung saan ang access token ay ipinapasa sa user agent para sa karagdagang paggamit sa application. Ginagawa nitong available ang token sa user at iba pang mga application sa device ng user. Ang ganitong uri ng pahintulot ng awtorisasyon ay hindi nagpapatotoo sa pagkakakilanlan ng aplikasyon, at ang proseso mismo ay umaasa sa isang redirect URL (na dating nakarehistro sa serbisyo).
Hindi sinusuportahan ng Implicit Flow ang mga token ng pag-refresh ng token ng access.
Daloy ng Pagbibigay ng Mga Kredensyal ng Kliyente β ay ginagamit kapag na-access ng application ang API. Ang ganitong uri ng pahintulot sa pagpapahintulot ay karaniwang ginagamit para sa mga pakikipag-ugnayan ng server-to-server na dapat gawin sa background nang walang agarang pakikipag-ugnayan ng user. Ang daloy ng pagbibigay ng kredensyal ng kliyente ay nagbibigay-daan sa isang serbisyo sa web (kumpidensyal na kliyente) na gumamit ng sarili nitong mga kredensyal sa halip na magpanggap bilang isang user upang patotohanan kapag tumatawag sa isa pang serbisyo sa web. Para sa mas mataas na antas ng seguridad, posible para sa serbisyo sa pagtawag na gumamit ng isang sertipiko (sa halip na isang nakabahaging lihim) bilang isang kredensyal.
Ang detalye ng OAuth2 ay inilarawan sa
JWT token at ang mga benepisyo nito
Ang JWT (JSON Web Token) ay isang bukas na pamantayan () na tumutukoy sa isang compact at self-contained na paraan upang ligtas na maglipat ng impormasyon sa pagitan ng mga partido bilang JSON object.
Ayon sa pamantayan, ang token ay binubuo ng tatlong bahagi sa base-64 na format, na pinaghihiwalay ng mga tuldok. Ang unang bahagi ay tinatawag na header, na naglalaman ng uri ng token at ang pangalan ng hash algorithm para sa pagkuha ng digital signature. Ang ikalawang bahagi ay nag-iimbak ng pangunahing impormasyon (user, mga katangian, atbp.). Ang ikatlong bahagi ay ang digital signature.
. .
Huwag kailanman mag-imbak ng token sa iyong DB. Dahil ang isang wastong token ay katumbas ng isang password, ang pag-iimbak ng token ay tulad ng pag-iimbak ng password sa malinaw na teksto.
Access token ay isang token na nagbibigay ng access sa may-ari nito upang ma-secure ang mga mapagkukunan ng server. Karaniwan itong may maikling buhay at maaaring magdala ng karagdagang impormasyon tulad ng IP address ng partido na humihiling ng token.
I-refresh ang token ay isang token na nagbibigay-daan sa mga kliyente na humiling ng mga bagong access token pagkatapos mag-expire ang kanilang buhay. Ang mga token na ito ay karaniwang ibinibigay sa loob ng mahabang panahon.
Ang pangunahing bentahe ng paggamit sa microservice architecture:
- Kakayahang ma-access ang iba't ibang mga application at serbisyo sa pamamagitan ng isang beses na pagpapatunay.
- Sa kawalan ng ilang kinakailangang katangian sa profile ng user, posibleng pagyamanin ang data na maaaring idagdag sa payload, kabilang ang awtomatiko at on-the-fly.
- Hindi na kailangang mag-imbak ng impormasyon tungkol sa mga aktibong session, kailangan lang i-verify ng application ng server ang lagda.
- Mas nababaluktot na kontrol sa pag-access sa pamamagitan ng mga karagdagang katangian sa payload.
- Ang paggamit ng signature ng token para sa header at payload ay nagpapataas ng seguridad ng solusyon sa kabuuan.
JWT token - komposisyon
Pamagat - bilang default, ang header ay naglalaman lamang ng uri ng token at ang algorithm na ginagamit para sa pag-encrypt.
Ang uri ng token ay naka-imbak sa "typ" key. Ang 'uri' na key ay hindi pinapansin sa JWT. Kung ang "typ" key ay naroroon, ang halaga nito ay dapat na JWT upang ipahiwatig na ang bagay na ito ay isang JSON Web Token.
Ang pangalawang key na "alg" ay tumutukoy sa algorithm na ginamit upang i-encrypt ang token. Dapat itong itakda sa HS256 bilang default. Ang header ay naka-encode sa base64.
{ "alg": "HS256", "type": "JWT"}
payload (nilalaman) - iniimbak ng payload ang anumang impormasyon na kailangang suriin. Ang bawat susi sa payload ay kilala bilang isang "claim". Halimbawa, maaari mong ipasok ang aplikasyon sa pamamagitan lamang ng imbitasyon (sarado na promo). Kapag gusto naming mag-imbita ng isang tao na lumahok, nagpapadala kami sa kanila ng liham ng imbitasyon. Mahalagang suriin kung ang email address ay pag-aari ng taong tumatanggap ng imbitasyon, kaya isasama namin ang address na ito sa payload, para dito ay iniimbak namin ito sa "email" na key
{ "email": "[protektado ng email]"}
Ang mga susi sa payload ay maaaring maging arbitrary. Gayunpaman, may ilang nakalaan:
- iss (Issuer) - Tinutukoy ang aplikasyon kung saan ipinapadala ang token.
- sub (Subject) - tumutukoy sa paksa ng token.
- Ang aud (Audience) ay isang hanay ng mga case-sensitive na string o URI na isang listahan ng mga tatanggap ng token na ito. Kapag ang receiving side ay nakatanggap ng JWT na may ibinigay na susi, dapat nitong suriin ang presensya ng sarili nito sa mga tatanggap - kung hindi, huwag pansinin ang token.
- exp (Expiration Time) - Nagsasaad kung kailan mag-e-expire ang token. Ang pamantayan ng JWT ay nangangailangan ng lahat ng pagpapatupad na tanggihan ang mga nag-expire na token. Ang exp key ay dapat na isang timestamp sa unix na format.
- Ang nbf (Not Before) ay isang oras sa unix na format na tumutukoy sa sandali kung kailan naging wasto ang token.
- iat (Inilabas Sa) - Kinakatawan ng key na ito ang oras na ibinigay ang token at maaaring gamitin upang matukoy ang edad ng JWT. Ang iat key ay dapat na isang timestamp sa unix na format.
- Jti (JWT ID) β isang string na tumutukoy sa natatanging identifier ng token na ito, case-sensitive.
Mahalagang maunawaan na ang payload ay hindi ipinadala sa naka-encrypt na anyo (bagaman ang mga token ay maaaring ma-nest at pagkatapos ay posible na magpadala ng naka-encrypt na data). Samakatuwid, hindi ito maaaring mag-imbak ng anumang lihim na impormasyon. Tulad ng header, ang payload ay base64 na naka-encode.
Lagda - kapag may title at payload tayo, pwede nating kalkulahin ang signature.
Base64-encoded: kinukuha ang header at payload, pinagsama sila sa isang string sa pamamagitan ng isang tuldok. Pagkatapos ang string na ito at ang lihim na key ay input sa encryption algorithm na tinukoy sa header ("alg" key). Ang susi ay maaaring maging anumang string. Mas pipiliin ang mas mahahabang string dahil mas matagal itong makuha.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Pagbuo ng Keycloak Failover Cluster Architecture
Kapag gumagamit ng isang kumpol para sa lahat ng proyekto, may mga tumaas na kinakailangan para sa isang solusyon sa SSO. Kapag ang bilang ng mga proyekto ay maliit, ang mga kinakailangang ito ay hindi gaanong kapansin-pansin para sa lahat ng mga proyekto, gayunpaman, sa pagtaas ng bilang ng mga gumagamit at pagsasama, ang mga kinakailangan para sa pagkakaroon at pagtaas ng pagganap.
Ang pagtaas ng panganib ng isang solong pagkabigo ng SSO ay nagpapataas ng mga kinakailangan para sa arkitektura ng solusyon at ang mga pamamaraan na ginagamit para sa mga kalabisan na bahagi, at humahantong sa isang napakahigpit na SLA. Sa pagsasaalang-alang na ito, mas madalas sa pag-unlad o maagang yugto ng pagpapatupad ng mga solusyon, ang mga proyekto ay may sarili nilang imprastraktura na hindi nabigo. Habang umuunlad ang pag-unlad, kinakailangan na maglatag ng mga pagkakataon para sa pag-unlad at pag-scale. Ito ay pinaka-flexible upang bumuo ng isang failover cluster gamit ang container virtualization o isang hybrid na diskarte.
Upang gumana sa Active/Active at Active/Passive cluster mode, kinakailangan upang matiyak ang pagkakapare-pareho ng data sa isang relational database - ang parehong mga database node ay dapat na sabay-sabay na ginagaya sa pagitan ng iba't ibang geo-distributed na data center.
Ang pinakasimpleng halimbawa ng isang fault-tolerant na pag-install.
Ano ang mga pakinabang ng paggamit ng isang kumpol:
- Mataas na kakayahang magamit at pagganap.
- Suporta para sa mga operating mode: Aktibo / Aktibo, Aktibo / Passive.
- Kakayahang dynamic na sukat - kapag gumagamit ng virtualization ng container.
- Posibilidad ng sentralisadong pamamahala at pagsubaybay.
- Pinag-isang diskarte para sa pagkakakilanlan/pagpapatunay/pagpapahintulot ng mga user sa mga proyekto.
- Mas malinaw na pakikipag-ugnayan sa pagitan ng iba't ibang proyekto nang walang paglahok ng user.
- Ang kakayahang muling gamitin ang JWT token sa iba't ibang proyekto.
- Isang punto ng pagtitiwala.
- Mas mabilis na paglulunsad ng mga proyekto gamit ang microservices/container virtualization (hindi na kailangang iangat at i-configure ang mga karagdagang bahagi).
- Posibleng bumili ng komersyal na suporta mula sa vendor.
Ano ang Hahanapin Kapag Nagpaplano ng Cluster
DBMS
Gumagamit ang Keycloak ng isang database management system para mag-imbak ng: realms, clients, users, etc.
Ang isang malawak na hanay ng DBMS ay suportado: MS SQL, Oracle, MySQL, PostgreSQL. Ang Keycloak ay may sarili nitong built-in na relational database. Inirerekomenda na gamitin para sa mga hindi na-load na kapaligiran - tulad ng mga kapaligiran sa pag-unlad.
Upang gumana sa Active/Active at Active/Passive cluster mode, ang data consistency sa isang relational database ay kinakailangan, at ang parehong database cluster node ay sabay-sabay na ginagaya sa pagitan ng mga data center.
Ibinahagi ang cache (Infinspan)
Para gumana nang tama ang cluster, kinakailangan ang karagdagang pag-synchronize ng mga sumusunod na uri ng mga cache gamit ang JBoss Data Grid:
Mga session ng pagpapatotoo - ginagamit upang mag-save ng data kapag nagpapatotoo sa isang partikular na user. Ang mga kahilingan mula sa cache na ito ay karaniwang kasama lamang ang browser at ang Keycloak server, hindi ang application.
Ginagamit ang mga token ng pagkilos para sa mga sitwasyon kung saan kailangang kumpirmahin ng user ang isang aksyon nang asynchronous (sa pamamagitan ng email). Halimbawa, sa panahon ng isang forget password flow, ang actionTokens Infinispan cache ay ginagamit upang subaybayan ang metadata tungkol sa nauugnay na mga token ng pagkilos na nagamit na, kaya hindi na ito magagamit muli.
Caching at invalidation ng persistent data - ginagamit upang i-cache ang persistent data upang maiwasan ang mga hindi kinakailangang query sa database. Kapag na-update ng anumang server ng Keycloak ang data, kailangang malaman ito ng lahat ng iba pang server ng Keycloak sa lahat ng data center.
Trabaho - Ginagamit lamang upang magpadala ng mga di-wastong mensahe sa pagitan ng mga cluster node at data center.
Mga session ng user - ginagamit upang mag-imbak ng data tungkol sa mga session ng user na wasto para sa tagal ng session ng browser ng user. Dapat iproseso ng cache ang mga kahilingan sa HTTP mula sa end user at sa application.
Proteksyon ng brute force - ginagamit upang subaybayan ang data tungkol sa mga nabigong login.
Pagbalanse ng load
Ang load balancer ay ang nag-iisang entry point sa keycloak at dapat na sumusuporta sa mga malagkit na session.
Mga Server ng Application
Ginagamit ang mga ito upang kontrolin ang pakikipag-ugnayan ng mga bahagi sa isa't isa at maaaring i-virtualize o i-container gamit ang mga kasalukuyang tool sa automation at dynamic na pag-scale ng mga tool sa automation ng imprastraktura. Ang pinakakaraniwang mga senaryo sa pag-deploy sa OpenShift, Kubernates, Rancher.
Ito ay nagtatapos sa unang bahagi - ang teoretikal. Sa susunod na serye ng mga artikulo, susuriin ang mga halimbawa ng pagsasama sa iba't ibang tagapagbigay ng pagkakakilanlan at mga halimbawa ng mga setting.
Pinagmulan: www.habr.com