Ano ang Keycloak at paano ito i-install nang paunti-unti

Sa halos anumang modernong app na ginagamit mo araw-araw (email, social media, corporate intranets, customer dashboards, atbp.) sa likod ng mga eksena, mayroong isang sistema na nagpapasya kung sino ka at kung ano ang maaari mong i-access. Kapag nagsimulang mag-ipon ang mga kumpanya ng mga application, serbisyo, at API, ang manu-manong pamamahala ng mga user, password, pahintulot, at session ay nagiging isang tunay na sakit ng ulo.

Lumitaw ang Keycloak sa tamang oras para malutas ang gusot na iyonAng Keycloak ay isang plataporma sa pamamahala ng pagkakakilanlan at pag-access na nagsasaayos ng pagpapatotoo, awtorisasyon, at single sign-on para sa maraming aplikasyon. Sa halip na ang bawat aplikasyon ay magpatupad ng sarili nitong sistema ng pag-login, tungkulin, at pagbawi ng password, ang Keycloak ang humahawak sa lahat ng iyon, at ang mga aplikasyon ay nagtitiwala lamang dito gamit ang mga pamantayan tulad ng OAuth 2.0, OpenID Connect, o SAML 2.0.

Ano ang Keycloak at ano ang papel nito sa seguridad ng IAM?

Ang Keycloak ay isang open source na IdP (Identity Provider)Nakasulat sa Java at pinapanatili ng Red Hat (dating JBoss), ito ay lisensyado sa ilalim ng Apache 2.0, kaya malaya itong magagamit at iakma kahit sa mga komersyal na kapaligiran. Mayroon ding bayad na bersyon sa antas ng enterprise na tinatawag na Red Hat Single Sign-On, ngunit pareho pa rin ang pangunahing functionality nito.

Ang identity server na ito ay nagbibigay ng SSO, federation, at multi-tenancyPinapayagan nito ang isang user na mag-log in nang isang beses at mag-access ng maraming application, kung saan ang mga application na iyon ay nagtatalaga ng authentication sa Keycloak, at ang pamamahala ng mga user, grupo, attribute, at mga pahintulot ay ginagawa nang sentralisado, nang hindi muling ipinapatupad ang wheel sa bawat proyekto.

Namumukod-tangi ang Keycloak kumpara sa ibang mga solusyon sa IAM (libre, open source, o proprietary) batay sa kanilang maturity, pag-aampon, at pagiging tugma sa mga karaniwang protocol. Gayunpaman, ang tamang solusyon para sa bawat organisasyon ay depende sa mga pangangailangan nito (komersyal na suporta, SLA, mga partikular na functionality, on-premises kumpara sa SaaS deployment, atbp.).

Isa sa mga kalakasan ng Keycloak Pinagsasama nito ang ilang bahagi: OAuth 2.0 at OpenID Connect based authentication, suporta sa SAML 2.0, social login (Google, Facebook, GitHub, atbp.), integrasyon sa LDAP at Active Directory, administrasyon sa pamamagitan ng web console, CLI at REST API, pati na rin ang isang nababaluktot na modelo ng mga user, grupo at mga tungkulin na makikita sa mga token na inisyu para sa mga aplikasyon.

Mga kinakailangang pundasyon: OAuth 2.0, OpenID Connect at JWT

Para lubos na maunawaan ang ginagawa ng Keycloak, makakatulong na malinawan ang tatlong konsepto.OAuth 2.0, OpenID Connect (OIDC), at JSON Web Tokens (JWT). Hindi mo kailangang maging eksperto, ngunit kailangan mong maunawaan ang pangkalahatang konsepto, dahil ang lahat ay umiikot sa kanila.

OAuth 2.0 bilang isang balangkas ng awtorisasyon

Ang OAuth 2.0 ay isang karaniwang balangkas ng awtorisasyon ng APIGinagamit ng mga higanteng kumpanya tulad ng Google, Facebook, Microsoft, GitHub, at LinkedIn, ang pangunahing tungkulin nito ay payagan ang isang application (kliyente) na ma-access ang mga mapagkukunan ng isang user sa ibang application o API, nang may tahasang pahintulot ng user, nang hindi palaging nagbabahagi ng mga kredensyal.

Sa halip na magpadala ng username at password sa bawat kahilinganIpinakikilala ng OAuth 2.0 ang konsepto ng access token: isang panandaliang access token na ipinapadala sa mga HTTP call papunta sa API at pinapatunayan ng API. Ang IdP (halimbawa, Keycloak) ay naglalabas ng token na ito pagkatapos mapatunayan ang pagkakakilanlan at pahintulot ng user.

