V žiadnej veľkej spoločnosti a X5 Retail Group nie je výnimkou, keďže s jej vývojom narastá počet projektov, ktoré vyžadujú autorizáciu užívateľa. Postupom času sa vyžaduje bezproblémový prechod používateľov z jednej aplikácie do druhej a potom je potrebné použiť jeden server Single-Sing-On (SSO). Ale čo keď sa už v rôznych projektoch používajú poskytovatelia identity ako AD alebo iní, ktorí nemajú ďalšie atribúty. Na pomoc príde trieda systémov nazývaná „sprostredkovatelia identifikácie“. Najfunkčnejší sú jeho zástupcovia ako Keycloak, Gravitee Access management atď. Najčastejšie môžu byť prípady použitia rôzne: interakcia so strojom, participácia používateľa atď. Riešenie musí podporovať flexibilnú a škálovateľnú funkcionalitu, ktorá dokáže spojiť všetky požiadavky do jedného, a takéto riešenia má teraz naša spoločnosť indikačného makléra - Keycloak.
Keycloak je open source produkt na kontrolu identity a prístupu spravovaný spoločnosťou RedHat. Je základom pre produkty spoločnosti využívajúce SSO - RH-SSO.
Základné pojmy
Predtým, ako sa začnete zaoberať riešeniami a prístupmi, mali by ste sa rozhodnúť v termínoch a postupnosti procesov:
identifikácia je postup na rozpoznanie subjektu podľa jeho identifikátora (inými slovami ide o definíciu mena, loginu alebo čísla).
overenie pravosti - ide o autentifikačný postup (používateľ je kontrolovaný heslom, list je kontrolovaný elektronickým podpisom atď.)
Povolenie – poskytuje prístup k zdroju (napríklad e-mailu).
Kryt na kľúče sprostredkovateľa identity
plášť na kľúče je open source riešenie správy identity a prístupu určené na použitie v IS, kde je možné použiť vzory architektúry mikroslužieb.
Keycloak ponúka funkcie, ako je jednotné prihlásenie (SSO), sprostredkovaná identita a sociálne prihlásenie, federácia používateľov, klientske adaptéry, správcovská konzola a konzola na správu účtov.
Základné funkcie podporované Keycloak:
- Single-Sign On a Single-Sign Out pre aplikácie prehliadača.
- Podpora OpenID/OAuth 2.0/SAML.
- Identity Brokering – autentifikácia pomocou externých poskytovateľov identity OpenID Connect alebo SAML.
- Sociálne prihlásenie – podpora Google, GitHub, Facebook, Twitter pre identifikáciu používateľa.
- Federácia používateľov – synchronizácia používateľov zo serverov LDAP a Active Directory a iných poskytovateľov identity.
- Kerberos bridge - použitie Kerberos servera na automatickú autentifikáciu užívateľa.
- Admin Console – pre jednotnú správu nastavení a možností riešenia cez web.
- Account Management Console - pre samosprávu užívateľského profilu.
- Prispôsobenie riešenia na základe firemnej identity spoločnosti.
- 2FA Authentication – podpora TOTP/HOTP pomocou Google Authenticator alebo FreeOTP.
- Prihlasovacie toky - je možná samoregistrácia používateľa, obnovenie a reset hesla a iné.
- Správa relácií – správcovia môžu spravovať relácie používateľov z jedného bodu.
- Token Mappers - viazanie užívateľských atribútov, rolí a iných požadovaných atribútov na tokeny.
- Flexibilná správa politík prostredníctvom sféry, aplikácie a používateľov.
- Podpora CORS – Klientske adaptéry majú vstavanú podporu CORS.
- Rozhrania poskytovateľa služieb (SPI) – veľké množstvo rozhraní SPI, ktoré vám umožňujú prispôsobiť rôzne aspekty servera: toky autentifikácie, poskytovatelia identity, mapovanie protokolov a ďalšie.
- Klientske adaptéry pre aplikácie JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Podpora pre prácu s rôznymi aplikáciami, ktoré podporujú knižnicu OpenID Connect Relying Party alebo knižnicu poskytovateľa služieb SAML 2.0.
- Rozšíriteľné pomocou pluginov.
Pre procesy CI / CD, ako aj automatizáciu procesov správy v Keycloak je možné použiť REST API / JAVA API. Dokumentácia je dostupná elektronicky:
REST API
Java API
Poskytovatelia podnikovej identity (on-premise)
Schopnosť overovať používateľov prostredníctvom služieb federácie používateľov.
Je možné použiť aj pass-through autentizáciu – ak sa používatelia autentifikujú voči pracovným staniciam s Kerberos (LDAP alebo AD), potom môžu byť automaticky autentifikovaní na Keycloak bez toho, aby museli znova zadávať svoje používateľské meno a heslo.
Na autentifikáciu a ďalšiu autorizáciu používateľov je možné použiť relačný DBMS, ktorý je najvhodnejší pre vývojové prostredia, keďže nezahŕňa zdĺhavé nastavovanie a integráciu v počiatočných fázach projektov. V predvolenom nastavení Keycloak používa vstavaný DBMS na ukladanie nastavení a používateľských údajov.
Zoznam podporovaných DBMS je rozsiahly a zahŕňa: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle a ďalšie. Zatiaľ najviac testované sú Oracle 12C Release1 RAC a Galera 3.12 cluster pre MariaDB 10.1.19.
Poskytovatelia identity – sociálne prihlásenie
Je možné použiť prihlásenie zo sociálnych sietí. Ak chcete aktivovať možnosť overovania používateľov, použite správcovskú konzolu Keycloack. Zmeny v kóde aplikácie nie sú potrebné a táto funkcia je k dispozícii hneď po vybalení a možno ju aktivovať v ktorejkoľvek fáze projektu.
Na autentifikáciu používateľa je možné použiť poskytovateľov OpenID/SAML Identity.
Typické autorizačné scenáre využívajúce OAuth2 v Keycloak
Tok autorizačného kódu - používa sa s aplikáciami na strane servera. Jeden z najbežnejších typov autorizačných povolení, pretože je vhodný pre serverové aplikácie, kde zdrojový kód aplikácie a klientske údaje nie sú dostupné pre cudzincov. Proces je v tomto prípade založený na presmerovaní. Aplikácia musí byť schopná komunikovať s užívateľským agentom (user-agent), ako je napríklad webový prehliadač, aby mohla prijímať autorizačné kódy API presmerované cez užívateľského agenta.
implicitný tok - používajú mobilné alebo webové aplikácie (aplikácie bežiace na zariadení používateľa).
Typ povolenia implicitnej autorizácie používajú mobilné a webové aplikácie, kde nemožno zaručiť dôvernosť klienta. Implicitný typ povolenia využíva aj presmerovanie užívateľského agenta, pričom prístupový token sa odovzdá užívateľskému agentovi na ďalšie použitie v aplikácii. Tým sa token sprístupní používateľovi a ďalším aplikáciám v zariadení používateľa. Tento typ autorizačného povolenia neoveruje identitu aplikácie a samotný proces sa spolieha na presmerovanie URL (predtým zaregistrované v službe).
Implicitný tok nepodporuje obnovovacie tokeny prístupového tokenu.
Tok udeľovania poverení klienta — používajú sa, keď aplikácia pristupuje k API. Tento typ autorizačného povolenia sa zvyčajne používa na interakcie server-server, ktoré sa musia vykonávať na pozadí bez bezprostrednej interakcie používateľa. Tok udeľovania poverení klienta umožňuje webovej službe (dôvernému klientovi) používať svoje vlastné poverenia namiesto toho, aby sa pri volaní inej webovej služby vydávala za používateľa na overenie. Pre vyššiu úroveň zabezpečenia je možné, aby volajúca služba použila ako poverenie certifikát (namiesto zdieľaného tajomstva).
Špecifikácia OAuth2 je opísaná v
Token JWT a jeho výhody
JWT (JSON Web Token) je otvorený štandard (), ktorý definuje kompaktný a samostatný spôsob na bezpečný prenos informácií medzi stranami ako objekt JSON.
Podľa štandardu sa token skladá z troch častí vo formáte base-64, oddelených bodkami. Prvá časť sa nazýva hlavička, ktorá obsahuje typ tokenu a názov hashovacieho algoritmu na získanie digitálneho podpisu. V druhej časti sú uložené základné informácie (používateľ, atribúty atď.). Treťou časťou je digitálny podpis.
. .
Nikdy neukladajte token vo svojej databáze. Pretože platný token je ekvivalentný heslu, uloženie tokenu je ako uloženie hesla vo forme čistého textu.
Prístupový token je token, ktorý poskytuje svojmu vlastníkovi prístup k zabezpečeným zdrojom servera. Zvyčajne má krátku životnosť a môže obsahovať ďalšie informácie, ako je IP adresa strany žiadajúcej o token.
Obnoviť token je token, ktorý umožňuje klientom požiadať o nové prístupové tokeny po uplynutí ich životnosti. Tieto tokeny sa zvyčajne vydávajú na dlhé obdobie.
Hlavné výhody použitia v architektúre mikroslužieb:
- Možnosť prístupu k rôznym aplikáciám a službám prostredníctvom jednorazovej autentifikácie.
- Pri absencii množstva požadovaných atribútov v užívateľskom profile je možné ho obohatiť o dáta, ktoré je možné pridávať do užitočného zaťaženia, vrátane automatizovaných a on-the-fly.
- Nie je potrebné ukladať informácie o aktívnych reláciách, serverová aplikácia potrebuje iba overiť podpis.
- Flexibilnejšie riadenie prístupu prostredníctvom ďalších atribútov v užitočnom zaťažení.
- Použitie tokenového podpisu pre hlavičku a užitočné zaťaženie zvyšuje bezpečnosť riešenia ako celku.
JWT token – zloženie
Titul - hlavička štandardne obsahuje iba typ tokenu a algoritmus použitý na šifrovanie.
Typ tokenu je uložený v kľúči „typ“. Kľúč „type“ sa v JWT ignoruje. Ak je prítomný kľúč „typ“, jeho hodnota musí byť JWT, čo znamená, že tento objekt je webový token JSON.
Druhý kľúč „alg“ definuje algoritmus použitý na šifrovanie tokenu. Predvolene by mal byť nastavený na HS256. Hlavička je zakódovaná v base64.
{ "alg": "HS256", "type": "JWT"}
užitočné zaťaženie (obsah) - užitočné zaťaženie ukladá všetky informácie, ktoré je potrebné skontrolovať. Každý kľúč v užitočnom zaťažení je známy ako „nárok“. Napríklad do aplikácie môžete vstúpiť iba pozvánkou (uzavretá promo akcia). Keď chceme niekoho pozvať na účasť, pošleme mu pozývací list. Je dôležité skontrolovať, či e-mailová adresa patrí osobe, ktorá prijíma pozvanie, preto túto adresu zahrnieme do užitočného obsahu, preto ju uložíme do kľúča „e-mail“
{ "e-mail": "[chránené e-mailom]"}
Kľúče v užitočnom zaťažení môžu byť ľubovoľné. Existuje však niekoľko rezervovaných:
- iss (Essuer) – Identifikuje aplikáciu, z ktorej sa token odosiela.
- sub (Subject) - definuje predmet tokenu.
- aud (Audience) je pole reťazcov alebo URI, v ktorých sa rozlišujú malé a veľké písmená, čo je zoznam príjemcov tohto tokenu. Keď prijímajúca strana dostane JWT s daným kľúčom, musí skontrolovať svoju prítomnosť v príjemcoch – inak token ignorovať.
- exp (čas platnosti) – Označuje, kedy vyprší platnosť tokenu. Štandard JWT vyžaduje, aby všetky jeho implementácie odmietli tokeny, ktorých platnosť vypršala. Kľúč exp musí byť časová pečiatka vo formáte unix.
- nbf (Not Before) je čas v unixovom formáte, ktorý určuje moment, kedy sa token stane platným.
- iat (Vydané v) – Tento kľúč predstavuje čas vydania tokenu a možno ho použiť na určenie veku JWT. Kľúč iat musí byť časová pečiatka vo formáte unix.
- Jti (JWT ID) — reťazec, ktorý definuje jedinečný identifikátor tohto tokenu, pričom sa rozlišujú malé a veľké písmená.
Je dôležité pochopiť, že užitočné zaťaženie sa neprenáša v šifrovanej forme (hoci tokeny môžu byť vnorené a potom je možné prenášať šifrované údaje). Preto nemôže uchovávať žiadne tajné informácie. Rovnako ako hlavička, užitočné zaťaženie je zakódované v base64.
podpis - keď máme titul a užitočné zaťaženie, vieme vypočítať podpis.
Base64-encoded: hlavička a užitočné zaťaženie sú prevzaté, sú spojené do reťazca cez bodku. Potom sa tento reťazec a tajný kľúč vložia do šifrovacieho algoritmu špecifikovaného v hlavičke (kľúč "alg"). Kľúčom môže byť ľubovoľný reťazec. Najvýhodnejšie budú dlhšie šnúrky, pretože ich naberanie bude trvať dlhšie.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Vybudovanie architektúry klastra s podporou zlyhania kľúča
Pri použití jedného klastra pre všetky projekty sú zvýšené požiadavky na riešenie SSO. Pri malom počte projektov nie sú tieto požiadavky tak výrazné pre všetky projekty, avšak s nárastom počtu používateľov a integrácií rastú požiadavky na dostupnosť a výkon.
Zvýšenie rizika zlyhania jediného SSO zvyšuje požiadavky na architektúru riešenia a metódy používané pre redundantné komponenty a vedie k veľmi prísnej SLA. V tomto ohľade majú projekty častejšie počas vývoja alebo počiatočných fáz implementácie riešení svoju vlastnú infraštruktúru, ktorá nie je odolná voči chybám. Ako vývoj napreduje, je potrebné stanoviť príležitosti pre rozvoj a škálovanie. Najflexibilnejšie je vybudovať klaster prepnutia pri zlyhaní pomocou virtualizácie kontajnerov alebo hybridného prístupu.
Pre prácu v klastrových režimoch Aktívny/Aktívny a Aktívny/Pasívny je potrebné zabezpečiť konzistentnosť údajov v relačnej databáze – oba databázové uzly musia byť synchrónne replikované medzi rôznymi geograficky distribuovanými dátovými centrami.
Najjednoduchší príklad inštalácie odolnej voči chybám.
Aké sú výhody používania jedného klastra:
- Vysoká dostupnosť a výkon.
- Podpora prevádzkových režimov: Aktívny / Aktívny, Aktívny / Pasívny.
- Schopnosť dynamicky škálovať – pri použití virtualizácie kontajnerov.
- Možnosť centralizovaného riadenia a monitorovania.
- Jednotný prístup k identifikácii/autentifikácii/autorizácii používateľov v projektoch.
- Transparentnejšia interakcia medzi rôznymi projektmi bez zapojenia používateľov.
- Možnosť opätovného použitia tokenu JWT v rôznych projektoch.
- Jediný bod dôvery.
- Rýchlejšie spúšťanie projektov pomocou mikroslužieb/virtualizácie kontajnerov (nie je potrebné zdvíhať a konfigurovať ďalšie komponenty).
- Komerčnú podporu je možné zakúpiť od predajcu.
Na čo sa zamerať pri plánovaní klastra
DBMS
Keycloak používa systém správy databáz na ukladanie: realmov, klientov, používateľov atď.
Je podporovaná široká škála DBMS: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak prichádza s vlastnou vstavanou relačná databázou. Odporúča sa na použitie v nenáročných prostrediach, ako sú vývojové prostredia.
Ak chcete pracovať v režimoch aktívneho/aktívneho klastra a aktívneho/pasívneho klastra, je potrebná konzistentnosť údajov v relačnej databáze a oba uzly databázového klastra sa synchrónne replikujú medzi údajovými centrami.
Distribuovaná vyrovnávacia pamäť (Infinspan)
Aby klaster správne fungoval, je potrebná dodatočná synchronizácia nasledujúcich typov vyrovnávacích pamätí pomocou JBoss Data Grid:
Autentifikačné relácie – slúžia na ukladanie údajov pri autentifikácii konkrétneho používateľa. Požiadavky z tejto vyrovnávacej pamäte zvyčajne zahŕňajú iba prehliadač a server Keycloak, nie aplikáciu.
Tokeny akcií sa používajú pre scenáre, kde používateľ potrebuje potvrdiť akciu asynchrónne (prostredníctvom e-mailu). Napríklad počas toku zabudnutia hesla sa vyrovnávacia pamäť ActionTokens Infinispan používa na sledovanie metadát o priradených symboloch akcií, ktoré už boli použité, takže ju nemožno znova použiť.
Ukladanie do vyrovnávacej pamäte a zneplatnenie perzistentných údajov – používa sa na ukladanie perzistentných údajov do vyrovnávacej pamäte, aby sa predišlo zbytočným dopytom do databázy. Keď ktorýkoľvek server Keycloak aktualizuje údaje, všetky ostatné servery Keycloak vo všetkých dátových centrách o tom musia vedieť.
Práca – Používa sa iba na odosielanie neplatných správ medzi uzlami klastra a dátovými centrami.
Používateľské relácie – slúžia na ukladanie údajov o používateľských reláciách, ktoré sú platné počas trvania relácie prehľadávača používateľa. Cache musí spracovávať požiadavky HTTP od koncového používateľa a aplikácie.
Ochrana hrubou silou – slúži na sledovanie údajov o neúspešných prihláseniach.
Rozdelenie výkonu
Nástroj na vyvažovanie záťaže je jediným vstupným bodom pre maskovanie kľúčov a musí podporovať trvalé relácie.
Aplikačné servery
Používajú sa na riadenie interakcie komponentov medzi sebou a môžu byť virtualizované alebo kontajnerizované pomocou existujúcich automatizačných nástrojov a dynamického škálovania nástrojov na automatizáciu infraštruktúry. Najbežnejšie scenáre nasadenia v OpenShift, Kubernates, Rancher.
Týmto sa končí prvá časť – teoretická. V ďalšej sérii článkov budú analyzované príklady integrácií s rôznymi poskytovateľmi identity a príklady nastavení.
Zdroj: hab.com