Bármely nagyvállalatnál sem kivétel ez alól az X5 Retail Group sem, hiszen fejlődése során nő a felhasználói jogosultságot igénylő projektek száma. Idővel a felhasználók zökkenőmentes átállására van szükség az egyik alkalmazásról a másikra, majd egyetlen egyszeri egyszeri (SSO) szerver használatára van szükség. De mi van akkor, ha az identitásszolgáltatókat, például az AD-t vagy másokat, amelyek nem rendelkeznek további attribútumokkal, már használják a különböző projektekben. A rendszerek egy osztálya, az úgynevezett "azonosító brókerek" fog segíteni. A legfunkcionálisabbak a képviselői, mint például a Keycloak, a Gravitee Access management stb. Leggyakrabban a felhasználási esetek eltérőek lehetnek: gépi interakció, felhasználói részvétel stb. és az ilyen megoldások cégünknek most van egy indikációs brókerje - Keycloak.
A Keycloak egy nyílt forráskódú identitás- és hozzáférés-felügyeleti termék, amelyet a RedHat tart fenn. Ez az alapja a cég termékeinek SSO - RH-SSO használatával.
Alapfogalmak
Mielőtt elkezdené a megoldásokkal és megközelítésekkel foglalkozni, döntse el a folyamatok feltételeit és sorrendjét:
azonosító egy eljárás egy alany felismerésére az azonosítója alapján (más szóval ez egy 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, a levelet elektronikus aláírással, stb.)
Meghatalmazás – hozzáférést biztosít egy erőforráshoz (például e-mailhez).
Keycloak Identity Broker
Kulcsköpeny egy nyílt forráskódú identitás- és hozzáférés-kezelési megoldás, amelyet olyan IS-ben való használatra terveztek, ahol mikroszolgáltatási architektúra minták használhatók.
A Keycloak olyan funkciókat kínál, mint az egyszeri bejelentkezés (SSO), közvetített identitás és közösségi bejelentkezés, felhasználói összevonás, ügyféladapterek, felügyeleti konzol és fiókkezelési konzol.
A Keycloak által támogatott alapvető funkciók:
- Egyszeri bejelentkezés és egyszeri kijelentkezés böngészőalkalmazásokhoz.
- OpenID/OAuth 2.0/SAML támogatás.
- Identity Brokering – hitelesítés külső OpenID Connect vagy SAML identitásszolgáltatók használatával.
- Közösségi bejelentkezés – Google, GitHub, Facebook, Twitter támogatás a felhasználó azonosításához.
- Felhasználói összevonás – a felhasználók szinkronizálása LDAP és Active Directory kiszolgálókról és más identitásszolgáltatókról.
- Kerberos-híd – Kerberos-kiszolgáló használata az automatikus felhasználói hitelesítéshez.
- Felügyeleti konzol – a beállítások és megoldási lehetőségek egységes kezeléséhez az interneten keresztül.
- Fiókkezelő konzol – a felhasználói profil önálló kezeléséhez.
- A megoldás testreszabása a cég arculata alapján.
- 2FA hitelesítés – TOTP/HOTP támogatás a Google Authenticator vagy a FreeOTP használatával.
- Bejelentkezési folyamatok – a felhasználó önregisztrációja, jelszó-helyreállítás és visszaállítás, és egyéb lehetőségek is lehetségesek.
- Munkamenet-kezelés – a rendszergazdák egyetlen pontról kezelhetik a felhasználói munkameneteket.
- Token Mappers – felhasználói attribútumok, szerepkörök és egyéb kötelező attribútumok hozzárendelése a tokenekhez.
- Rugalmas házirend-kezelés a tartományon, az alkalmazásokon és a felhasználókon keresztül.
- CORS-támogatás – Az ügyféladapterek beépített CORS-támogatással rendelkeznek.
- Service Provider Interfaces (SPI) – számos SPI, amely lehetővé teszi a szerver különböző aspektusainak konfigurálását: hitelesítési folyamatok, identitásszolgáltatók, protokollleképezés és még sok más.
- Kliens adapterek JavaScript alkalmazásokhoz, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Támogatás az OpenID Connect Relying Party könyvtárat vagy a SAML 2.0 Service Provider Library-t támogató különféle alkalmazásokkal.
- Bővíthető pluginekkel.
A CI / CD folyamatokhoz, valamint a Keycloak kezelési folyamatainak automatizálásához a REST API / JAVA API használható. A dokumentáció elektronikus formában elérhető:
REST API
JAVA API
Vállalati identitásszolgáltatók (helyszíni)
Lehetőség a felhasználók hitelesítésére a Felhasználó-összevonási szolgáltatásokon keresztül.
Átmenő hitelesítés is használható - ha a felhasználók Kerberos (LDAP vagy AD) munkaállomásokon hitelesítenek, akkor automatikusan hitelesíthetők a Keycloak-ban anélkül, hogy újra meg kellene adniuk felhasználónevüket és jelszavukat.
A felhasználók hitelesítésére és további engedélyezésére lehetőség van egy relációs DBMS használatára, amely leginkább a fejlesztői környezetekben alkalmazható, mivel nem igényel hosszadalmas beállításokat és integrációkat a projektek korai szakaszában. Alapértelmezés szerint a Keycloak beépített DBMS-t használ a beállítások és a felhasználói adatok tárolására.
A támogatott DBMS-ek listája kiterjedt, és a következőket tartalmazza: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle és mások. A leginkább tesztelt jelenleg az Oracle 12C Release1 RAC és a Galera 3.12 fürt a MariaDB 10.1.19-hez.
Identitásszolgáltatók – közösségi bejelentkezés
Lehetőség van a közösségi hálózatokból történő bejelentkezés használatára. A felhasználók hitelesítésének engedélyezéséhez használja a Keycloack felügyeleti konzolt. Az alkalmazás kódjának módosítására nincs szükség, és ez a funkció már a dobozból is elérhető, és a projekt bármely szakaszában aktiválható.
Lehetőség van OpenID/SAML Identity-szolgáltatók használatára a felhasználói hitelesítéshez.
Tipikus engedélyezési forgatókönyvek a Keycloak OAuth2 használatával
Engedélyezési kódfolyam - szerveroldali alkalmazásokkal használható. Az egyik legelterjedtebb engedélyezési típus, mert kiválóan alkalmas olyan szerveralkalmazásokhoz, ahol az alkalmazás forráskódja és kliens adatai nem érhetők el kívülállók számára. A folyamat ebben az esetben az átirányításon alapul. Az alkalmazásnak képesnek kell lennie kommunikálni egy felhasználói ügynökkel (felhasználói ügynök), például egy webböngészővel, hogy megkapja a felhasználói ügynökön keresztül átirányított API engedélyezési kódokat.
implicit áramlás - mobil vagy webes alkalmazások (a felhasználó eszközén futó alkalmazások) használják.
Az implicit engedélyezési engedélytípust olyan mobil- és webalkalmazások használják, ahol az ügyfelek adatvédelme nem garantálható. Az implicit engedélytípus felhasználói ügynök átirányítást is használ, ahol a hozzáférési jogkivonat átadásra kerül a felhasználói ügynöknek az alkalmazásban való későbbi felhasználás céljából. Ez elérhetővé teszi a tokent a felhasználó és a felhasználó eszközén lévő egyéb alkalmazások számára. Ez a típusú engedélyezési engedély nem hitelesíti az alkalmazás azonosságát, és maga a folyamat az átirányítási URL-re támaszkodik (amely korábban regisztrált a szolgáltatásnál).
Az Implicit Flow nem támogatja a hozzáférési token frissítési tokeneket.
Ügyfél hitelesítő adatainak engedélyezési folyamata — akkor használatosak, amikor az alkalmazás hozzáfér az API-hoz. Ezt a típusú engedélyezési engedélyt általában a kiszolgálók közötti interakciókhoz használják, amelyeket a háttérben kell végrehajtani azonnali felhasználói beavatkozás nélkül. Az ügyfél-hitelesítési adatok engedélyezési folyamata lehetővé teszi a webszolgáltatás (bizalmas ügyfél) számára, hogy saját hitelesítő adatait használja, ahelyett, hogy egy másik webszolgáltatás hívásakor hitelesítené a felhasználót. A magasabb szintű biztonság érdekében lehetőség van arra, hogy a hívó szolgáltatás tanúsítványt használjon (megosztott titok helyett) hitelesítő adatként.
Az OAuth2 specifikáció leírása a
JWT token és előnyei
A JWT (JSON Web Token) egy nyílt szabvány (), amely egy kompakt és önálló módszert határoz meg a felek közötti biztonságos információátvitelhez JSON-objektumként.
A szabvány szerint a token alap-64 formátumú három részből áll, amelyeket pontok választanak el egymástól. Az első részt fejlécnek nevezzük, 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 az alapvető információkat (felhasználó, attribútumok stb.) tárolja. A harmadik rész a digitális aláírás.
. .
Soha ne tároljon tokent a DB-ben. Mivel az érvényes token egyenértékű a jelszóval, a token tárolása olyan, mintha a jelszót tiszta szövegben tárolná.
Hozzáférési token egy token, amely hozzáférést biztosít tulajdonosának a biztonságos szerver erőforrásokhoz. Általában rövid élettartamú, és további információkat tartalmazhat, például a tokent kérő fél IP-címét.
Token frissítése egy token, amely lehetővé teszi az ügyfelek számára, hogy új hozzáférési tokeneket kérjenek, miután élettartamuk lejárt. Ezeket a tokeneket általában hosszú időre adják ki.
A mikroszolgáltatási architektúrában való használat fő előnyei:
- Különféle alkalmazások és szolgáltatások elérése egyszeri hitelesítéssel.
- Számos kötelező attribútum hiányában a felhasználói profilban lehetőség van a rakományhoz hozzáadható adatokkal gazdagítani, akár automatikusan és menet közben is.
- Nincs szükség információ tárolására az aktív munkamenetekről, a szerveralkalmazásnak csak az aláírást kell ellenőriznie.
- Rugalmasabb hozzáférés-szabályozás a rakományban lévő további attribútumokkal.
- A fejléchez és a hasznos adathoz való token aláírás használata növeli a teljes megoldás biztonságát.
JWT token - kompozíció
Cím - alapértelmezés szerint a fejléc csak a token típusát és a titkosításhoz használt algoritmust tartalmazza.
A token típusát a "typ" kulcs tárolja. A 'type' kulcsot figyelmen kívül hagyja a JWT. Ha a "typ" kulcs jelen van, akkor annak értékének JWT-nek kell lennie, hogy jelezze, hogy ez az objektum egy JSON Web Token.
A második "alg" kulcs a token titkosításához használt algoritmust határozza meg. Alapértelmezés szerint HS256-ra kell állítani. A fejléc base64-ben van kódolva.
{ "alg": "HS256", "typ": "JWT"}
hasznos teher (tartalom) - a rakomány tárol minden olyan információt, amelyet ellenőrizni kell. A rakományban lévő minden kulcsot "igénylésnek" neveznek. A pályázatba például csak meghívással lehet belépni (zárt promóció). Ha meg akarunk hívni valakit, küldünk neki egy meghívó levelet. Fontos ellenőrizni, hogy az e-mail cím a meghívót elfogadó személyé-e, ezért ezt a címet beletesszük a rakományba, ehhez tároljuk az "e-mail" kulcsban
{ "e-mail": "[e-mail védett]"}
A hasznos teher kulcsai tetszőlegesek lehetnek. Van azonban néhány fenntartva:
- iss (Kibocsátó) – Azonosítja azt az alkalmazást, amelyből a tokent küldik.
- sub (Subject) - meghatározza a token tárgyát.
- Az aud (Audience) a kis- és nagybetűket megkülönböztető karakterláncok vagy URI-k tömbje, amely a token címzettjeinek listája. Amikor a fogadó fél JWT-t kap az adott kulccsal, ellenőriznie kell saját jelenlétét a címzettekben - ellenkező esetben figyelmen kívül hagyja a tokent.
- exp (lejárati idő) – Azt jelzi, amikor a token lejár. A JWT szabvány megköveteli, hogy minden implementációja elutasítsa a lejárt jogkivonatokat. Az exp kulcsnak unix formátumú időbélyegzőnek kell lennie.
- Az nbf (Not Before) egy unix formátumú idő, amely meghatározza azt a pillanatot, amikor a token érvényessé válik.
- iat (Kiadva) – Ez a kulcs a token kiadásának idejét jelöli, és felhasználható a JWT életkorának meghatározására. Az iat kulcsnak unix formátumú időbélyegzőnek kell lennie.
- Jti (JWT ID) – karakterlánc, amely meghatározza ennek a tokennek az egyedi azonosítóját, megkülönbözteti a kis- és nagybetűket.
Fontos megérteni, hogy a hasznos teher nem titkosítva kerül továbbításra (bár a tokenek beágyazhatók, és akkor lehetséges titkosított adatok továbbítása). Ezért nem tárolhat benne titkos információkat. A fejléchez hasonlóan a hasznos terhelés is base64 kódolású.
aláírás - ha megvan a cím és a terhelés, ki tudjuk számítani az aláírást.
Base64 kódolású: a fejlécet és a hasznos terhelést veszik, és egy ponton keresztül egy karakterláncba egyesítik. Ezután ez a karakterlánc és a titkos kulcs bekerül a fejlécben megadott titkosítási algoritmusba ("alg" kulcs). A kulcs bármilyen karakterlánc lehet. A hosszabb karakterláncok a legelőnyösebbek, mivel hosszabb ideig tart a felvétel.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Keycloak feladatátvevő klaszter architektúra építése
Ha minden projekthez egyetlen fürtöt használ, megnövekednek a követelmények az egyszeri bejelentkezési megoldással szemben. Ha kicsi a projektek száma, ezek a követelmények nem minden projektnél jelentkeznek annyira, azonban a felhasználók és az integrációk számának növekedésével nőnek a rendelkezésre állás és a teljesítmény követelményei.
Az egyszeri egyszeri bejelentkezés meghibásodásának kockázatának növelése növeli a megoldási architektúra és a redundáns komponensekhez használt módszerek követelményeit, és nagyon szoros SLA-hoz vezet. E tekintetben a projektek gyakrabban a fejlesztés vagy a megoldások bevezetésének korai szakaszában rendelkeznek saját, nem hibatűrő infrastruktúrával. A fejlesztés előrehaladtával meg kell határozni a fejlesztési és méretezési lehetőségeket. A legrugalmasabb feladatátvételi fürt létrehozása konténervirtualizáció vagy hibrid megközelítés használatával.
Az Aktív/Aktív és az Aktív/Passzív fürt módban való munkához biztosítani kell az adatok konzisztenciáját a relációs adatbázisban – mindkét adatbázis-csomópontot szinkronban kell replikálni a különböző földrajzilag elosztott adatközpontok között.
A legegyszerűbb példa a hibatűrő telepítésre.
Melyek az egyetlen fürt használatának előnyei:
- Magas rendelkezésre állás és teljesítmény.
- Működési módok támogatása: Aktív / Aktív, Aktív / Passzív.
- Dinamikus skálázás lehetősége - konténervirtualizáció használatakor.
- Központosított irányítás és felügyelet lehetősége.
- Egységes megközelítés a felhasználók azonosítására/hitelesítésére/engedélyezésére a projektekben.
- Átláthatóbb interakció a különböző projektek között felhasználói beavatkozás nélkül.
- Lehetőség a JWT token újrafelhasználására különböző projektekben.
- Egyetlen bizalmi pont.
- A projektek gyorsabb elindítása mikroszolgáltatások/konténervirtualizáció segítségével (nincs szükség további összetevők emelésére és konfigurálására).
- Lehetőség van kereskedelmi támogatás vásárlására az eladótól.
Mit kell figyelembe venni a klaszter tervezésekor
DBMS
A Keycloak DBMS-kezelő rendszert használ a mentéshez: tartományok, ügyfelek, felhasználók stb.
A DBMS-ek széles skálája támogatott: MS SQL, Oracle, MySQL, PostgreSQL. A Keycloak saját beépített relációs adatbázissal rendelkezik. Használata kis igénybevételű környezetben, például fejlesztői környezetben javasolt.
Az Aktív/Aktív és az Aktív/Passzív fürt módban való működéshez a relációs adatbázisban az adatok konzisztenciája szükséges, és mindkét adatbázis-fürtcsomópont szinkronban replikálódik az adatközpontok között.
Elosztott gyorsítótár (Infinspan)
A fürt megfelelő működéséhez a következő típusú gyorsítótárak további szinkronizálása szükséges a JBoss Data Grid használatával:
Hitelesítési munkamenetek – adatok mentésére szolgálnak egy adott felhasználó hitelesítése során. Az ebből a gyorsítótárból érkező kérések általában csak a böngészőt és a Keycloak-kiszolgálót tartalmazzák, az alkalmazást nem.
Műveletjogkivonatok – olyan helyzetekben használatosak, amikor a felhasználónak aszinkron módon (e-mailben) kell megerősítenie egy műveletet. Például a jelszó elfelejtésének folyamata során az Infinispan actionTokens gyorsítótár a már használt kapcsolódó műveleti tokenek metaadatainak nyomon követésére szolgál, így azok nem használhatók fel újra.
A perzisztens adatok gyorsítótárazása és érvénytelenítése – a perzisztens adatok gyorsítótárazására szolgál, hogy elkerülje az adatbázisba irányuló szükségtelen lekérdezéseket. Amikor bármely Keycloak-kiszolgáló frissíti az adatokat, az összes többi Keycloak-szervernek tudnia kell róla az összes adatközpontban.
Munka – Csak érvénytelenítési üzenetek küldésére szolgál a fürtcsomópontok és az adatközpontok között.
Felhasználói munkamenetek – a felhasználói munkamenetek adatainak tárolására szolgál, amelyek a felhasználó böngészőjének munkamenete alatt érvényesek. A gyorsítótárnak fel kell dolgoznia a végfelhasználó és az alkalmazás HTTP-kéréseit.
Brute force védelem – a sikertelen bejelentkezésekkel kapcsolatos adatok nyomon követésére szolgál.
Terhelés elosztás
A terheléselosztó a keycloak egyetlen belépési pontja, és támogatnia kell a ragadós munkameneteket.
Alkalmazásszerverek
Az összetevők egymás közötti interakciójának vezérlésére szolgálnak, és virtualizálhatók vagy konténerbe helyezhetők a meglévő automatizálási eszközök és az infrastruktúra-automatizálási eszközök dinamikus skálázásával. A leggyakoribb telepítési forgatókönyvek az OpenShiftben, a Kubernatesben és a Rancherben.
Ezzel lezárul az első rész – az elméleti. A következő cikksorozatban a különböző azonosítási szolgáltatókkal való integráció példáit és a beállítások példáit tárgyaljuk.
Forrás: will.com