Tinutukoy ng pamantayan ang ilang daloy ng awtorisasyon (mga uri ng grant) upang iakma ang proseso sa uri ng kliyente: mga secure na backend application, mga browser-based na SPA, app mga mobile device, limitadong device, komunikasyon sa pagitan ng makina, atbp. Ang bawat daloy ay nagmamarka kung ano ang ipinagpapalit sa bawat hakbang (mga authorization code, token, kredensyal, atbp.).

Ang apat na pangunahing tungkulin ng OAuth 2.0 tunog:

• May-ari ng Resource: kadalasan ang gumagamit na ang datos ay gusto mong konsultahin o baguhin.
• Kliente: ang aplikasyon (web, mobile, IoT, backend…) na gustong kumilos para sa gumagamit.
• server ng mapagkukunan: ang API na naglalantad ng datos at nagva-validate ng mga access token.
• Server ng Awtorisasyon: ang IdP (Keycloak) na nag-aauthenticate sa user at nag-iisyu ng mga token.

Bukod pa rito, ipinakikilala ng OAuth 2.0 ang konsepto ng mga saklawTinutukoy nito ang saklaw ng pahintulot na ibinibigay ng user sa application: pagbabasa ng email, pag-post sa social network, pag-access sa isang pangunahing profile, atbp. Ang ibinigay na token ay nagko-code kung aling mga pahintulot ang talagang ipinagkaloob sa client.

OpenID Connect: isang identity layer sa ibabaw ng OAuth 2.0

Nagdagdag ang OpenID Connect (OIDC) ng pagkakakilanlan sa OAuth 2.0Bagama't ang OAuth ay tumatalakay sa awtorisasyon (kung ano ang kayang gawin ng isang aplikasyon), ang OIDC naman ay tumatalakay sa pagtukoy sa isang pamantayang paraan kung sino ang na-authenticate na user at kung paano makuha ang kanilang pangunahing datos.

Tinutukoy ng OIDC ang mga kilalang endpoint at metadata, tulad ng dokumento ng pagtuklas na inilathala sa ruta /.well-known/openid-configuration kung saan tinutukoy ng provider ang mga authorization URL, token, public key, impormasyon ng user, atbp. Pinapayagan nito ang mga application na halos awtomatikong ma-configure.

Nagbibigay din ito ng UserInfo endpoint.Ginagamit ito upang kumuha ng impormasyon mula sa na-authenticate na user (pangalan, email, atbp.) gamit ang isang valid na access token. Karaniwan sa mga integrasyong nakabatay sa Keycloak na basahin ang data na ito pagkatapos mag-login upang punan ang mga profile ng user sa application.

Access_token at JSON Web Tokens (JWT)

Sa maraming modernong implementasyon, ang access_token ay isang JWT (JSON Web Token). Ito ay isang pamantayan (RFC 7519) para sa pagkatawan ng mga claim bilang isang digitally signed JSON, sa tatlong bahagi na pinaghihiwalay ng mga tuldok: header, payload, at signature, na lahat ay naka-encode sa Base64URL.

