Co je Keycloak a jak ho krok za krokem nainstalovat

Poslední aktualizace: 08/01/2026
Autor: Isaac
  • Keycloak je poskytovatel identit s otevřeným zdrojovým kódem, který centralizuje ověřování, autorizaci a jednotné přihlašování (SSO) pro více aplikací pomocí OAuth 2.0, OpenID Connect a SAML.
  • Jeho model sfér, uživatelů, skupin a rolí umožňuje flexibilní správu identit a oprávnění, včetně federace s externími adresáři, jako je LDAP, Active Directory nebo Azure AD.
  • Lze jej nasadit na Docker, Kubernetes nebo počítače. Linux s PostgreSQL a škálovat ve vysoké dostupnosti za reverzními proxy a vyvažovači zátěže, jako jsou Nginx a Keepalived.
  • Tokeny JWT vydané službou Keycloak lze přizpůsobit pomocí mapovačů, což umožňuje vytvářet jemné bezpečnostní modely, které lze snadno integrovat do moderních API a aplikací.

Správa identity a přístupu Keycloak

V téměř každé moderní aplikaci, kterou používáte denně (e-mail, sociální média, firemní intranet, zákaznické dashboardy atd.) V zákulisí existuje systém, který rozhoduje o tom, kdo jste a k čemu máte přístup. Když firmy začnou hromadit aplikace, služby a API, ruční správa uživatelů, hesel, oprávnění a relací se stává skutečnou bolestí hlavy.

Keycloak se objeví právě včas, aby ten nepořádek vyřešil.Keycloak je platforma pro správu identit a přístupu, která centralizuje ověřování, autorizaci a jednotné přihlašování (SSO) pro více aplikací. Místo toho, aby každá aplikace implementovala svůj vlastní systém pro přihlášení, role a obnovu hesla, Keycloak se o vše postará a aplikace mu jednoduše důvěřují pomocí standardů, jako jsou OAuth 2.0, OpenID Connect nebo SAML 2.0.

Co je Keycloak a jakou roli hraje v zabezpečení IAM?

Keycloak je open source IdP (poskytovatel identity).Je napsán v Javě a spravován společností Red Hat (dříve JBoss). Je licencován pod Apache 2.0, takže jej lze volně používat a upravovat i v komerčním prostředí. Existuje placená verze pro podniky s názvem Red Hat Single Sign-On, ale základní funkce jsou stejné.

Tento server identit poskytuje SSO, federaci a multitenancy.Umožňuje uživateli přihlásit se jednou a přistupovat k více aplikacím, přičemž tyto aplikace delegují ověřování na Keycloak a správa uživatelů, skupin, atributů a oprávnění se provádí centrálně, bez nutnosti znovu implementovat kolečko v každém projektu.

Keycloak vyniká mezi ostatními IAM řešeními (bezplatné, open source nebo proprietární) na základě jejich vyspělosti, přijetí a kompatibility se standardními protokoly. Správné řešení pro každou organizaci však bude záviset na jejích potřebách (komerční podpora, SLA, specifické funkce, nasazení v místním prostředí versus SaaS atd.).

Jedna ze silných stránek Keycloaku Kombinuje několik komponent: ověřování založené na OAuth 2.0 a OpenID Connect, podporu SAML 2.0, přihlašování přes sociální sítě (Google, facebook, GitHub atd.), integrace s LDAP a Active Directory, administrace přes webovou konzoli, CLI a REST API, a také flexibilní model uživatelů, skupin a rolí, které se odrážejí v tokenech vydaných pro aplikace.

Server Keycloak a připojené aplikace

Požadované základy: OAuth 2.0, OpenID Connect a JWT

Abychom plně pochopili, co Keycloak dělá, je užitečné mít jasno ve třech konceptech.OAuth 2.0, OpenID Connect (OIDC) a JSON Web Tokens (JWT). Nemusíte se stát expertem, ale musíte rozumět obecnému konceptu, protože se kolem nich všechno točí.

OAuth 2.0 jako autorizační framework

OAuth 2.0 je standardní framework pro autorizaci API.Používají ho giganti jako Google, Facebook, Microsoft, GitHub a LinkedIn. Jeho hlavní funkcí je umožnit aplikaci (klientovi) přístup k uživatelským zdrojům v jiné aplikaci nebo API s výslovným souhlasem uživatele, aniž by musel neustále sdílet své přihlašovací údaje.

Místo odesílání uživatelského jména a hesla v každém požadavkuOAuth 2.0 zavádí koncept přístupového tokenu: krátkodobý přístupový token, který je odesílán v HTTP voláních do API a tímto API ověřován. IdP (například Keycloak) vydává tento token po ověření identity a souhlasu uživatele.

