U svakoj velikoj kompaniji, pa tako i u X5 Retail Group, s vremenom raste broj projekata koji traže autorizaciju korisnika. Kako vrijeme prolazi, potrebno je osigurati nesmetan prijelaz korisnika iz jedne aplikacije u drugu, što stvara potrebu za korištenjem jedinstvenog poslužitelja za prijavu jednim klikom (Single-Sign-On, SSO). No, što učiniti kada su identifikacijski pružatelji poput AD-a ili drugih, koji nemaju dodatne atribute, već korišteni u različitim projektima? U pomoć dolaze klase sustava poznate kao „identifikacijski posrednici“. Najfunkcionalniji među njima su oni poput Keycloak-a, Gravitee Access management i sl. Najčešće upotrebe mogu biti različite: strojna interakcija, sudjelovanje korisnika itd. Rješenje mora podržavati fleksibilnu i skalabilnu funkcionalnost koja može okupiti sve zahtjeve na jednom mjestu, a trenutno je to u našoj kompaniji identifikacijski posrednik – Keycloak.
Keycloak je proizvod otvorenog izvora namijenjen identificiranju i kontroli pristupa, koji podržava tvrtka RedHat. On je osnova za proizvode tvrtke koji koriste SSO – RH-SSO.
Osnovni pojmovi
Prije nego što se počnete baviti rješenjima i pristupima, potrebno je definirati termine i slijed procesa:
Identifikacija — to je procedura prepoznavanja subjekta po njegovom identifikatoru (jednostavnim riječima, to je određivanje imena, korisničkog imena ili broja).
Autentifikacija – to je procedura provjere autentičnosti (korisnika se provjerava pomoću lozinke, e-mail se provjerava putem elektroničkog potpisa itd.)
Autorizacija – to je omogućavanje pristupa nekom resursu (na primjer, elektroničkoj pošti).
Identifikacijski posrednik Keycloak
Keycloak — to je rješenje za upravljanje identifikacijom i pristupom s otvorenim izvorom, namijenjeno korištenju u informacijskim sustavima gdje se mogu koristiti obrasci mikroservisne arhitekture.
Keycloak nudi takve funkcije kao što su jedinstvena prijava (SSO), posrednička identifikacija i društvena prijava u sustav, federacija korisnika, klijentski adapteri, konzola za administraciju i konzola za upravljanje računima.
Osnovna funkcionalnost koju podržava Keycloak:
- Jedinstvena prijava i jedinstveno odjavljivanje za web aplikacije.
- Podrška za OpenID/OAuth 2.0/SAML.
- Identitetsko posredovanje – autentifikacija putem vanjskih OpenID Connect ili SAML identitetskih provajdera.
- Društvena prijava – podrška za Google, GitHub, Facebook, Twitter za identifikaciju korisnika.
- Federacija korisnika – sinhronizacija korisnika iz LDAP i Active Directory servera i drugih identitetskih provajdera.
- Kerberos most – korišćenje Kerberos servera za automatsku autentifikaciju korisnika.
- Administratorska konzola — za centralizovano upravljanje postavkama i parametrima rešenja putem Web-a.
- Konzola za upravljanje korisničkim računima – za samostalno upravljanje korisničkim profilima.
- Kustomizacija rešenja u skladu sa brendom kompanije.
- 2FA autentifikacija – podrška za TOTP/HOTP putem Google Authenticator ili FreeOTP.
- Tokovi prijave – moguće samoregistracija korisnika, obnova i resetovanje lozinki i druge opcije.
- Upravljanje sesijama – administratori mogu upravljati sesijama korisnika iz jedinstvene tačke.
- Mapperi tokena – povezivanje atributa korisnika, uloga i drugih potrebnih atributa u tokene.
- Fleksibilno upravljanje politikama putem realm, aplikacija i korisnika.
- CORS podrška – klijentski adapteri imaju ugrađenu podršku za CORS.
- Interfejsi provajdera usluga (SPI) – veliki broj SPI-a koji omogućavaju podešavanje različitih aspekata rada servera: tokovi autentifikacije, identitetski provajderi, mapiranje protokola i mnogo više.
- Klijentski adapteri za JavaScript aplikacije, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Podrška za rad sa različitim aplikacijama koje podržavaju OpenID Connect Relying Party biblioteku ili SAML 2.0 biblioteka provajdera usluga.
- Mogućnost proširenja putem dodataka.
Za CI/CD procese, kao i automatizaciju procesa upravljanja u Keycloak, može se koristiti REST API/JAVA API. Dokumentacija je dostupna u elektronskom formatu:
REST API
JAVA API
Identitetski provajderi na nivou preduzeća (On-Premise)
Mogućnost autentifikacije korisnika putem User Federation usluga.
Takođe može biti korišćena prolazna autentifikacija – ako se korisnici autentifikuju na radnim stanicama sa Kerberos (LDAP ili AD), mogu biti automatski autentifikovani na Keycloak bez potrebe da ponovo unose svoje korisničko ime i lozinku.
Za autentifikaciju i daljnju autorizaciju korisnika moguće je koristiti relacijsku bazu podataka, što je najprimjerenije za razvojne sredine jer ne zahtijeva dugotrajna podešavanja i integracije u ranim fazama projekata. Po defaultu, Keycloak koristi ugrađenu bazu podataka za pohranu postavki i podataka o korisnicima.
Popis podržanih baza podataka je širok i uključuje: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle i druge. Najtestiraniji su trenutno Oracle 12C Release1 RAC i Galera 3.12 cluster za MariaDB 10.1.19.
Identifikacijski pružatelji – social login
Moguće je koristiti prijavu iz društvenih mreža. Za aktivaciju mogućnosti autentikacije korisnika koristi se administratorska konzola Keycloak. Nema potrebe za promjenama u kodu aplikacija, a ova funkcionalnost je dostupna „iz kutije“ i može se aktivirati u bilo kojoj fazi realizacije projekta.
Za autentifikaciju korisnika moguće je koristiti OpenID/SAML identitetske pružatelje.
Tipični scenariji autorizacije s korištenjem OAuth2 u Keycloak
Authorization Code Flow – koristi se sa servernim aplikacijama (server-side applications). Jedan od najčešće korištenih tipova auth autorizacije, jer je dobro prilagođen za serverne aplikacije gdje izvorni kod aplikacije i podaci klijenta nisu dostupni trećim stranama. Proces se u ovom slučaju temelji na preusmjeravanju (redirection). Aplikacija mora biti sposobna interagirati s korisničkim agentom (user-agent), kao što je web preglednik – primati kodove autorizacije API preusmjerene putem korisničkog agenta.
Implicit Flow – koristi se u mobilnim ili web aplikacijama (aplikacije koje rade na uređaju korisnika).
Neizraziti tip odobrenja koristi se u mobilnim i web aplikacijama gdje se privatnost korisnika ne može garantirati. Neizraziti tip odobrenja također koristi preusmjeravanje korisničkog agenta, pri čemu se pristupni token predaje korisničkom agentu za daljnju upotrebu u aplikaciji. To čini token dostupnim korisniku i drugim aplikacijama na korisnikovom uređaju. Ovaj tip odobrenja ne provodi autentifikaciju aplikacije, a cijeli proces oslanja se na URL preusmjeravanja (registriran ranije u servisu).
Neizraziti tok ne podržava osvježavanje pristupnog tokena (refresh tokens).
Grant tok za klijentske vjerodajnice — koristi se kada aplikacija pristupa API-ju. Ovaj tip odobrenja obično se koristi za 'poslužitelj-za-poslužitelj' interakcije, koje se moraju izvoditi u pozadini bez neposredne interakcije s korisnikom. Tok davanja klijentskih vjerodajnica omogućuje web usluzi (povjerljivom klijentu) korištenje vlastitih vjerodajnica umjesto identifikacije korisnika za autentifikaciju prilikom poziva druge web usluge. Za viši nivo sigurnosti, pozivateljska usluga može koristiti certifikat (umjesto zajedničkog tajnog ključa) kao vjerodajnicu.
OAuth2 specifikacija opisana je u
JWT token i njegove prednosti
JWT (JSON Web Token) — otvoreni standard (), koji definira kompaktan i samostalan način za sigurnu razmjenu informacija između strana u obliku JSON objekta.
Prema standardu, token se sastoji od tri dijela u base-64 formatu, odvojena točkama. Prvi dio se zove zaglavlje (header), koje sadrži tip tokena i naziv hash algoritma za generiranje digitalnog potpisa. Drugi dio sadrži osnovne informacije (korisnik, atributi itd.). Treći dio – digitalni potpis.
..
Nikada ne pohranjujte token u vašu BDP. Zato što je važeći token ekvivalentan lozinci, pohranjivanje tokena je isto kao pohranjivanje lozinke u otvorenom obliku.
Access-token — je token koji svom vlasniku omogućuje pristup zaštićenim resursima servera. Obično ima kratak rok trajanja i može sadržavati dodatne informacije, kao što je IP adresa strane koja zahtijeva taj token.
Refresh token — je token koji klijentima omogućuje da zatraže nove access tokene nakon što im istekne rok trajanja. Ovi tokeni se obično dodjeljuju na duži rok.
Glavne prednosti upotrebe u mikroservisnoj arhitekturi:
- Mogućnost pristupa različitim aplikacijama i uslugama putem jedinstvene autentifikacije.
- U slučaju nedostatka određenih potrebnih atributa u korisničkim profilima moguće je obogatiti podatke koji se mogu dodati u korisni teret, uključujući automatski i "u hodu".
- Nema potrebe za pohranjivanjem informacija o aktivnim sesijama, serverska aplikacija samo treba provjeriti potpis.
- Fleksibilnije upravljanje pristupom zahvaljujući dodatnim atributima u korisnom teretu.
- Primjena potpisa tokena za zaglavlje i korisni teret povećava sigurnost rješenja u cjelini.
JWT token — sastav
Zaglavlje — po defaultu, zaglavlje sadrži samo tip tokena i algoritam koji se koristi za šifriranje.
Tip tokena se pohranjuje u ključu "typ". Ključ "typ" se ignorira u JWT-u. Ako ključ "typ" postoji, njegova vrijednost mora biti JWT, kako bi se naznačilo da je ovaj objekt JSON Web Token.
Drugi ključ "alg" određuje algoritam koji se koristi za šifriranje tokena. Po defaultu bi trebao biti postavljen na HS256. Zaglavlje se kodira u base64.
{ "alg": "HS256", "typ": "JWT"}
Payload (sadržaj) — u korisnom teretu se pohranjuje svaka informacija koja se treba provjeriti. Svaki ključ u korisnom teretu poznat je kao "izjava". Na primjer, u aplikaciju je moguće ući samo po pozivu (zatvoren promocijski događaj). Kada želimo pozvati nekoga da sudjeluje, šaljemo mu e-mail s pozivom. Važno je provjeriti da e-mail adresa pripada osobi koja prihvaća poziv, stoga ćemo uključiti tu adresu u korisni teret, čuvajući je u ključu "e-mail".
{ "email": "example@x5.ru" }
Ključevi u payload-u mogu biti proizvoljni. Međutim, postoji nekoliko rezerviranih:
- iss (Issuer) — definira aplikaciju iz koje se šalje token.
- sub (Tema) — definira predmet tokena.
- aud (Publika) – niz osjetljivih na velika/mala slova ili URI, koji je popis primatelja ovog tokena. Kada primatelj primi JWT s ovom ključem, mora provjeriti svoju prisutnost među primateljima — inače treba ignorirati token.
- exp (Vrijeme isteka) — označava kada ističe valjanost markera. Standard JWT zahtijeva da se svi njegovi umnoživi odbijaju kada im istekne valjanost. Ključ exp mora biti vremenska oznaka u unix formatu.
- nbf (Ne prije) — ovo je vrijeme u unix formatu koje određuje trenutak kada token postaje valjan.
- iat (Izdano u) — ovaj ključ predstavlja vrijeme kada je token izdan i može se koristiti za određivanje starosti JWT-a. Ključ iat mora biti vremenska oznaka u unix formatu.
- Jti (JWT ID) — niz koji definira jedinstveni identifikator ovog tokena uzimajući u obzir velika i mala slova.
Važno je razumjeti da se korisni podaci ne prenose u šifriranom obliku (iako, tokeni mogu biti ugniježdeni i tada je moguće prenositi šifrirane podatke). Stoga se u njima ne smije pohranjivati nikakve tajne informacije. Kao i zaglavlje, korisni podaci se kodiraju u base64.
Potpis — kada imamo zaglavlje i korisne podatke, možemo izračunati potpis.
Uzimaju se kodirani u base64: zaglavlje i korisni podaci, oni se spajaju u niz kroz točku. Tada se ovaj niz i tajni ključ šalju algoritmu šifriranja navedenom u zaglavlju (ključ „alg“). Ključ može biti bilo koja niz. Duži nizovi bit će najpoželjniji, jer će trebati više vremena za pronalaženje.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Izrada arhitekture otpornog klastera Keycloak
Kada se koristi jedan klaster za sve projekte, zahtjevi za SSO rješenjem postaju veći. Kada je broj projekata mali, ti zahtjevi nisu toliko osjetni za sve projekte, međutim, s povećanjem broja korisnika i integracija, raste potreba za dostupnošću i performansama.
Povećanje rizika od neuspjeha jedinstvenog SSO-a povećava zahtjeve za arhitekturu rješenja i korištene metode rezerviranja komponenti te dovodi do vrlo strogog SLA-a. U vezi s tim, projekti često imaju vlastitu infrastrukturu koja nije otporna na neuspjehe tijekom razvoja ili ranih faza implementacije rješenja. Kako se razvijaju, potrebna su rješenja koja omogućuju rast i skalabilnost. Najflexibilnije je izgraditi otporniji klaster koristeći kontejnersku virtualizaciju ili hibridni pristup.
Za rad u načinu Active/Active i Active/Passive klastera potrebno je osigurati dosljednost podataka u relacijskoj bazi podataka - oba čvora baze podataka moraju biti sinkrono replikovana među različitim geografski distribuiranim podatkovnim centrima.
Najjednostavniji primjer otpornog instaliranja.
Koje prednosti donosi korištenje jedinstvenog klastera:
- Visoka dostupnost i performanse.
- Podrška za načine rada: Active/Active, Active/Passive.
- Mogućnost dinamičkog skaliranja - pri korištenju kontejnerske virtualizacije.
- Mogućnost centraliziranog upravljanja i nadzora.
- Jedinstveni pristup za identifikaciju/ autentifikaciju/ autorizaciju korisnika u projektima.
- Prozirnija interakcija između različitih projekata bez uključivanja korisnika.
- Mogućnost ponovnog korištenja JWT tokena u različitim projektima.
- Jedinstvena točka povjerenja.
- Brži početak projekata korištenjem mikroservisa/ kontejnerske virtualizacije (nije potrebno pokretati i postavljati dodatne komponente).
- Postoji mogućnost kupnje komercijalne podrške od dobavljača.
Na što treba obratiti pažnju pri planiranju klastera
DBMS
Keycloak koristi sustav upravljanja DBMS-om za pohranu: realms, clients, users itd.
Podržava širok spektar DBMS-a: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak dolazi s vlastitom ugrađenom relacijskom bazom podataka. Preporučuje se korištenje za nenapučena okruženja - poput razvojnih okruženja.
Za rad u načinu Active/Active i Active/Passive klastera potrebno je osigurati dosljednost podataka u relacijskoj bazi podataka, a oba čvora klastera baza podataka sinkrono se replikiraju među podatkovnim centrima.
Distribuirani cache (Infinspan)
Za ispravan rad klastera potrebna je dodatna sinkronizacija sljedećih vrsta keša uz JBoss Data Grid:
Sesije autentifikacije — koriste se za pohranu podataka prilikom autentifikacije određenog korisnika. Upiti iz ovog keša obično uključuju samo preglednik i Keycloak server, a ne aplikaciju.
Akcijski tokeni — koriste se za scenarije kada korisnik treba potvrditi akciju asinkrono (putem e-pošte). Na primjer, tijekom tokova zaboravljene lozinke, keš akcijskih tokena Infinispan koristi se za praćenje metapodataka o povezanih markerima akcija koji su već korišteni, stoga se ne mogu ponovo koristiti.
Keširanje i povlačenje trajnih podataka – koristi se za keširanje trajnih podataka kako bi se izbjegli nepotrebni upiti prema bazi podataka. Kada neki Keycloak server ažurira podatke, svi ostali Keycloak serveri u svim centrima podataka moraju biti svjesni toga.
Rad — koristi se samo za slanje poruka o nevaženju između čvorova klastera i centara podataka.
Korisničke sesije — koriste se za pohranu podataka o korisničkim sesijama koje su valjane tijekom sesije preglednika korisnika. Keš mora obraditi HTTP zahtjeve od krajnjeg korisnika i aplikacije.
Zaštita od brute force napada — koristi se za praćenje podataka o neuspješnim prijavama.
Upravljanje opterećenjem
Upravljačka jedinica opterećenja je jedinstvena točka ulaza u Keycloak i mora podržavati sticky sesije.
Serverske aplikacije
Koriste se za kontrolu interakcije između komponenti i mogu biti virtualizirane ili kontejnerizirane uz korištenje postojećih alata za automatizaciju i dinamičko skaliranje infrastrukture. Najčešći scenariji implementacije u OpenShift, Kubernetes, Rancher.
Ovdje prva dio — teoretski — završava. U sljedećim ciklusima članaka bit će razmatrani primjeri integracija s različitim pružateljima identiteta i primjeri postavki.
Izvor: habr.com