Ang header ay nagpapahiwatig ng teknikal na impormasyon tungkol sa token. (algoritmo ng lagda, uri ng token, at kadalasan ang pagkakakilanlan ng susi na ginamit, kidAng kargamento ay naglalaman ng mga paghahabol, tulad ng:

• exp: petsa ng pag-expire.
• iat: oras ng pagsasahimpapawid.
• iss: taga-isyu, karaniwang ang IdP URL.
• sub: natatanging pantukoy ng gumagamit.
• aud: madla kung saan nakadirekta ang token.
• jti: natatanging pantukoy ng token.

Ang lagda ay nabubuo gamit ang isang pribado o lihim na susi.Samakatuwid, ang anumang pagbabago sa token ay sumisira sa lagda at nade-detect habang nagpapatunay. Kinukuha ng API ang public key mula sa IdP salamat sa property na ito. jwks_uri mula sa dokumento ng pagtuklas, na tumuturo sa isang JSON file na naglalaman ng listahan ng mga pampublikong susi at ang kanilang mga kid.

Pinapayagan din ng Keycloak ang pagpapasadya ng mga inisyu na tokenMaaaring magdagdag ng mga karagdagang claim batay sa mga katangian ng user, grupo, tungkulin, o kahit na mga nakapirming halaga. Ginagawa ito gamit ang mga mapper na naka-configure bawat kliyente o bawat saklaw ng kliyente, na ginagawang madali para sa mga API na matanggap ang eksaktong impormasyong kailangan nila.

Arkitektura ng Keycloak: Mga Realm, Gumagamit, Grupo, at Tungkulin

Inaayos ng Keycloak ang configuration nito sa RealmsAng mga ito ay parang mga "virtual identity server" sa loob ng iisang instalasyon. Tinatawag ng ibang mga vendor ang katulad nito bilang tenant o directory. Ang bawat realm ay may kanya-kanyang independiyenteng mga user, grupo, kliyente, patakaran, at setting.

Bilang default, mayroong isang espesyal na realm na tinatawag na master.Dapat nakalaan ang account na ito para sa mga pandaigdigang gawaing administratibo, tulad ng paglikha at pamamahala ng iba pang mga realm. Maaaring pamahalaan ng administrator user ang maraming realm mula sa iisang console nang hindi kinakailangang mag-log in gamit ang iba't ibang account para sa bawat isa.

Maaaring tukuyin ang mga lokal na gumagamit sa loob ng isang saklawpagtatalaga sa kanila ng mga pasadyang katangian, pagpapangkat-pangkat sa mga ito, at pag-uugnay sa mga ito sa mga tungkulin. Maingat na dinisenyo ang modelo upang ang mga kaugnay na impormasyon ay tuluyang maipakita sa mga token na ginagamit ng aplikasyon (mga tungkulin, grupo, datos ng profile, mga flag ng seguridad, atbp.).

Pinapayagan ng mga grupo ang mga gumagamit na maisaayos nang hierarchical.Ang isang grupo ay maaaring magkaroon ng mga subgroup (mga anak), at minana ng isang user ang mga katangian at tungkulin ng lahat ng grupong kinabibilangan nila, kabilang ang kanilang mga magulang. Nagbibigay-daan ito para sa mga napaka-flexible na modelo ng awtorisasyon nang hindi kinakailangang ulitin ang mga configuration para sa bawat user.

Sa usapin ng mga tungkulin, mayroong dalawang pangunahing antas:

• Mga tungkulin sa kaharian: mga global sa loob ng realm, madalas gamitin para sa mga pahintulot sa iba't ibang property.
• Mga tungkulin ng kliyente: partikular sa isang partikular na aplikasyon, na nagbibigay-daan sa pinong detalye para sa bawat serbisyo.

Sinusuportahan ng Keycloak ang mga pinagsamang tungkulinIyon ay, ang mga tungkulin na kinabibilangan naman ng iba pang mga tungkulin. Nakakatulong ito upang pangkatin ang mga pahintulot at italaga ang mga ito nang sabay-sabay sa mga user o grupo, bagama't mas mainam na huwag itong gamitin nang labis upang maiwasan ang pagiging kumplikado ng pamamahala o pag-apekto sa pagganap.

Pag-install ng Keycloak sa development mode: Docker, Kubernetes, at VM

Para mag-set up ng lab environment gamit ang Keycloak Mayroong ilang mga simpleng opsyon: Docker container, deployment sa Kubernetes (halimbawa gamit ang Minikube) o classic installation sa isang virtual machine na may Linux at OpenJDK.

Keycloak sa Docker

Ang pinakamabilis na paraan para simulan ang Keycloak para sa pagsubok Kabilang dito ang pagpapatakbo ng isang lalagyan na may opisyal na imahe, paglalantad ng port 8080 at pagpasa ng username at password ng administrator sa mga environment variable, at pag-boot sa mode start-dev (walang HTTPS at may naka-embed na H2 database):

Gamit ang isang utos ng Docker isang gumaganang server ang nakukuha sa http://localhost:8080, sapat na para baguhin ang administration console, lumikha ng mga realm, user, client at subukan ang mga pangunahing integrasyon.

Keycloak sa Kubernetes gamit ang Minikube

Kung nakikipagtulungan ka na sa Kubernetes, madali mong made-deploy ang Keycloak. Gamit ang mga sample manifest mula sa opisyal na repository, gagawa ka ng Deployment at Service, at pagkatapos ay magbubukas ng tunnel gamit ang Minikube para ma-access ang serbisyo mula sa iyong makina, kadalasan ay sa port 8080 muli.

Ang pamamaraang ito ay mainam para sa paggaya ng mga kapaligirang mas malapit sa produksyon. (kasama ang mga pod, serbisyo, panlabas na configuration, atbp.) at para mag-eksperimento sa mga kontroladong deployment, scaling, at upgrade ng Keycloak sa mga K8s cluster.

Keycloak sa Ubuntu gamit ang OpenJDK at PostgreSQL (advanced dev mode)

Ang isa pang posibilidad ay ang pag-install ng Keycloak sa isang Ubuntu VM Gumagamit ng OpenJDK at isang lokal na PostgreSQL database, na may self-signed certificate at custom hostname. Bagama't isa pa ring pagsubok na senaryo, papalapit na ito sa isang production topology.

Kasama sa mga karaniwang hakbang ang:

• I-update ang operating system at i-install ang Java (halimbawa, OpenJDK 11 o mas bago).
• I-install ang PostgreSQL (mas mainam kung sa isang hiwalay na server, bagama't sa isang lab ay maaari itong nasa parehong makina).
• Gumawa ng partikular na user at database para sa Keycloak at ibigay ang mga naaangkop na pribilehiyo.
• Gumawa ng user ng system nang walang mga pribilehiyo (hal. keycloak) upang patakbuhin ang serbisyo.
• I-download ang opisyal na distribusyon ng Keycloak, i-unzip ito sa /opt/keycloak at isaayos ang mga pahintulot.
• Gumawa ng self-signed X.509 certificate gamit ang openssl at itakda ito keycloak.conf kasama ang mga parameter ng koneksyon ng PostgreSQL at ang hostname ninanais.
• Tukuyin ang isang yunit systemd Para simulan ang Keycloak sa development mode sa pagsisimula ng system, itakda ang mga kredensyal ng administrator sa pamamagitan ng mga environment variable.

Kapag gumagana na ang serbisyoKaraniwan itong ina-access sa pamamagitan ng HTTPS sa port 8443 na may naka-configure na hostname. Kung gagamit ng self-signed certificate, kakailanganin itong pagkatiwalaan sa browser (sa pamamagitan ng pag-import ng CA o ng certificate mismo sa trusted certificate store ng makina).

Mga advanced na deployment: mataas na availability, PostgreSQL at reverse proxy

Kapag lumipat tayo mula sa laboratoryo patungo sa produksyonNagbabago ang sitwasyon: kailangan mong isipin ang mataas na availability, matatag na data persistence, mga valid na certificate at, kadalasan, isang reverse proxy na nagsesentralisa sa HTTPS access at load balancing.

Isang karaniwang pattern ang pag-deploy ng maraming Keycloak node sa likod ng isang load balancer (hal., Nginx) at paggamit ng PostgreSQL database sa HA mode bilang persistence backend. Ang layunin ay alisin ang mga nag-iisang punto ng pagkabigo para sa parehong application at data layer.

Sa ganitong uri ng arkitektura, ang mga sumusunod na hakbang ay karaniwang sinusunod::

• Ihanda ang mga na-update na Linux server (Debian/Ubuntu) at i-install ang mga dependency: unzip, wget, openjdk, openssl, Atbp
• Gumawa ng gumagamit ng sistema keycloak may bahay sa /opt/keycloak at walang pribilehiyong interactive na mga pahintulot sa pag-login.
• I-download ang nais na bersyon ng Keycloak, i-unzip ito, at italaga ang pagmamay-ari sa nakalaang user.
• Gumawa ng isang partikular na database sa PostgreSQL, kasama ang naaangkop na user at mga pribilehiyo, inaayos din ang may-ari ng schema at mga default na pahintulot sa mga talahanayan.
• Bumuo ng mga self-signed certificate (o gumamit ng mga certificate mula sa isang internal CA) para sa mga Keycloak node at i-configure ang HTTPS sa application server.
• Ayusin keycloak.conf para kumonekta sa PostgreSQL VIP, tukuyin ang mga HTTP/HTTPS port, certificate, proxy parameter, hostname, cluster stack (hal., UDP), at mga log level.
• Tukuyin ang isang serbisyo systemd simple yan boot Keycloak na may kc.sh start o kc.sh start --optimizedpamamahala ng mga awtomatikong pag-restart kung sakaling magkaroon ng mga pagkabigo.

Karaniwang naka-deploy ang Nginx sa ibabaw ng publishing at load balancing layer. bilang isang HTTPS reverse proxy, na may sarili nitong TLS certificate at isang upstream configuration na nakaturo sa mga Keycloak node sa mga backend port nito (karaniwan ay 8080 kung ang TLS ay tinapos sa Nginx).

Upang maalis ang mga nag-iisang punto ng pagkabigo sa balancerKaraniwang i-configure ang dalawang Nginx node sa high availability gamit ang Keepalived. Pinamamahalaan ng tool na ito ang isang floating virtual IP (VIP) na ina-advertise sa isa sa mga server bilang master at, kung sakaling magkaroon ng pagkabigo, lumilipat sa backup node, pinapanatili ang service continuity.

Pag-set up ng Realm, mga user, at pagpaparehistro ng application (client)

Kapag na-activate na natin ang Keycloak, ang susunod na lohikal na hakbang ay Kabilang dito ang paglikha ng isang realm para sa ating mga user at application, at mula roon ay pagtukoy sa mga user, grupo, tungkulin, at client (ang mga application na magdedelegate ng authentication sa Keycloak).

Isang bagong realm ang nalikha mula sa Admin Console. Sa pamamagitan lamang ng paglalagay ng pangalan nito. Mula sa sandaling iyon, magkakaroon tayo ng isang nakahiwalay na espasyo na may sarili nitong mga setting. Kabilang sa mga unang pagsasaayos, ang mga sumusunod ay karaniwang kapaki-pakinabang:

• I-configure ang SMTP para sa pagpapadala ng mga email (pag-verify ng email, pagbawi ng password, mga notification).
• Paganahin kung ninanais Deklaratibong Profile ng Gumagamit, na nagbibigay-daan sa iyong deklaratibong tukuyin kung anong mga katangian ang magkakaroon ng isang user, kung anong mga pagpapatunay ang nalalapat, at kung ang mga ito ay maaaring i-edit ng user.
• Ayusin ang mga parameter ng pag-login: payagan o hindi payagan ang self-registration, tandaan ang session sa pagitan ng mga pag-restart ng browser, payagan ang pagbawi ng password, atbp.

Ang paggawa ng user sa isang realm ay kasing simple ng pagpuno ng isang form Kakailanganin mo ng username, email address, pangalan at apelyido. Pagkatapos, itatakda mo ang iyong password (pansamantala o permanente) mula sa tab na credentials. Mula doon, maaari kang magtalaga ng mga grupo, tungkulin, at karagdagang mga katangian.

Nag-aalok ang Keycloak ng nakalaang Account Console para sa mga end user.kung saan maaari nilang tingnan at baguhin ang datos ng kanilang profile, palitan ang kanilang password, suriin ang mga aktibong sesyon, o pamahalaan ang mga karagdagang salik sa pagpapatotoo. Ito ay isang napaka-maginhawang paraan upang italaga ang ilan sa mga pangunahing pangangasiwa ng kanilang account sa gumagamit.

Ang panggagaya ay isa pang kawili-wiling katangian.Ang isang administrator na may pahintulot ay maaaring "magpanggap" ng isang user mula sa console upang kopyahin ang mga problema, i-verify ang mga pahintulot, atbp., nang hindi nangangailangan ng password ng user.

Para magamit ng isang application ang Keycloak bilang isang IdPDapat itong nakarehistro bilang isang kliyente. Sa seksyong Mga Kliyente, isang bagong client ID ang gagawin, ang uri ay ipapakita bilang OpenID Connect (maliban kung gagamitin ang SAML), at ang mga pinapayagang daloy ng OAuth 2.0 ay pipiliin: Standard Flow (Authorization Code), Direct Access Grants (Password), Implicit, Client Credentials (mga service account), Device Code, CIBA, atbp.

Ang configuration ng kliyente ang nagpapasya rin Kung kinakailangan ang pagpapatotoo ng kliyente (lihim ng kliyente o mga sertipiko), aling mga redirect URI ang balido at aling mga web origin ang pinapayagan (napakahalaga sa mga SPA dahil sa mga patakaran ng CORS). Mula roon, maaaring gumamit ang application ng mga opisyal o third-party na library upang magtalaga ng pagpapatotoo sa Keycloak sa pamamagitan ng OIDC.

Pagsasama sa mga panlabas na direktoryo at iba pang mga tagapagbigay ng pagkakakilanlan

Ang Keycloak ay maaaring gumana bilang isang lokal na mapagkukunan ng pagkakakilanlan (mga user, grupo, at mga tungkuling tinukoy sa loob ng sarili nitong database) o maaari itong kumilos bilang isang identity broker sa isa o higit pang mga panlabas na provider.

Isang napakakaraniwang integrasyon ay sa Azure Active DirectoryIniimbak ng Azure AD ang mga corporate user at grupo, at kumokonekta ang Keycloak bilang isang OIDC client para mag-download ng mga pagkakakilanlan at grupo, na mina-map ang mga ito sa mga lokal na user at tungkulin. Naiiwasan nito ang pagdoble ng mga pagkakakilanlan at mga gawaing administratibo sa maraming site.

Sa pangkalahatang termino, ang paggamit ng Azure AD bilang isang panlabas na IdP tapos na ang sumusunod:

• Magrehistro ng isang aplikasyon sa Azure AD, kunin ang client ID nito at lumikha ng isang client secret.
• I-configure sa Azure AD ang mga redirect URI papunta sa Keycloak (OIDC broker endpoint sa kaukulang realm).
• Ayusin ang mga claim na ibibigay sa token sa Azure AD application, halimbawa sa pamamagitan ng pagsasama ng mga user group.
• Sa Keycloak, gumawa ng OpenID Connect Identity Provider na nakaturo sa mga Azure endpoint (authorization, token, logout, userinfo) at i-configure ang client ID, client secret, at ang mga nais na login parameter.

Kapag naitatag na ang tiwala sa pagitan nilaKapag nag-sign in ang isang user sa pamamagitan ng Azure AD, nililikha (o sini-synchronize) ng Keycloak ang user nang lokal at maaaring imapa ang mga grupo ng Azure sa mga tungkulin ng Keycloak gamit ang mga advanced mapper. Halimbawa, ang grupong "Mga Developer" sa Azure ay maaaring isalin sa tungkulin ng "Mga Developer" sa Keycloak, na pagkatapos ay inilulunsad sa mga integrated application at serbisyo (tulad ng Jenkins).

Bukod sa Azure AD, pinapayagan ng Keycloak ang identity federation na may LDAP, classic Active Directory, iba pang OIDC IdPs, mga social provider (Google, Facebook, GitHub, atbp.) at marami pang iba, na kayang paghaluin ang ilang source nang sabay-sabay sa loob ng iisang larangan.

Karagdagang seguridad: mga bot, CAPTCHA, at mga pinakamahusay na kasanayan

Bagama't lubos na pinapalakas ng Keycloak ang seguridad ng pagpapatotoo (MFA, mga patakaran sa password, account lockout, session control, atbp.), ang mga pahina sa pag-login, pagpaparehistro, at pagbawi ng password ay nananatiling malinaw na target para sa mga bot at awtomatikong pag-atake.

Upang mabawasan ang mga ganitong uri ng bantaInirerekomenda na pagsamahin ang Keycloak sa mga mekanismong anti-bot tulad ng mga solusyon sa CAPTCHA na sumusunod sa GDPR na nagpapaiba sa trapiko ng tao at awtomatikong trapiko nang hindi nakompromiso ang karanasan ng gumagamit. Ang mga solusyong ito ay karaniwang isinasama sa mga form sa pag-login at pagpaparehistro, na nagdaragdag ng karagdagang patong ng depensa laban sa mga pag-atake ng credential stuffing, paggawa ng malawakang account, o pang-aabuso sa mga daloy ng pagbawi ng password.

Bukod sa CAPTCHA, kabilang sa iba pang mabubuting kasanayan ang monitor mga tala para sa pag-access, mag-set up ng mga alerto para sa mga hindi pangkaraniwang pagtaas sa mga nabigong pagtatangka, pana-panahong suriin ang mga inisyu na token at ang kanilang tagal, tiyaking tanging ang mga kinakailangang endpoint lamang ang nakalantad sa labas, at panatilihing updated ang Keycloak at ang mga dependency nito gamit ang mga pinakabagong security patch.

Ang buong ekosistema ng mga paggana na ito (SSO, multi-tenancy, integrasyon sa mga panlabas na direktoryo, mga nako-configure na token, mga high availability deployment at proteksyon ng bot) ay ginagawang isang napakalakas na tool ang Keycloak para sa pag-sentralisa ng authentication at awtorisasyon para sa mga modernong aplikasyon, na tumutulong sa mga kumpanya na palakasin ang kanilang seguridad nang hindi isinasakripisyo ang karanasan ng gumagamit o patuloy na binabago ang pamamahala ng pagkakakilanlan.