Standard definuje několik autorizačních toků (typů udělení) přizpůsobit proces typu klienta: zabezpečené backendové aplikace, SPA založené na prohlížeči, aplikace mobilní zařízení, omezená zařízení, komunikace mezi stroji atd. Každý tok označuje, co se v každém kroku vyměňuje (autorizační kódy, tokeny, přihlašovací údaje atd.).

Čtyři základní role OAuth 2.0 Zvuk:

  • Vlastník zdrojeobvykle uživatel, jehož data chcete zobrazit nebo upravit.
  • Klientaplikace (webová, mobilní, IoT, backend…), který chce jednat jménem uživatele.
  • zdrojový server: API, které zpřístupňuje data a ověřuje přístupové tokeny.
  • Autorizační server: IdP (Keycloak), který ověřuje uživatele a vydává tokeny.

OAuth 2.0 navíc zavádí koncept oborů (scopes).Ty definují rozsah oprávnění, která uživatel aplikaci uděluje: čtení e-mailů, zveřejňování příspěvků na sociálních sítích, přístup k základnímu profilu atd. Vydaný token kóduje, která oprávnění byla klientovi skutečně udělena.

OpenID Connect: vrstva identity nad OAuth 2.0

OpenID Connect (OIDC) přidává identitu do OAuth 2.0Zatímco OAuth se zabývá autorizací (co aplikace dokáže), OIDC se zabývá standardizovanou identifikací ověřeného uživatele a způsobem, jak získat jeho základní data.

  9 způsobů, jak skrýt svou IP adresu

OIDC definuje dobře známé koncové body a metadata, například dokument o objevu zveřejněný na trase /.well-known/openid-configuration kde poskytovatel specifikuje autorizační adresy URL, token, veřejné klíče, informace o uživateli atd. To umožňuje téměř automatickou konfiguraci aplikací.

Také poskytuje koncový bod UserInfo.Toto se používá k načtení informací od ověřeného uživatele (jméno, e-mail atd.) pomocí platného přístupového tokenu. V integracích založených na Keycloaku je velmi běžné, že se tato data po přihlášení načtou za účelem naplnění uživatelských profilů v aplikaci.

Access_token a webové tokeny JSON (JWT)

V mnoha moderních implementacích je access_token JWT. (JSON Web Token). Jedná se o standard (RFC 7519) pro reprezentaci deklarací identity jako digitálně podepsaného JSON, ve třech částech oddělených tečkami: záhlaví, datová část a podpis, vše kódované v Base64URL.

