V žádné velké společnosti, a X5 Retail Group není výjimkou, s jejím rozvojem roste počet projektů, které vyžadují autorizaci uživatele. Postupem času je vyžadován bezproblémový přechod uživatelů z jedné aplikace do druhé a pak je potřeba používat jediný server Single-Sing-On (SSO). Ale co když poskytovatelé identit, jako je AD nebo jiní, kteří nemají další atributy, jsou již používáni v různých projektech. Na pomoc přijde třída systémů zvaných „zprostředkovatelé identifikace“. Nejfunkčnější jsou jeho zástupci, jako je Keycloak, Gravitee Access management atd. Nejčastěji mohou být případy použití různé: interakce se strojem, účast uživatele atd. Řešení musí podporovat flexibilní a škálovatelnou funkcionalitu, která dokáže sloučit všechny požadavky do jednoho, a tato řešení má nyní naše společnost indikačního makléře - Keycloak.
Keycloak je open source produkt pro kontrolu identity a přístupu spravovaný společností RedHat. Je základem pro produkty společnosti využívající SSO - RH-SSO.
Základní pojmy
Než se začnete zabývat řešeními a přístupy, měli byste se rozhodnout v termínech a posloupnosti procesů:
Identifikace je postup pro rozpoznání subjektu podle jeho identifikátoru (jinými slovy jde o definici jména, přihlašovacího jména nebo čísla).
Ověřování - jedná se o autentizační postup (uživatel je kontrolován heslem, dopis je kontrolován elektronickým podpisem atd.)
Povolení - jedná se o poskytnutí přístupu ke zdroji (například k e-mailu).
Kryt na klíče od makléře identity
Klíčenka je open source řešení pro správu identit a přístupu navržené pro použití v IS, kde lze použít vzory architektury mikroslužeb.
Keycloak nabízí funkce, jako je jednotné přihlášení (SSO), zprostředkovaná identita a sociální přihlášení, federace uživatelů, klientské adaptéry, administrátorská konzole a konzola pro správu účtů.
Základní funkce podporované Keycloak:
- Single-Sign On a Single-Sign Out pro aplikace prohlížeče.
- Podpora pro OpenID/OAuth 2.0/SAML.
- Identity Brokering – ověřování pomocí externích poskytovatelů identity OpenID Connect nebo SAML.
- Sociální přihlášení – podpora Google, GitHub, Facebook, Twitter pro identifikaci uživatele.
- Federace uživatelů – synchronizace uživatelů ze serverů LDAP a Active Directory a dalších poskytovatelů identity.
- Kerberos bridge – pomocí serveru Kerberos pro automatickou autentizaci uživatele.
- Admin Console – pro jednotnou správu nastavení a možností řešení přes web.
- Account Management Console - pro vlastní správu uživatelského profilu.
- Přizpůsobení řešení na základě korporátní identity společnosti.
- 2FA Authentication – podpora TOTP/HOTP pomocí Google Authenticator nebo FreeOTP.
- Přihlašovací toky – je možná samoregistrace uživatele, obnovení a resetování hesla a další.
- Správa relací – administrátoři mohou spravovat uživatelské relace z jednoho místa.
- Token Mappers - vazba uživatelských atributů, rolí a dalších požadovaných atributů na tokeny.
- Flexibilní správa zásad napříč sférou, aplikací a uživateli.
- Podpora CORS – Klientské adaptéry mají vestavěnou podporu CORS.
- Rozhraní poskytovatelů služeb (SPI) – Velké množství rozhraní SPI, které vám umožňují přizpůsobit různé aspekty serveru: toky ověřování, poskytovatele identity, mapování protokolů a další.
- Klientské adaptéry pro aplikace JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Podpora pro práci s různými aplikacemi, které podporují knihovnu OpenID Connect Relying Party nebo knihovnu poskytovatelů služeb SAML 2.0.
- Rozšiřitelné pomocí pluginů.
Pro procesy CI / CD a také 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
Poskytovatelé podnikové identity (on-premise)
Schopnost ověřovat uživatele prostřednictvím služeb federace uživatelů.
Lze použít i průchozí autentizaci – pokud se uživatelé ověřují vůči pracovním stanicím s Kerberos (LDAP nebo AD), pak mohou být automaticky autentizováni na Keycloak, aniž by museli znovu zadávat své uživatelské jméno a heslo.
Pro autentizaci a další autorizaci uživatelů je možné využít relační DBMS, která je nejvíce použitelná pro vývojová prostředí, protože nezahrnuje zdlouhavé nastavování a integrace v raných fázích projektů. Ve výchozím nastavení používá Keycloak k ukládání nastavení a uživatelských dat vestavěný DBMS.
Seznam podporovaných DBMS je rozsáhlý a zahrnuje: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle a další. Zatím nejvíce testovanými jsou Oracle 12C Release1 RAC a Galera 3.12 cluster pro MariaDB 10.1.19.
Poskytovatelé identity – sociální přihlášení
Je možné použít přihlášení ze sociálních sítí. Chcete-li aktivovat možnost ověřování uživatelů, použijte administrátorskou konzoli Keycloack. Změny v kódu aplikace nejsou vyžadovány a tato funkce je k dispozici ihned po vybalení a lze ji aktivovat v jakékoli fázi projektu.
Pro autentizaci uživatele je možné použít poskytovatele OpenID/SAML Identity.
Typické scénáře autorizace pomocí OAuth2 v Keycloak
Tok autorizačního kódu - používá se s aplikacemi na straně serveru. Jeden z nejběžnějších typů oprávnění k autorizaci, protože se dobře hodí pro serverové aplikace, kde zdrojový kód aplikace a klientská data nejsou k dispozici cizím osobám. Proces je v tomto případě založen na přesměrování. Aplikace musí být schopna komunikovat s uživatelským agentem (user-agent), jako je webový prohlížeč, aby mohla přijímat autorizační kódy API přesměrované přes uživatelského agenta.
implicitní tok - používají mobilní nebo webové aplikace (aplikace běžící na zařízení uživatele).
Typ implicitní autorizace používají mobilní a webové aplikace, kde nelze zaručit důvěrnost klienta. Implicitní typ oprávnění také využívá přesměrování uživatelského agenta, přičemž přístupový token je předán uživatelskému agentovi pro další použití v aplikaci. Tím se token zpřístupní uživateli a dalším aplikacím v zařízení uživatele. Tento typ autorizačního oprávnění neověřuje identitu aplikace a samotný proces závisí na přesměrovací URL (dříve registrované u služby).
Implicitní tok nepodporuje obnovovací tokeny přístupového tokenu.
Tok udělení přihlašovacích údajů klienta — používají se, když aplikace přistupuje k API. Tento typ oprávnění k autorizaci se obvykle používá pro interakce server-server, které je třeba provádět na pozadí bez okamžité interakce uživatele. Tok udělení přihlašovacích údajů klienta umožňuje webové službě (důvěrnému klientovi) používat své vlastní přihlašovací údaje namísto vydávání se za uživatele k ověření při volání jiné webové služby. Pro vyšší úroveň zabezpečení je možné, aby volající služba použila jako pověření certifikát (místo sdíleného tajemství).
Specifikace OAuth2 je popsána v
JWT token a jeho výhody
JWT (JSON Web Token) je otevřený standard (), který definuje kompaktní a samostatný způsob, jak bezpečně přenášet informace mezi stranami jako objekt JSON.
Podle standardu se token skládá ze tří částí ve formátu base-64, oddělených tečkami. První část se nazývá hlavička, která obsahuje typ tokenu a název hashovacího algoritmu pro získání digitálního podpisu. V druhé části jsou uloženy základní informace (uživatel, atributy atd.). Třetí částí je digitální podpis.
. .
Nikdy neukládejte token ve vaší DB. Protože platný token je ekvivalentní heslu, uložení tokenu je jako uložení hesla ve formátu prostého textu.
Přístupový token je token, který uděluje svému vlastníkovi přístup k zabezpečeným zdrojům serveru. Obvykle má krátkou životnost a může nést další informace, jako je IP adresa strany požadující token.
Obnovit token je token, který umožňuje klientům žádat o nové přístupové tokeny po vypršení jejich životnosti. Tyto tokeny jsou obvykle vydávány na dlouhou dobu.
Hlavní výhody použití v architektuře mikroslužeb:
- Možnost přístupu k různým aplikacím a službám prostřednictvím jednorázového ověření.
- Při absenci řady požadovaných atributů v uživatelském profilu je možné obohatit o data, která lze přidat do užitečného zatížení, včetně automatizovaných a on-the-fly.
- Není potřeba ukládat informace o aktivních relacích, serverová aplikace potřebuje pouze ověřit podpis.
- Flexibilnější řízení přístupu prostřednictvím dalších atributů v užitečné zátěži.
- Použití tokenového podpisu pro hlavičku a užitečné zatížení zvyšuje bezpečnost řešení jako celku.
JWT token - složení
Titul - ve výchozím nastavení hlavička obsahuje pouze typ tokenu a algoritmus použitý pro šifrování.
Typ tokenu je uložen v klíči "typ". Klíč 'type' je v JWT ignorován. Je-li přítomen klíč „typ“, jeho hodnota musí být JWT, aby bylo zřejmé, že tento objekt je webový token JSON.
Druhý klíč „alg“ definuje algoritmus použitý k šifrování tokenu. Ve výchozím nastavení by měl být nastaven na HS256. Záhlaví je zakódováno v base64.
{ "alg": "HS256", "type": "JWT"}
užitečné zatížení (obsah) - užitečné zatížení ukládá veškeré informace, které je třeba zkontrolovat. Každý klíč v užitečné zátěži je známý jako „nárok“. Například do aplikace můžete vstoupit pouze pozvánkou (uzavřená promo akce). Když chceme někoho pozvat k účasti, pošleme mu zvací dopis. Je důležité zkontrolovat, že e-mailová adresa patří osobě, která pozvání přijímá, proto tuto adresu zahrneme do užitečného zatížení, proto ji uložíme do klíče „e-mail“
{ "e-mailem": "[chráněno e-mailem]"}
Klíče v užitečné zátěži mohou být libovolné. Existuje však několik vyhrazených:
- iss (Essuer) – Identifikuje aplikaci, ze které je token odesílán.
- sub (Předmět) - definuje předmět tokenu.
- aud (Audience) je pole řetězců nebo URI rozlišujících velká a malá písmena, které je seznamem příjemců tohoto tokenu. Když přijímající strana obdrží JWT s daným klíčem, musí zkontrolovat svou přítomnost v příjemcích – jinak token ignorovat.
- exp (čas vypršení platnosti) – Označuje, kdy vyprší platnost tokenu. Standard JWT vyžaduje, aby všechny jeho implementace odmítaly tokeny, jejichž platnost vypršela. Klíč exp musí být časové razítko ve formátu unix.
- nbf (Not Before) je čas v unixovém formátu, který určuje okamžik, kdy se token stane platným.
- iat (Vydáno v) – Tento klíč představuje čas vydání tokenu a lze jej použít k určení věku JWT. Klíč iat musí být časové razítko ve formátu unix.
- Jti (JWT ID) — řetězec, který definuje jedinečný identifikátor tohoto tokenu, přičemž se rozlišují velká a malá písmena.
Je důležité pochopit, že payload se nepřenáší v šifrované podobě (i když tokeny lze vnořit a je pak možné přenášet šifrovaná data). Proto nemůže ukládat žádné tajné informace. Stejně jako záhlaví je užitečné zatížení kódováno base64.
Podpis - když máme titul a užitečné zatížení, můžeme vypočítat podpis.
Base64-encoded: záhlaví a užitečné zatížení jsou převzaty, jsou spojeny do řetězce prostřednictvím tečky. Poté se tento řetězec a tajný klíč vloží do šifrovacího algoritmu uvedeného v záhlaví (klíč „alg“). Klíčem může být libovolný řetězec. Nejvýhodnější budou delší struny, protože jejich nabírání bude trvat déle.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Vytváření architektury klastru proti selhání Keycloak
Při použití jednoho clusteru pro všechny projekty jsou zvýšené požadavky na řešení SSO. Při malém počtu projektů nejsou tyto požadavky tak markantní u všech projektů, nicméně s nárůstem počtu uživatelů a integrací rostou požadavky na dostupnost a výkon.
Zvýšení rizika selhání jediného SSO zvyšuje požadavky na architekturu řešení a metody používané pro redundantní komponenty a vede k velmi těsné SLA. V tomto ohledu mají projekty častěji během vývoje nebo raných fází implementace řešení svou vlastní infrastrukturu bez chyb. Jak vývoj postupuje, je nutné stanovit příležitosti pro rozvoj a škálování. Nejflexibilnější je vytvořit cluster s podporou převzetí služeb při selhání pomocí virtualizace kontejnerů nebo hybridního přístupu.
Pro práci v režimech clusteru Aktivní/Aktivní a Aktivní/Pasivní je nutné zajistit konzistenci dat v relační databázi – oba databázové uzly musí být synchronně replikovány mezi různými geograficky distribuovanými datovými centry.
Nejjednodušší příklad instalace odolné proti chybám.
Jaké jsou výhody použití jednoho clusteru:
- Vysoká dostupnost a výkon.
- Podpora provozních režimů: Aktivní / Aktivní, Aktivní / Pasivní.
- Možnost dynamického škálování – při použití virtualizace kontejnerů.
- Možnost centralizované správy a monitorování.
- Jednotný přístup k identifikaci/autentizaci/autorizaci uživatelů v projektech.
- Transparentnější interakce mezi různými projekty bez zapojení uživatelů.
- Možnost opětovného použití tokenu JWT v různých projektech.
- Jediný bod důvěry.
- Rychlejší spouštění projektů pomocí mikroslužeb/virtualizace kontejnerů (není třeba zvedat a konfigurovat další komponenty).
- Je možné zakoupit komerční podporu od dodavatele.
Na co se zaměřit při plánování klastru
DBMS
Keycloak používá systém správy databází k ukládání: sfér, klientů, uživatelů atd.
Je podporována široká škála DBMS: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak přichází s vlastní vestavěnou relační databází. Doporučuje se používat pro nezatížená prostředí – jako jsou vývojová prostředí.
Pro práci v režimech klastru Aktivní/Aktivní a Aktivní/Pasivní je vyžadována konzistence dat v relační databázi a oba uzly databázového klastru jsou synchronně replikovány mezi datovými centry.
Distribuovaná mezipaměť (Infinspan)
Aby cluster fungoval správně, je nutná dodatečná synchronizace následujících typů mezipamětí pomocí JBoss Data Grid:
Autentizační relace – slouží k uložení dat při ověřování konkrétního uživatele. Požadavky z této mezipaměti obvykle zahrnují pouze prohlížeč a server Keycloak, nikoli aplikaci.
Tokeny akcí se používají pro scénáře, kdy uživatel potřebuje potvrdit akci asynchronně (e-mailem). Například během toku zapomenutí hesla se mezipaměť actionTokens Infinispan používá ke sledování metadat o přidružených tokenech akcí, které již byly použity, takže ji nelze znovu použít.
Ukládání do mezipaměti a zneplatnění perzistentních dat – používá se k ukládání perzistentních dat do mezipaměti, aby se předešlo zbyteč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.
Práce – Používá se pouze k odesílání neplatných zpráv mezi uzly clusteru a datovými centry.
Uživatelské relace – slouží k ukládání dat o uživatelských relacích, které jsou platné po dobu trvání relace prohlížeče uživatele. Mezipaměť musí zpracovávat požadavky HTTP od koncového uživatele a aplikace.
Ochrana hrubou silou – slouží ke sledování dat o neúspěšných přihlášeních.
Vyvažování zátěže
Nástroj pro vyrovnávání zatížení je jediným vstupním bodem pro maskování klíčů a musí podporovat pevné relace.
Aplikační servery
Používají se k řízení vzájemné interakce komponent a lze je virtualizovat nebo kontejnerizovat pomocí stávajících automatizačních nástrojů a dynamického škálování nástrojů pro automatizaci infrastruktury. Nejběžnější scénáře nasazení v OpenShift, Kubernates, Rancher.
Tím končí první část – teoretická. V další sérii článků budou rozebrány příklady integrací s různými poskytovateli identit a příklady nastavení.
Zdroj: www.habr.com