Ve většině velkých společností, včetně X5 Retail Group, se s rozvojem zvyšuje počet projektů, kde je potřeba autorizace uživatelů. Postupem času je nutný bezproblémový přechod uživatelů mezi aplikacemi, což vyžaduje použití jednotného serveru Single-Sign-On (SSO). Ale co, když už jsou v různých projektech využívány identifikační poskytovatelé jako AD nebo jiné, které nemají další atributy? Na pomoc přichází třída systémů nazvaných „identifikační brokery“. Mezi nejvíce funkční se řadí jejich zástupci, jako jsou Keycloak, Gravitee Access management a další. Nejčastěji mohou být scénáře použití různé: strojová interakce, zapojení uživatelů atd. Řešení by mělo podporovat flexibilní a škálovatelnou funkčnost, schopnou sjednotit všechny požadavky v jednom, a takovým řešením v naší společnosti je nyní identifikační broker – Keycloak.
Keycloak je produkt s otevřeným zdrojovým kódem, určený pro identifikaci a kontrolu přístupu, podporovaný společností RedHat. Je základem pro produkty společnosti využívající SSO – RH-SSO.
Základní pojmy
Než začneme zkoumat řešení a přístupy, měli bychom se jasně určit v termínech a posloupnosti procesů:
Identifikace — to je procedura rozpoznávání subjektu podle jeho identifikátoru (jinými slovy, to je určení jména, přihlášení nebo čísla).
Autentizace — to je procedura ověřování (uživatel se ověřuje pomocí hesla, e-mail se ověřuje elektronickým podpisem atd.)
Autentizace — to je poskytování přístupu k nějakému zdroji (např. k elektronické poště).
Identifikační broker Keycloak
Keycloak — to je řešení pro správu identifikace a přístupu s otevřeným zdrojovým kódem, určené pro použití v IS, kde mohou být použity vzory mikroservisní architektury.
Keycloak nabízí takové funkce, jako je jednotný přístup (SSO), brokerská identifikace a sociální přihlášení, federace uživatelů, klientské adaptéry, administrátorskou konzoli a konzoli pro správu účtů.
Základní funkčnost podporovaná v Keycloak:
- Single-Sign On a Single-Sign Out pro webové aplikace.
- Podpora OpenID/OAuth 2.0/SAML.
- Identity Brokering – autentizace pomocí externích poskytovatelů identit OpenID Connect nebo SAML.
- Social Login – podpora pro Google, GitHub, Facebook, Twitter pro identifikaci uživatelů.
- User Federation – synchronizace uživatelů z LDAP a Active Directory serverů a dalších poskytovatelů identit.
- Kerberos bridge – využití Kerberos serveru pro automatickou autentizaci uživatelů.
- Admin Console — pro centrální správu nastavení a parametrů řešení prostřednictvím Webu.
- Account Management Console – pro samosprávu uživatelského profilu.
- Přizpůsobení řešení na základě firemního stylu.
- 2FA Authentication – podpora TOTP/HOTP pomocí Google Authenticator nebo FreeOTP.
- Login Flows – uživatelé mohou provádět sebedeklaraci, obnovu a resetování hesla a další.
- Session Management – administrátoři mohou spravovat relace uživatelů z jednoho místa.
- Token Mappers – přiřazení atributů uživatelů, rolí a dalších požadovaných atributů do tokenů.
- Flexibilní správa politik prostřednictvím realm, aplikací a uživatelů.
- CORS Support – klientské adaptéry mají vestavěnou podporu CORS.
- Service Provider Interfaces (SPI) – široká škála SPI umožňuje nastavit různé aspekty fungování serveru: autentizační toky, poskytovatele identit, mapování protokolů a mnohé další.
- Klientské adaptéry pro JavaScript aplikace, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Podpora pro práci s různými aplikacemi, které podporují OpenID Connect Relying Party library nebo SAML 2.0 Service Provider Library.
- Možnost rozšíření pomocí pluginů.
Pro procesy CI/CD, stejně jako pro automatizaci procesů správy v Keycloak, lze použít REST API/JAVA API. Dokumentace je k dispozici v elektronické podobě:
REST API
JAVA API
Podnikové identifikační poskytovatele (On-Premise)
Možnost autentizace uživatelů prostřednictvím služeb User Federation.
Může být také použita jednolitá autentizace – pokud se uživatelé autentizují na pracovních stanicích s Kerberos (LDAP nebo AD), mohou být automaticky autentizováni na Keycloak bez nutnosti znovu zadávat své uživatelské jméno a heslo.
Pro autentizaci a následnou autorizaci uživatelů je možné použít relační databázový systém, což je obvykle nejvhodnější pro vývojové prostředí, neboť to nevyžaduje dlouhé nastavení a integrace v raných fázích projektů. Ve výchozím nastavení Keycloak používá vestavěnou databázi pro ukládání nastavení a údajů o uživatelích.
Seznam podporovaných databázových systémů je rozsáhlý a zahrnuje: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle a další. V současné době jsou nejvíce testovány Oracle 12C Release1 RAC a Galera 3.12 cluster pro MariaDB 10.1.19.
Identifikační poskytovatelé — sociální přihlášení.
Je možné používat přihlášení ze sociálních sítí. Pro aktivaci možnosti autentizovat uživatele se používá konzole administrátora Keycloak. Žádné změny v kódu aplikací nejsou potřebné a tento funkční prvek je dostupný "out of the box" a může být aktivován v jakékoli fázi realizace projektu.
Pro autentizaci uživatelů je možné použít poskytovatele OpenID/SAML Identity.
Typické scénáře autorizace s použitím OAuth2 v Keycloak.
Authorization Code Flow — používá se se serverovými aplikacemi (server-side applications). Je to jeden z nejběžnějších typů povolení k autorizaci, protože se dobře hodí pro serverové aplikace, kde není zdrojový kód aplikace a data klienta přístupná třetím osobám. Proces je v tomto případě založen na přesměrování. Aplikace by měla být schopna interagovat s uživatelským agentem (user-agent), jako je webový prohlížeč — získávat kódy autorizace API přesměrovávané prostřednictvím uživatelského agenta.
Implicit Flow — používá se mobilními nebo webovými aplikacemi (aplikace běžící na zařízení uživatele).
Implicitní typ oprávnění se používá mobilními a webovými aplikacemi, kde není zaručena důvěrnost klienta. Tento typ oprávnění také využívá přesměrování uživatelského agenta, kdy se přístupový token předává uživatelskému agentu k dalšímu použití v aplikaci. To činí token dostupným uživateli a dalším aplikacím na zařízení uživatele. Při tomto typu oprávnění se neprovádí autentizace identity aplikace a celý proces se spoléhá na URL přesměrování (dříve registrované ve službě).
Implicitní tok nepodporuje obnovovací tokeny (refresh tokens).
Grant Flow pro klientské údaje — se používá při přístupu aplikace k API. Tento typ oprávnění se obvykle používá pro interakce "server-server", které by měly probíhat na pozadí bez okamžité interakce s uživateli. Grant Flow pro klientské údaje umožňuje webové službě (důvěrnému klientovi) používat své vlastní údaje místo ztělesnění uživatele pro autentizaci při volání jiných webových služeb. Pro vyšší úroveň zabezpečení může volající služba použít certifikát (namísto sdíleného tajemství) jako údaje.
Specifikace OAuth2 je popsána v
JWT token a jeho výhody
JWT (JSON Web Token) — otevřený standard (), který určuje kompaktní a autonomní způsob pro bezpečný přenos informací mezi stranami ve formě JSON objektu.
Podle standardu se token skládá ze tří částí v base-64 formátu oddělených tečkami. První část se nazývá hlavička (header), která obsahuje typ tokenu a název hashovacího algoritmu pro získání digitálního podpisu. Druhá část uchovává hlavní informace (uživatel, atributy atd.). Třetí část – digitální podpis.
..
Nikdy neukládejte token ve vaší databázi. Protože platný token je ekvivalentní heslu, ukládání tokenu je stejné jako ukládání hesla v otevřeném formátu.
Access-token — je to token, který poskytuje jeho majiteli přístup k chráněným zdrojům serveru. Obvykle má krátkou životnost a může obsahovat další informace, jako je IP adresa strany, která tento token žádá.
Refresh token — je to token, který umožňuje klientům požadovat nové access tokeny po uplynutí jejich životnosti. Tyto tokeny jsou obvykle vydávány na delší dobu.
Hlavní výhody použití v mikroslužbové architektuře:
- Možnost přístupu k různým aplikacím a službám prostřednictvím jednorázové autentizace.
- Pokud chybí některé požadované atributy v profilu uživatelů, je možné obohatit data, která mohou být do payloadu přidána, včetně automatizace a 'za běhu'.
- Není nutné uchovávat informace o aktivních relacích, serverová aplikace by měla pouze ověřit podpis.
- Flexibilnější správa přístupu díky dodatečným atributům v payloadu.
- Použití podpisu tokenu pro hlavičku a payload zvyšuje bezpečnost řešení jako celku.
JWT token — složení
Nadpis — ve výchozím nastavení hlavička obsahuje pouze typ tokenu a algoritmus používaný pro šifrování.
Typ tokenu je uložen v klíči 'typ'. Klíč 'typ' je v JWT ignorován. Pokud je klíč 'typ' přítomen, jeho hodnota by měla být JWT, aby označila, že tento objekt je JSON Web Token.
Druhý klíč 'alg' určuje algoritmus používaný pro šifrování tokenu. Ve výchozím nastavení by měl být nastaven na HS256. Hlavička je kódována v base64.
{ "alg": "HS256", "typ": "JWT"}
Payload (obsah) — v payloadu je uložena jakákoli informace, kterou je třeba ověřit. Každý klíč v payloadu je znám jako "claim". Například, do aplikace lze vstoupit pouze na pozvání (uzavřená promoakce). Když chceme někoho pozvat k účasti, pošleme mu e-mail s pozváním. Je důležité ověřit, že e-mailová adresa patří osobě, která pozvání přijímá, proto tuto adresu zahrneme do payloadu a uložíme ji pod klíčem "e-mail".
{ "email": "example@x5.ru" }
Klíče v payload mohou být libovolné. Přesto existuje několik rezervovaných:
- iss (Issuer) — určuje aplikaci, ze které je token odesílán.
- sub (Předmět) — určuje téma tokenu.
- aud (Publikum) – pole citlivých na velikost písmen řetězců nebo URI, které představuje seznam příjemců tohoto tokenu. Když přijímající strana obdrží JWT s tímto klíčem, měla by zkontrolovat, zda je sama mezi příjemci – jinak token ignorovat.
- exp (Čas expirace) — udává, kdy vyprší platnost tokenu. Standard JWT vyžaduje, aby ve všech implementacích byly tokeny s vypršenou platností odmítnuty. Klíč exp by měl být časovou značkou ve formátu unix.
- nbf (Nejprve) — je to čas ve formátu unix, který určuje okamžik, kdy token začne být platný.
- iat (Vydáno) — tento klíč představuje čas, kdy byl token vydán a může být použit k určení stáří JWT. Klíč iat by měl být časovou značkou ve formátu unix.
- Jti (ID JWT) — řetězec, který určuje unikátní identifikátor tohoto tokenu s ohledem na velikost písmen.
Je důležité pochopit, že payload není přenášen ve šifrované podobě (i když mohou být tokeny vnořené a pak je možné přenášet šifrovaná data). Proto do ní nelze ukládat žádné tajné informace. Stejně jako hlavička, payload je zakódována v base64.
Podpis — když máme hlavičku a payload, můžeme vypočítat podpis.
Berou se zakódované v base64: hlavička a payload, ty se spojí do řetězce přes tečku. Poté tento řetězec a tajný klíč vstupují do algoritmu šifrování, který je uveden v hlavičce (klíč „alg“). Klíč může být jakýkoliv řetězec. Delší řetězce budou preferovány, protože k jejich prolomení bude zapotřebí více času.
{"alg":"RSA1_5", "payload":"A128CBC-HS256"}
Budování architektury odolného klastru Keycloak
Při použití jednoho klastru pro všechny projekty se zvyšují požadavky na řešení SSO. Když je počet projektů malý, tyto požadavky nejsou pro všechny projekty tak patrné, avšak se zvyšujícím se počtem uživatelů a integrací se zvyšují požadavky na dostupnost a výkonnost.
Zvyšování rizik selhání jednotného SSO zvyšuje nároky na architekturu řešení a používané metody zálohování komponent a vede k velmi přísnému SLA. V této souvislosti mají častěji projekty při vývoji nebo raných fázích implementace řešení vlastní infrastrukturu, která není odolná proti selhání. S postupem času je potřeba zakotvit možnosti rozvoje a škálování. Nejflexibilnější je budování odolného clusteru s využitím kontejnerové virtualizace nebo hybridního přístupu.
Pro práci v režimu Active/Active a Active/Passive je třeba zajistit konzistenci dat v relační databázi — oba uzly databáze musí být synchronně replikovány mezi různými geograficky rozloženými datovými centry.
Nejjednodušším příkladem odolné instalace.
Jaké výhody přináší použití jednotného clusteru:
- Vysoká dostupnost a výkon.
- Podpora režimů provozu: Active/Active, Active/Passive.
- Možnost dynamického škálování — při použití kontejnerové virtualizace.
- Možnost centralizovaného řízení a monitorování.
- Jednotný přístup k identifikaci/autentizaci/autorizačním uživatelům v projektech.
- Transparentnější interakce mezi různými projekty bez účasti uživatelů.
- Možnost opětovného využití JWT tokenu v různých projektech.
- Jednotný důvěryhodný bod.
- Rychlejší spuštění projektů pomocí mikroslužeb/kontejnerové virtualizace (není potřeba zřizování a konfigurace dalších komponent).
- Možnost zakoupení komerční podpory od dodavatele.
Na co je třeba dávat pozor při plánování clusteru
Počáteční model
Keycloak používá systém správy databáze k uchovávání: realms, clients, users atd.
Podporuje široké spektrum databází: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak je dodáván s vlastní integrovanou relační databází. Doporučuje se používat pro méně zatížené prostředí – například pro vývojová prostředí.
Pro práci v režimu Active/Active a Active/Passive je třeba zajistit konzistenci dat v relační databázi a oba uzly databázového clusteru jsou synchronně replikovány mezi datovými centry.
Distribuovaný cache (Infinspan)
Pro správnou funkci clustera je nutná dodatečná synchronizace následujících typů cache pomocí JBoss Data Grid:
Authenticated sessions — používá se k uchování dat při autentifikaci konkrétního uživatele. Dotazy z této cache obvykle zahrnují pouze prohlížeč a server Keycloak, nikoli aplikaci.
Action tokens — používají se pro scénáře, kdy je třeba, aby uživatel potvrdil akci asynchronně (e-mailem). Například během toku zapomenuté heslo cache actionTokens Infinispan slouží k sledování metadat o souvisejících akcích, které již byly použity, takže je nelze použít znovu.
Caching a invalidace trvalých dat – používá se k ukládání trvalých dat do cache, aby se předešlo nadbytečným dotazům do databáze. Když jakýkoli server Keycloak aktualizuje data, všechny ostatní servery Keycloak ve všech datových centrech o tom musí vědět.
Work — používá se pouze k zasílání zpráv o neplatnosti mezi uzly clusteru a datovými centry.
Uživatelské relace — používají se k uchování údajů relací uživatelů, které platí po dobu relace prohlížeče uživatele. Cache by měla zpracovávat HTTP dotazy od koncového uživatele a aplikace.
Ochrana před brute force útoky — používá se k sledování údajů o neúspěšných pokusech o přihlášení.
Vyvažování zátěže
Zátěžový vyrovnávač je jediným bodem vstupu do keycloaku a měl by podporovat sticky sessions.
Aplikační servery
Používají se pro kontrolu interakce komponent mezi sebou a mohou být virtualizovány nebo kontejnerizovány s využitím dostupných automatizačních a dynamických škálovacích nástrojů automatizace infrastruktury. Nejčastější scénáře nasazení jsou v OpenShift, Kubernetes, Rancher.
Tímto končí první část – teoretická. V následujících cyklech článků budou představeny příklady integrací s různými identifikačními poskytovateli a příklady konfigurací.
Zdroj: habr.com