Záhlaví obsahuje technické informace o tokenu. (algoritmus podpisu, typ tokenu a často identifikátor použitého klíče, kidDatová část obsahuje deklarace identity, jako například:

  • expdatum expirace.
  • iat: čas vysílání.
  • iss: vydavatel, obvykle URL IdP.
  • náhradník: jedinečný identifikátor uživatele.
  • aud: publikum, kterému je token určen.
  • jti: jedinečný identifikátor tokenu.

Podpis se generuje pomocí soukromého nebo tajného klíče.Jakákoli úprava tokenu proto naruší podpis a je detekována během validace. API získává veřejný klíč od IdP díky vlastnosti jwks_uri z dokumentu o objevování, který odkazuje na soubor JSON obsahující seznam veřejných klíčů a jejich kid.

Keycloak také umožňuje přizpůsobení vydaných tokenůDalší deklarace identity lze přidat na základě atributů uživatelů, skupin, rolí nebo dokonce pevných hodnot. To se provádí pomocí mapovačů konfigurovaných pro každého klienta nebo pro každý rozsah klienta, což API usnadňuje příjem přesně těch informací, které potřebují.

OAuth2 OpenID Connect a schéma JWT

Architektura Keycloak: Sféry, uživatelé, skupiny a role

Keycloak organizuje svou konfiguraci v RealmsJsou to jako „virtuální servery identity“ v rámci jedné instalace. Jiní dodavatelé něco podobného nazývají tenant nebo adresář. Každá oblast má své vlastní nezávislé uživatele, skupiny, klienty, zásady a nastavení.

Ve výchozím nastavení existuje speciální oblast s názvem master.Tento účet by měl být vyhrazen pro globální administrativní úkoly, jako je vytváření a správa dalších realmů. Administrátorský uživatel může spravovat více realmů ze stejné konzole, aniž by se musel pro každý z nich přihlašovat s jiným účtem.

Lokální uživatele lze definovat v rámci sféry.přiřazování vlastních atributů, seskupování a propojení s rolemi. Model je pečlivě navržen tak, aby se relevantní informace nakonec odrážely v tokenech spotřebovaných aplikací (role, skupiny, profilová data, bezpečnostní příznaky atd.).

Skupiny umožňují hierarchické uspořádání uživatelů.Skupina může mít podskupiny (podskupiny) a uživatel dědí atributy a role všech skupin, do kterých patří, včetně svých rodičů. To umožňuje velmi flexibilní modely autorizace, aniž by bylo nutné opakovat konfigurace pro každého uživatele.

Co se týče rolí, existují dvě hlavní úrovně:

  • Role v sférách: globální proměnné v rámci realmu, často používané pro oprávnění napříč vlastnostmi.
  • Role klientů: specifické pro konkrétní aplikaci, což umožňuje jemnou granularitu pro každou službu.

Keycloak podporuje složené roleTedy role, které zase zahrnují další role. To pomáhá seskupovat oprávnění a přiřazovat je najednou uživatelům nebo skupinám, i když je nejlepší to nepoužívat nadměrně, aby se nezkomplikovala správa nebo neovlivnil výkon.

Instalace Keycloaku ve vývojářském režimu: Docker, Kubernetes a VM

Nastavení laboratorního prostředí s Keycloakem Existuje několik jednoduchých možností: Docker kontejner, nasazení na Kubernetes (například s Minikube) nebo klasická instalace na virtuální stroj s Linuxem a OpenJDK.

Keycloak v Dockeru

Nejrychlejší způsob, jak spustit Keycloak pro testování Zahrnuje spuštění kontejneru s oficiálním obrazem, zpřístupnění portu 8080 a předání uživatelského jména a hesla správce prostřednictvím proměnných prostředí a spuštění do režimu start-dev (bez HTTPS a s integrovanou databází H2):

S jediným příkazem Dockeru funkční server je získán v http://localhost:8080, dost na to, aby se dalo experimentovat s administrátorskou konzolí, vytvářet realmy, uživatele, klienty a testovat základní integrace.

Keycloak v Kubernetes s Minikube

Pokud již pracujete s Kubernetes, můžete snadno nasadit Keycloak. Pomocí ukázkových manifestů z oficiálního repozitáře vytvoříte nasazení a službu a poté otevřete tunel s Minikube pro přístup ke službě z vašeho počítače, obvykle opět na portu 8080.

  Soubory CPI – definice, charakteristiky, použití, kompatibilní programy

Tento přístup je ideální pro simulaci prostředí blíže výrobě. (s pody, službami, externí konfigurací atd.) a experimentovat s řízeným nasazením, škálováním a upgrady Keycloaku na clusterech K8s.

Keycloak na Ubuntu s OpenJDK a PostgreSQL (pokročilý vývojářský režim)

Další možností je nainstalovat Keycloak na virtuální počítač s Ubuntu Používání OpenJDK a lokální databáze PostgreSQL s certifikátem podepsaným držitelem a vlastním názvem hostitele. I když se stále jedná o testovací scénář, blíží se to produkční topologii.

Mezi typické kroky patří:

  • Aktualizujte operační systém a nainstalujte Javu (například OpenJDK 11 nebo vyšší).
  • Nainstalujte PostgreSQL (ideálně na samostatný server, i když v laboratoři to může být na stejném počítači).
  • Vytvořte pro Keycloak konkrétního uživatele a databázi a udělte mu příslušná oprávnění.
  • Vytvořte systémového uživatele bez oprávnění (např. keycloak) pro spuštění služby.
  • Stáhněte si oficiální distribuci Keycloak a rozbalte ji do /opt/keycloak a upravit oprávnění.
  • Vygenerujte certifikát X.509 s vlastním podpisem pomocí OpenSSL a zapni to keycloak.conf spolu s parametry připojení PostgreSQL a hostname žádoucí.
  • Definujte jednotku systemd Chcete-li spustit Keycloak ve vývojářském režimu při spuštění systému, nastavte přihlašovací údaje správce pomocí proměnných prostředí.

Jakmile je služba spuštěna a fungujeObvykle je přístupný přes HTTPS na portu 8443 s nakonfigurovaným názvem hostitele. Pokud se používá certifikát s vlastním podpisem, je nutné jej v prohlížeči označit jako důvěryhodný (importem certifikační autority nebo samotného certifikátu do úložiště důvěryhodných certifikátů počítače).

Instalace a nasazení Keycloaku

Pokročilá nasazení: vysoká dostupnost, PostgreSQL a reverzní proxy

Když se přesuneme z laboratoře do výrobyObraz se mění: musíte myslet na vysokou dostupnost, robustní perzistenci dat, platné certifikáty a často i reverzní proxy, která centralizuje přístup HTTPS a vyvažování zátěže.

Poměrně běžným vzorem je nasazení více uzlů Keycloak. za load balancerem (např. Nginx) a s využitím databáze PostgreSQL v režimu HA jako perzistenčního backendu. Cílem je eliminovat jednotlivé body selhání jak pro aplikační, tak pro datovou vrstvu.

V tomto typu architektury se obvykle dodržují kroky, jako například následující::

  • Připravte aktualizované Linuxové servery (Debian/Ubuntu) a nainstalujte závislosti: unzip, wget, openjdk, openssl, Etc.
  • Vytvořit uživatele systému keycloak s domovem v /opt/keycloak a bez privilegovaných interaktivních přihlašovacích oprávnění.
  • Stáhněte si požadovanou verzi Keycloaku, rozbalte ji a přiřaďte vlastnictví určenému uživateli.
  • Vytvořte specifickou databázi v PostgreSQL s příslušným uživatelem a oprávněními, a také upravte vlastníka schématu a výchozí oprávnění k tabulkám.
  • Vygenerujte certifikáty s vlastním podpisem (nebo použijte certifikáty od interní certifikační autority) pro uzly Keycloak a nakonfigurujte HTTPS na aplikačním serveru.
  • Upravit keycloak.conf Pro připojení k VIP serveru PostgreSQL definujte porty HTTP/HTTPS, certifikáty, parametry proxy, název hostitele, zásobník clusteru (např. UDP) a úrovně protokolování.
  • Definujte službu systemd jednoduché bota Klíčenka s kc.sh start o kc.sh start --optimizedspráva automatických restartů v případě selhání.

Nginx se obvykle nasazují nad vrstvou pro publikování a vyvažování zátěže. jako reverzní proxy HTTPS s vlastním certifikátem TLS a konfigurací pro upstream, která ukazuje na uzly Keycloak na jeho backendových portech (obvykle 8080, pokud je TLS ukončeno v Nginxu).

Eliminovat jednotlivé body selhání ve vyvažovačiJe běžné konfigurovat dva uzly Nginx ve vysoké dostupnosti pomocí nástroje Keepalived. Tento nástroj spravuje plovoucí virtuální IP adresu (VIP), která je na jednom ze serverů inzerována jako hlavní a v případě selhání se přepne na záložní uzel, čímž se zachovává kontinuita služby.

Nastavení registrace sféry, uživatelů a aplikací (klientů)

Jakmile máme Keycloak spuštěný a funkční, dalším logickým krokem je Zahrnuje to vytvoření realmu pro naše uživatele a aplikace a odtud definování uživatelů, skupin, rolí a klientů (aplikací, které budou delegovat ověřování na Keycloak).

Nová doména se vytvoří z konzole pro správu. Jednoduše zadáním jeho názvu. Od té chvíle budeme mít izolovaný prostor s vlastním nastavením. Mezi prvními úpravami se obvykle hodí následující:

  • Nakonfigurujte SMTP pro odesílání e-mailů (ověření e-mailu, obnovení hesla, oznámení).
  • Povolit, pokud je to žádoucí Deklarativní uživatelský profil, což umožňuje deklarativně definovat, jaké atributy bude mít uživatel, jaké ověření se použijí a zda je uživatel může upravovat.
  • Úprava parametrů přihlášení: povolení nebo zakázání samoregistrace, zapamatování relace mezi restarty prohlížeče, povolení obnovení hesla atd.

Vytvoření uživatele v realmu je stejně jednoduché jako vyplnění formuláře Budete potřebovat uživatelské jméno, e-mailovou adresu, křestní jméno a příjmení. Poté si na kartě přihlašovací údaje nastavíte heslo (dočasné nebo trvalé). Odtud můžete přiřazovat skupiny, role a další atributy.

  Opravit chybu TSL Handshake Failed

Keycloak nabízí koncovým uživatelům specializovanou konzoli pro účty.kde si mohou prohlížet a upravovat data svého profilu, měnit heslo, kontrolovat aktivní relace nebo spravovat další faktory ověřování. Je to velmi pohodlný způsob, jak delegovat část základní správy svého účtu na uživatele.

Zosobnění je další zajímavou funkcí.Správce s oprávněním se může z konzole „vydávat“ za uživatele, aby reprodukoval problémy, ověřoval oprávnění atd., aniž by potřeboval heslo uživatele.

Aby aplikace používala Keycloak jako IdPMusí být registrován jako klient. V sekci Klienti se vytvoří nové ID klienta, typ se označí jako OpenID Connect (pokud se nepoužívá SAML) a vyberou se povolené toky OAuth 2.0: Standardní tok (autorizační kód), Přímé přístupové granty (heslo), Implicitní, Pověření klienta (servisní účty), Kód zařízení, CIBA atd.

Konfigurace klienta také rozhoduje Pokud je vyžadováno ověření klienta (tajný kód klienta nebo certifikáty), které URI pro přesměrování jsou platné a které webové zdroje jsou povoleny (velmi důležité v SPA kvůli politikám CORS). Odtud může aplikace použít oficiální knihovny nebo knihovny třetích stran k delegování ověření na Keycloak prostřednictvím OIDC.

Integrace s externími adresáři a dalšími poskytovateli identit

Keycloak může fungovat jako lokální zdroj identity (uživatelé, skupiny a role definované v rámci vlastní databáze) nebo může fungovat jako zprostředkovatel identity pro jednoho či více externích poskytovatelů.

Velmi běžnou integrací je integrace s Azure Active Directory.Azure AD ukládá firemní uživatele a skupiny a Keycloak se připojuje jako klient OIDC, aby stahoval identity a skupiny a mapoval je na lokální uživatele a role. Tím se zabrání duplicitě identit a administrativních úkolů napříč více lokalitami.

Obecně řečeno, použití Azure AD jako externího poskytovatele identity provádí se následující:

  • Zaregistrujte aplikaci ve službě Azure AD, získejte její ID klienta a vytvořte tajný klíč klienta.
  • Nakonfigurujte v Azure AD přesměrování URI na Keycloak (koncový bod zprostředkovatele OIDC v odpovídající sféře).
  • Upravte deklarace identity, které budou vydány v tokenu v aplikaci Azure AD, například zahrnutím skupin uživatelů.
  • V Keycloaku vytvořte poskytovatele identity OpenID Connect, který bude odkazovat na koncové body Azure (autorizace, token, odhlášení, uživatelské informace) a nakonfiguruje ID klienta, tajný klíč klienta a požadované parametry přihlášení.

Jakmile se mezi nimi vybuduje důvěraKdyž se uživatel přihlásí prostřednictvím Azure AD, Keycloak ho lokálně vytvoří (nebo synchronizuje) a pomocí pokročilých mapovačů může namapovat skupiny Azure na role Keycloak. Například skupinu „Vývojáři“ v Azure lze převést na roli „Vývojáři“ v Keycloak, která se poté rozšíří do integrovaných aplikací a služeb (například Jenkins).

Kromě Azure AD umožňuje Keycloak federaci identit s LDAP, klasický Active Directory, další OIDC IdP, poskytovatelé sociálních sítí (Google, Facebook, GitHub atd.) a další, s možností kombinovat několik zdrojů současně v rámci stejné domény.

Další zabezpečení: boti, CAPTCHA a osvědčené postupy

Ačkoli Keycloak výrazně posiluje zabezpečení ověřování (MFA, zásady pro hesla, uzamčení účtů, řízení relací atd.), přihlašovací, registrační a obnovení hesla zůstávají jasným cílem botů a automatizovaných útoků.

Pro zmírnění těchto typů hrozebDoporučuje se kombinovat Keycloak s mechanismy proti botům, jako jsou například řešení CAPTCHA kompatibilní s GDPR, která rozlišují mezi lidskou a automatizovanou návštěvností, aniž by to ohrozilo uživatelský zážitek. Tato řešení jsou obvykle integrována do přihlašovacích a registračních formulářů a přidávají tak další vrstvu ochrany proti útokům typu „credential stuffing“, hromadnému vytváření účtů nebo zneužívání postupů pro obnovení hesla.

Kromě CAPTCHA patří mezi osvědčené postupy monitor protokoly pro přístup, nastavit upozornění na anomální nárůsty neúspěšných pokusů, pravidelně kontrolovat vydané tokeny a jejich trvání, zajistit, aby vnějšímu prostředí byly přístupné pouze nezbytné koncové body, a udržovat Keycloak a jeho závislosti aktualizované nejnovějšími bezpečnostními záplatami.

Celý tento ekosystém funkcí (SSO, multi-tenancy, integrace s externími adresáři, konfigurovatelné tokeny, vysoce dostupné nasazení a ochrana před boty) dělá z Keycloaku velmi výkonný nástroj pro centralizaci ověřování a autorizace pro moderní aplikace, který pomáhá firmám posílit jejich zabezpečení, aniž by obětovaly uživatelský komfort nebo neustále obnovovaly správu identit.