Bár a nagyvállalatoknál, így az X5 Retail Group-nál is, a fejlődés során egyre több olyan projekttel találkozunk, ahol szükség van a felhasználók azonosítására. Idővel elengedhetetlenné válik a felhasználók zökkenőmentes átmenete egy alkalmazásból a másikba, így felmerül az igény egy központi Single-Sign-On (SSO) szerver használatára. De mi a teendő, ha olyan azonosítószolgáltatók, mint az AD vagy más hasonlók, amelyek nem rendelkeznek további attribútumokkal, már használatban vannak különböző projektekben? Ebben az esetben a „azonosítóbroke” rendszerek nyújtanak segítséget. A legfunkcionálisabb képviselői közé tartozik a Keycloak, a Gravitee Access management stb. A használati forgatókönyvek sokfélesége megfigyelhető: gépi interakció, felhasználói részvétel és egyebek. A megoldásnak rugalmasnak és skálázhatónak kell lennie, és képesnek kell lennie arra, hogy egyesítse az összes követelményt, amelyet jelenleg cégünknél az azonosítóbroke – Keycloak – biztosít.
A Keycloak egy nyílt forráskódú termék, amely az azonosításhoz és a hozzáférés-ellenőrzéshez készült, és a RedHat cég támogatja. Ez a cégnél az SSO-t használó termékek alapját képezi – RH-SSO.
Alapfogalmak
Mielőtt elkezdenénk foglalkozni a megoldásokkal és megközelítésekkel, tisztáznunk kell a kifejezéseket és a folyamatok sorrendjét:
Azonosítás — ez egy eljárás, amely során a szubjektumot az azonosítóján keresztül ismerjük fel (egyszerűbben szólva, ez a név, bejelentkezési név vagy szám meghatározása).
Hitelesítés — ez egy hitelesítési eljárás (a felhasználót jelszóval ellenőrzik, a levelet elektronikus aláírással ellenőrzik stb.)
Engedélyezés — ez a hozzáférés biztosítása valamilyen erőforráshoz (például egy elektronikus levélhez).
A Keycloak azonosítóbroke
Keycloak — ez egy nyílt forráskódú azonosítási és hozzáférés-vezérlési megoldás, amelyet olyan informatikai rendszerekhez terveztek, ahol mikroszerviz-architektúra mintázataként alkalmazhatók.
A Keycloak olyan funkciókat kínál, mint az egységes bejelentkezés (SSO), az azonosítóbroke és a közösségi bejelentkezés, a felhasználók szövetsége, a kliensadapterek, az adminisztrátori konzol és a felhasználói fiók kezelő konzol.
A Keycloak által támogatott alapfunkcionalitás:
- Single-Sign On és Single-Sign Out webböngészős alkalmazásokhoz.
- OpenID/OAuth 2.0/SAML támogatás.
- Identitás közvetítés – hitelesítés külső OpenID Connect vagy SAML azonosító szolgáltatókkal.
- Társadalmi bejelentkezés – a felhasználók azonosításának támogatása a Google, GitHub, Facebook, Twitter segítségével.
- Felhasználói federáció – felhasználók szinkronizálása LDAP és Active Directory szerverekről, valamint más azonosító szolgáltatókról.
- Kerberos-híd – a Kerberos szerver használata a felhasználók automatikus hitelesítésére.
- Adminisztrátori konzol – a megoldás beállításainak és paramétereinek egységes kezelése Weben keresztül.
- Fiókkezelési konzol – a felhasználói profil önálló kezelésére.
- A megoldás testreszabása a vállalat arculati elemei alapján.
- 2FA hitelesítés – TOTP/HOTP támogatás a Google Authenticator vagy FreeOTP révén.
- Bejelentkezési folyamatok – lehetséges a felhasználók önregisztrációja, jelszó helyreállítása és visszaállítása, és egyéb funkciók.
- Munkamenet-kezelés – az adminisztrátorok egyetlen pontból kezelhetik a felhasználói munkameneteket.
- Token-képzők – felhasználói attribútumok, szerepek és egyéb szükséges attribútumok hozzárendelése a tokenekhez.
- Rugalmas politika-kezelés realm, alkalmazás és felhasználók szerint.
- CORS támogatás – a kliensadapterek beépített CORS támogatással rendelkeznek.
- Szolgáltató interfészek (SPI) – számos SPI, amely lehetővé teszi a szerver működésének különböző aspektusainak konfigurálását: hitelesítési folyamatok, azonosító szolgáltatók, protokollok párosítása és sok más.
- JavaScript alkalmazások, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring kliensadapterei.
- Támogatás különböző alkalmazásokkal, amelyek OpenID Connect Relying Party könyvtárat vagy SAML 2.0 Szolgáltató könyvtárat használnak.
- Pluginok használatával történő bővíthetőség.
A CI/CD folyamatokhoz és a Keycloak kezelési folyamatainak automatizálásához REST API/JAVA API használható. A dokumentáció elektronikus formában elérhető:
REST API
JAVA API
Vállalati szintű azonosító szolgáltatók (On-Premise)
Felhasználók hitelesítésének lehetősége User Federation szolgáltatásokon keresztül.
Szintén alkalmazható a szintetikus hitelesítés – ha a felhasználók Kerberos (LDAP vagy AD) munkaállomásokon keresztül hitelesítik magukat, akkor automatikusan hitelesíthetők a Keycloak-on anélkül, hogy újra meg kellene adniuk felhasználónevüket és jelszavukat.
A felhasználók hitelesítéséhez és további engedélyezéséhez relációs adatbázis-kezelő rendszer használható, ami a fejlesztési környezetekben a legmegfelelőbb, mivel nem igényel hosszadalmas beállításokat és integrációkat a projektek korai fázisaiban. Alapértelmezés szerint a Keycloak beépített adatbázist használ a beállítások és a felhasználói adatok tárolására.
A támogatott adatbázisok listája széleskörű, és magában foglalja: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle és mások. Jelenleg a legjobban teszteltek az Oracle 12C Release1 RAC és a Galera 3.12 cluster a MariaDB 10.1.19-hez.
Az azonosító szolgáltatók — közösségi bejelentkezés
Lehetséges közösségi hálózatokból való bejelentkezés használata. Az a lehetőség, hogy a felhasználókat hitelesíteni lehessen, a Keycloak adminisztrátori konzolján aktiválható. Az alkalmazások kódjában nem szükséges változtatni, és ez a funkció "do-it-yourself" elérhető, bármely projektmegvalósítási fázisban aktiválható.
A felhasználók hitelesítéséhez OpenID/SAML azonosító szolgáltatók használata lehetséges.
A Keycloakban OAuth2 használatával történő engedélyezési forgatókönyvek típusa
Engedélyezési kód folyamat — szerveroldali alkalmazásokkal használatos. Ez az egyik legelterjedtebb engedélyezési típus, mivel jól illeszkedik a szerveroldali alkalmazásokhoz, ahol az alkalmazás forráskódja és az ügyféladatai nem hozzáférhetőek harmadik felek számára. Ez esetben a folyamat átirányításon (redirection) alapul. Az alkalmazásnak képesnek kell lennie interakcióba lépni a felhasználói ügynökkel (user-agent), például egy webböngészővel, hogy megszerezze a felhasználói ügynökön keresztül átirányított API engedélyezési kódokat.
Implicit folyamat — mobil vagy webböngésző alkalmazások (felhasználói eszközökön futó alkalmazások) használják.
Az implicit engedélyezési típus mobil- és webalkalmazásokban használatos, ahol az ügyfél adatainak védelme nem garantálható. Az implicit engedélyezési típus a felhasználói ügynök átirányítását is alkalmazza, amely során a hozzáférési token átkonvertálódik a felhasználói ügynöknek, hogy további felhasználásra kerüljön az alkalmazásban. Ez lehetővé teszi a token hozzáférését a felhasználó és más alkalmazások számára a felhasználó eszközén. Ebben az engedélyezési típusban az alkalmazás hitelesítése nem történik meg, a folyamat a korábban a szolgáltatásban regisztrált átirányítási URL-re támaszkodik.
Az implicit áramlás nem támogatja a hozzáférési token frissítő tokenjeit (refresh tokens).
Ügyféleszközök Hozzáférési Áramlás — az alkalmazás API-hoz való hozzáférésénél használatos. Ez az engedélyezési típus általában a 'szerver-szerver' interakciók során elterjedt, melyeknek a háttérben kell futniuk, anélkül, hogy azonnali felhasználói interakcióra lenne szükség. Az ügyféleszközök hozzáférési áramlása lehetővé teszi a webszolgáltatásnak (bizalmas kliens) a saját hitelesítő adatai használatát a felhasználó azonosítása helyett egy másik webszolgáltatás hitelesítéséhez. Magasabb biztonsági szint elérése érdekében a hívó szolgáltatás tanúsítványt (a közönséges titok helyett) használhat hitelesítő adatként.
Az OAuth2 specifikációja a következő címen található:
JWT token és előnyei
A JWT (JSON Web Token) egy nyílt szabvány (), amely egy kompakt és önálló módot határoz meg az információk biztonságos továbbítására a felek között JSON-objektum formájában.
A szabvány szerint a token három részből áll, base-64 formátumban, pontokkal elválasztva. Az első rész a fejléc (header), amely tartalmazza a token típusát és a digitális aláírás megszerzéséhez szükséges hash algoritmus nevét. A második rész a főinformációt tárolja (felhasználó, attribútumok stb.). A harmadik rész a digitális aláírás.
..
Soha ne tárolja a tokent az adatbázisában. Mert egy érvényes token egyenértékű egy jelszóval; a token tárolása olyan, mintha a jelszót nyílt formában tárolná.
Hozzáférési token — ez egy token, amely hozzáférést biztosít a tulajdonosának a szerver védett erőforrásaihoz. Általában rövid élettartammal rendelkezik, és tartalmazhat további információkat, például a kérő IP-címét.
Frissítő token — ez egy token, amely lehetővé teszi a kliensek számára, hogy új access tokeneket kérjenek az élettartamuk lejárta után. Ezek a tokenek általában hosszabb időre kerülnek kiadásra.
A mikroszolgáltatás-architektúrában való alkalmazás fő előnyei:
- Lehetőség különböző alkalmazások és szolgáltatások elérésére egyszeri hitelesítéssel.
- Ha a felhasználói profilban hiányoznak bizonyos szükséges attribútumok, az adatok kiegészíthetők, beleértve az automatizált és "valós idejű" hozzáadást is.
- Nincs szükség az aktív munkamenetek információinak tárolására, a kiszolgáló alkalmazásnak csak a aláírást kell ellenőriznie.
- Rugalmasabb hozzáférés-kezelés a hasznos terhelésben szereplő további attribútumok révén.
- A token aláírásának alkalmazása a fejlécben és a hasznos terhelésben növeli az egész megoldás biztonságát.
JWT token — összetétel
A fejléc — alapértelmezetten, a fejléc csak a token típusát és a titkosításhoz használt algoritmust tartalmazza.
A token típusa a "typ" kulcsban tárolódik. A "typ" kulcsot a JWT nem veszi figyelembe. Ha a "typ" kulcs jelen van, az értékének JWT-nek kell lennie, hogy jelezze, hogy ez az objektum egy JSON Web Token.
A második "alg" kulcs határozza meg a token titkosításához használt algoritmust. Alapértelmezetten ezt HS256-ra kell állítani. A fejléc base64 kódolva van.
{ "alg": "HS256", "typ": "JWT"}
Payload (tartalom) — a hasznos terhelésben bármilyen információt tárolunk, amelyet ellenőrizni kell. Minden kulcs a hasznos terhelésben "állításnak" nevezett elem. Például, a belépéshez a rendszerbe csak meghívás szükséges (zártkörű promóció). Amikor valakit szeretnénk meghívni, emailt küldünk neki a meghívóval. Fontos ellenőrizni, hogy az email cím az a személyé, aki elfogadja a meghívást, ezért ezt a címet beépítjük a hasznos terhelésbe, a "e-mail" kulcsban tárolva.
{ "email": "example@x5.ru" }
A payloadban a kulcsok önkényesek lehetnek. Azonban van néhány fenntartott:
- iss (Issuer) — meghatározza az alkalmazást, amelyből a token elküldésre kerül.
- sub (Téma) — meghatározza a token témáját.
- aud (Célcsoport) – egy érzékeny nagybetű-re kisbetűre sorokból álló tömb vagy URI, amely a token címzettjeinek listáját képezi. Amikor a címzett megkap egy JWT-t ezzel a kulccsal, ellenőriznie kell, hogy benne van-e a címzettek között — különben figyelmen kívül kell hagynia a tokent.
- exp (Lejárati idő) — megadja, mikor jár le a token érvényessége. A JWT szabvány megköveteli, hogy minden megvalósítás esetén az lejárt tokeneket el kell utasítani. Az exp kulcsnak unix időbélyegnek kell lennie.
- nbf (Nem korábban) — ez egy unix időbélyeg, amely meghatározza azt az időpontot, amikor a token érvényes lesz.
- iat (Kibocsátás ideje) — ez a kulcs azt az időt jelöli, amikor a tokent kiadták, és felhasználható a JWT korának meghatározásához. Az iat kulcsnak unix időbélyegnek kell lennie.
- Jti (JWT azonosító) — egy karakterlánc, amely meghatározza ennek a tokennek az egyedi azonosítóját nagybetűs érzékenységgel.
Fontos megérteni, hogy a hasznos adatokat nem titkosítva továbbítják (bár a tokenek lehetnek beágyazottak, és ekkor titkosított adatokat is lehet továbbítani). Ezért ebben nem tárolható semmilyen titkos információ. A hasznos adatokat, akárcsak a fejlécet, base64 kódolással írják.
Aláírás — amikor megvan a fejléc és a payload, kiszámítható az aláírás.
A base64 kódoltakat használják: a fejlécet és a payloadot, amelyek egy ponton keresztül összevonásra kerülnek. Ezután ez a sztring és a titkos kulcs bemenetet képez a fejlécben megadott titkosítási algoritmusnak ("alg" kulcs). A kulcs lehet bármilyen karakterlánc. A hosszabb karakterláncok a legjobbak, mivel hosszabb időbe telik a kitalálásuk.
{"alg":"RSA1_5", "payload":"A128CBC-HS256"}
A Keycloak megbízható klaszterének architektúrája
Egyetlen klaszter használata az összes projekthez magasabb követelményeket támaszt az SSO megoldásával szemben. Amikor a projektek száma alacsony, ezek a követelmények nem érződnek olyan erőteljesen, de a felhasználók és integrációk számának növekedésével a rendelkezésre állásra és teljesítményre vonatkozó követelmények emelkednek.
A megnövekedett SSO meghibásodási kockázatok emelik az architektúra és az alkalmazott komponensmentő módszerek követelményeit, és nagyon szigorú SLA-hoz vezetnek. Ennek következményeként a megoldások fejlesztése vagy korai bevezetési szakaszában a projektek saját, nem hibatűrő infrastruktúrát igényelnek. A fejlődés során szükséges a fejlesztési és skálázási lehetőségek beépítése. A hibatűrő klaszter legflexibilisebb felépítése konténer virtualizációval vagy hibrid megközelítéssel történik.
Az Active/Active és Active/Passive klaszter üzemeltetéséhez biztosítani kell az adatok konzisztenciáját a relációs adatbázisban — mindkét adatbázis csomópontot szinkronosan kell replikálni a különböző földrajzilag elosztott adatközpontok között.
A hibatűrő telepítés legegyszerűbb példája.
Milyen előnyöket nyújt egyetlen klaszter használata:
- Magas rendelkezésre állás és teljesítmény.
- Támogatja a működési módokat: Active/Active, Active/Passive.
- Dinamikus skálázás lehetősége — konténer virtualizáció alkalmazásakor.
- Központosított kezelési és monitorozási lehetőség.
- Egységes megközelítés az azonosítás / hitelesítés / felhasználói jogosultságok kezelésére a projektekben.
- Átláthatóbb együttműködés különböző projektek között felhasználói beavatkozás nélkül.
- A JWT tokenek több projektben való újrahasználásának lehetősége.
- Egységes bizalmi pont.
- Gyorsabb projektindítás mikroszolgáltatások / konténer virtualizáció használatával (nem szükséges további összetevők telepítése és beállítása).
- Lehetséges kereskedelmi támogatás vásárlása a gyártótól.
Mire érdemes figyelni a klaszter tervezésekor
DBMS
A Keycloak DBMS kezelőrendszert használ a következők tárolására: realms, clients, users stb.
Széles spektrumú DBMS-ek támogatottak: MS SQL, Oracle, MySQL, PostgreSQL. A Keycloak saját beépített relációs adatbázissal kerül forgalomba. Ajánlott nem túlterhelt környezetekben használni – mint például fejlesztési környezetekben.
Az Active/Active és Active/Passive klaszter üzemeltetéséhez biztosítani kell az adatok konzisztenciáját a relációs adatbázisban, és a klaszter mindkét csomópontjának szinkron módon kell replikálnia az adatközpontok között.
Elosztott gyorsítótár (Infinispan)
A klaszter megfelelő működéséhez szükséges a következő típusú gyorsítótárak további szinkronizálása a JBoss Data Grid használatával:
Hitelesítési munkamenetek — az adott felhasználó hitelesítési adatainak megőrzésére használják. Ennek a gyorsítótárnak a kérdései általában csak a böngészőt és a Keycloak kiszolgálót tartalmazzák, a nem alkalmazás részét.
Akciótokenek — olyan forgatókönyvekhez használatosak, amikor a felhasználónak szüksége van egy művelet megerősítésére aszinkron módon (e-mailben). Például a jelszó-visszaállítási folyamat során a gyorsítótár actionTokens Infinispan módot követi az akciókhoz kapcsolódó metaadatok nyomon követésében, amelyek már felhasználásra kerültek, ezért nem lehet őket újra felhasználni.
Tartós adatok gyorsítótárazása és érvénytelenítése – a tartós adatok gyorsítótárazására használják, hogy elkerüljék a szükségtelen adatbázis-kéréseket. Amikor bármely Keycloak kiszolgáló frissíti az adatokat, az összes többi Keycloak kiszolgálónak az összes adatközpontban tudnia kell erről.
Munka — csak a gyorsítótár invalidációs értesítéseinek küldésére szolgál a klaszter és az adatközpontok között.
Felhasználói munkamenetek — a felhasználói munkamenet adataik megőrzésére használják, amelyek érvényesek a felhasználó böngészési munkamenete alatt. A gyorsítótárnak kezelnie kell a végfelhasználói és alkalmazási HTTP-kéréseket.
Bruteforce védelem — az azonosítatlan bejelentkezési kísérletek adatainak nyomon követésére használják.
A terheléselosztás
A terheléselosztó a Keycloak egyetlen belépési pontja, és támogatnia kell a sticky sessions-t.
Alkalmazás kiszolgálók
Az összetevők közötti interakciók ellenőrzésére használják, és virtualizálhatók vagy konténerizálhatók a meglévő automatizálási eszközökkel és infrastruktúra automatizálási dinamikus skálázásával. A leggyakoribb telepítési forgatókönyvek az OpenShift, Kubernates, Rancher.
Ezzel véget ért az első, elméleti rész. A következő ciklusokban különböző azonosító szolgáltatókkal végzett integrációs példákat és beállítási példákat fogunk áttekinteni.
Forrás: habr.com
