Avagy ne találjuk fel újra a spanyolviaszt minden alkalommal
Bevezetés
A legtöbb alkalmazásunk fejlesztése során felmerül az igény, hogy valamilyen identitáskezelő megoldás segítségével védjük az appban található adatokat, funkciókat. Az esetek többségében az ezzel kapcsolatos igények nagyon hasonlóak, a teljesség igénye nélkül ezek szoktak felmerülni:
- védjük a felhasználói adatokat
- legyen regisztráció, bejelentkezés, elfelejtett jelszó
- lehessen valamilyen social platformokkal regisztrálni / belépni
- tudja a kétfaktoros hitelesítést
- LDAP és AD kezelés lehetősége
- legyen jól személyre szabható
- legyen GDPR ready
Ezért felmértük a piacon található IdP (Identity Provider) megoldásokat és arra a következtetésre jutottunk, hogy a teljesen ingyenes, nyílt forráskódú Keycloak szoftver tökéletesen kielégíti azokat az igényeket, melyeket ügyfeleink általában megkövetelnek, és a technológiai stackünkbe is megfelelően illeszkedik (így ha egyedi fejlesztéssel szükséges bővíteni, az sem okoz problémát).
Most már 2. éve használjuk, és startup projektektől kezdve kormányzati projektekteken át, számos helyen bizonyította, hogy jól választottunk, így egy blogcikk keretében szeretnénk bemutatni, hogyan is működik a termék.
Keycloak
A Keycloak egy nyílt forráskódú szoftver, amely lehetővé teszi az egyszeri bejelentkezést (IdP) az Identity Management és az Access Management használatával modern alkalmazásokhoz és szolgáltatásokhoz. A szoftver Java nyelven íródott, alapértelmezés szerint támogatja az identitás szövetségi protokollokat: SAML v2 és OpenID Connect (OIDC) / OAuth2. Az Apache engedélyével rendelkezik, a Red Hat pedig támogatja.
Az eszköz célja, hogy megkönnyítse az alkalmazások és szolgáltatások védelmét alig, vagy egyáltalán nem titkosítva. Az IdP lehetővé teszi egy alkalmazás számára a hitelesítés átruházását.
Főbb jellemzői:
- Single-Sign On
- Standard Protokollok
OpenID Connect, OAuth 2.0, SAML 2.0 - Központosított menedzsment
Az adminok és felhasználók kezelésére is. - LDAP és Active Directory kezelés
- Social Login lehetőségek
- Kétfaktoros bejelentkezés (OTP)
- Identity Brokering
- Gyors, skálázható
- Személyre szabható
- Kiegészítések könnyen fejleszthetők hozzá
Hosszabb angol nyelvű írás a termékről: https://www.coditation.com/an-introduction-to-keycloak/
Felépítés
Client = Modulok
Az egyes modulok, melyek saját jogosultságokkal bírnak, a Keycloak modelljében Clientként szerepelnek. Minden egyes Clienthez rendelhetők egyedi beállítások és biztonsági konfigurációk, valamint a jogosultsági modellben is megjelennek oly módon, hogy lehetőség van az egyes jogosultságok hatóköreit alrendszer szinten meghatározni.
Role = Jogosultságok
A Keycloak által kezelt jogosultsági modellben az engedélyezés alapegysége a Role, azaz ez a legkisebb kiosztható jogosultság. Azt, hogy egy felhasználóhoz milyen Role-ok tartoznak, a Keycloak tartja nyilván, ám azt, hogy egy művelet az adott Role birtokában elvégezhető vagy sem, az adott műveletet megvalósító modul dönti el.
A tervezett konvenciók szerint egy Role egy entitás (például felhasználó) egy adott típusú műveletére vonatkozik (például írás vagy olvasás). A konvenció szintén kitér az egyes Role-ok elnevezésére: csupa nagybetűvel az [ENTITÁS NEVE]_[MŰVELET NEVE] formátumot kell kövesse. A fentebb leírtaknak megfelelően, például a felhasználó adatainak lekéréséhez a USER_READ jogosultság (Role) szükséges.
Az egyes modulokban használt jogosultságok Client Role-okra képződnek le, azaz csak az adott modul szkópjában jelennek meg. Ezeket az egyes moduloknak kell, hogy definiálják.
Composite Role = Szerepkör
A Keycloak lehetővé teszi, hogy egy Composite Role tartalmazzon további más Role-okat is. Ezek alapján az eredeti követelményekben megjelenő Szerepkör funkcionalitás leképezhető Composite Role-á. Ekkor a szerepkörhöz tartozó egyes jogosultságok, mint az adott Composite Role által tartalmazott Role jelenik meg.
Például így nézhet ki az adminisztrátori szerepkör:
Név: ROLE_ADMIN
Tartalmazott jogok:
USER_WRITE
USER_READ
Composite Role + Attribútumok = Felhasználó típusok
A Keycloak lehetőséget ad, egy Role vagy CompositeRole tetszőleges további adatokkal való bővítéséhez, attribútumok segítségével. Ezek alapján a Felhasználó típus leképezhető egy attribútumokkal kiegészített Composite Role-lá.
A felhasználó típusból következő egyes jogosultságok, mint az adott Composite Role által tartalmazott Role, míg az üzleti adatok felsorolása (azaz milyen adatokkal kell rendelkezni az adott felhasználói típus betöltéséhez) kiegészítő attribútumként jelenik meg.
Group = Csoport
A Keycloak csoportok kezelését is támogatja, azaz létrehozhatjuk a felhasználók egy csoportját, akiket egyben kezelünk.
Adapterek
Bár a Keycloak az összes szükséges funkció elérésére biztosít felületet, ennek használata a legtöbb felhasználókezelést és jogosultsági beállításokat végző felhasználó számára indokolatlanul komplex, kényelmetlen lenne. Szintúgy megnövekedett kliens oldali komplexitással járna a Keycloak API-jának közvetlen felhasználása az egyes modulokban.
Ennek a komplexitásnak az elfedésére, valamint a felhasználói élmény javítására általában egy Adapter komponenst fejlesztünk. Az adapter fő célja a Keycloak alacsonyszintű műveleteinek összefogása és a felhasználók, valamint a többi modul számára üzleti művelet szintű kiajánlása.
Pluginok
A Keycloak rendszer pluginolható. Például a IBM Security Verify Authenticator Extensions plugin segítségével Fido2 auth is elérhetővé válik. Illetve saját pluginok is fejleszthetők.
Identity providerek
Megvalósítható a Facebook, Google, stb.. bejelentkezési lehetőségek.
Konklúzió
Eddigi munkáink során nem találkoztunk olyan igénnyel, melynek megvalósítását nem tudtuk megoldani a Keycloak és minimális egyedi fejlesztés segítségével. Sőt, inkább az a jellemző, hogy a Keycloak mindent tud gyárilag, amire csak szükségünk van, így előszeretettel használjuk is. Hiszen ahelyett, hogy már kész dolgokat fejlesztenénk újra, az erőforrásainkat új érték teremtésére fordíthatjuk az egyedi szoftverfejlesztési projektjeink során.
Ha akár üzleti, akár technológiai szempontból kérdésed merülne fel a fentiekkel kapcsolatban, fordulj hozzánk bizalommal a tech@nitrowise.com címen.
Mindeközben én projekt menedzserből szépen lassan Product Ownerré váltam és a „sikeres” projekt zárás helyett a partnerek elégedettsége, az üzleti érték maximalizálása lett az, ami a mindennapjaimat vezérli.