U svakoj velikoj tvrtki, a X5 Retail Group nije iznimka, kako se razvija, povećava se broj projekata koji zahtijevaju autorizaciju korisnika. S vremenom je potreban besprijekoran prijelaz korisnika s jedne aplikacije na drugu, a zatim postoji potreba za korištenjem jednog Single-Sing-On (SSO) poslužitelja. Ali što kada se pružatelji identiteta kao što su AD ili drugi koji nemaju dodatne atribute već koriste u raznim projektima. Klasa sustava nazvanih "brokeri za identifikaciju" priskočit će u pomoć. Najfunkcionalniji su njegovi predstavnici, kao što su Keycloak, Gravitee Access management itd. Najčešće slučajevi korištenja mogu biti različiti: interakcija stroja, sudjelovanje korisnika itd. Rješenje mora podržavati fleksibilnu i skalabilnu funkcionalnost koja može kombinirati sve zahtjeve u jednom, i takva rješenja naša tvrtka sada ima indikacijskog brokera - Keycloak.
Keycloak je proizvod otvorenog koda za identifikaciju i kontrolu pristupa koji održava RedHat. To je osnova za proizvode tvrtke koji koriste SSO - RH-SSO.
Osnovni pojmovi
Prije nego što se počnete baviti rješenjima i pristupima, trebali biste odlučiti o terminima i redoslijedu procesa:
identifikacija je postupak za prepoznavanje subjekta njegovim identifikatorom (drugim riječima, ovo je definicija imena, prijave ili broja).
ovjera - radi se o autentifikacijskom postupku (korisnik se provjerava lozinkom, pismo se provjerava elektroničkim potpisom itd.)
Autorizacija - ovo je pružanje pristupa resursu (na primjer, e-pošti).
Identity Broker Keycloak
ogrtač za ključeve je rješenje otvorenog koda za upravljanje identitetom i pristupom dizajnirano za korištenje u IS-u gdje se mogu koristiti uzorci arhitekture mikroservisa.
Keycloak nudi značajke kao što su jedinstvena prijava (SSO), posredovani identitet i prijava na društvene mreže, korisnička federacija, klijentski adapteri, administratorska konzola i konzola za upravljanje računom.
Osnovne funkcije koje podržava Keycloak:
- Single-Sign On i Single-Sign Out za aplikacije preglednika.
- Podrška za OpenID/OAuth 2.0/SAML.
- Identity Brokering - provjera autentičnosti pomoću vanjskih pružatelja identiteta OpenID Connect ili SAML.
- Social Login - Google, GitHub, Facebook, Twitter podrška za identifikaciju korisnika.
- User Federation - sinkronizacija korisnika s LDAP i Active Directory poslužitelja i drugih pružatelja identiteta.
- Kerberos most - korištenje Kerberos poslužitelja za automatsku autentifikaciju korisnika.
- Administratorska konzola - za jedinstveno upravljanje postavkama i opcijama rješenja putem weba.
- Account Management Console - za samostalno upravljanje korisničkim profilom.
- Prilagodba rješenja temeljena na korporativnom identitetu tvrtke.
- 2FA autentifikacija - TOTP/HOTP podrška pomoću Google Authenticatora ili FreeOTP.
- Tijek prijave - moguća je samoregistracija korisnika, oporavak i poništavanje lozinke i drugo.
- Upravljanje sesijama - administratori mogu upravljati korisničkim sesijama s jedne točke.
- Token Mappers - vezivanje korisničkih atributa, uloga i drugih potrebnih atributa na tokene.
- Fleksibilno upravljanje pravilima u području, aplikaciji i korisnicima.
- Podrška za CORS - Adapteri za klijente imaju ugrađenu podršku za CORS.
- Sučelja pružatelja usluga (SPI) - veliki broj SPI-ova koji vam omogućuju prilagodbu različitih aspekata poslužitelja: tokovi provjere autentičnosti, pružatelji identiteta, mapiranje protokola i više.
- Adapteri klijenta za JavaScript aplikacije, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Podrška za rad s različitim aplikacijama koje podržavaju OpenID Connect Relying Party biblioteku ili SAML 2.0 Service Provider Library.
- Proširivo pomoću dodataka.
Za CI / CD procese, kao i automatizaciju procesa upravljanja u Keycloaku, može se koristiti REST API / JAVA API. Dokumentacija je dostupna u elektroničkom obliku:
REST API
Java API
Pružatelji identiteta poduzeća (on-premise)
Mogućnost autentifikacije korisnika putem usluga User Federation.
Prolazna autentifikacija se također može koristiti - ako se korisnici autentificiraju na radnim stanicama s Kerberosom (LDAP ili AD), tada se mogu automatski autentificirati na Keycloak bez ponovnog unosa korisničkog imena i lozinke.
Za autentifikaciju i daljnju autorizaciju korisnika moguće je koristiti relacijski DBMS, koji je najprimjenjiviji za razvojna okruženja, jer ne uključuje dugotrajne postavke i integracije u ranim fazama projekata. Prema zadanim postavkama, Keycloak koristi ugrađeni DBMS za pohranu postavki i korisničkih podataka.
Popis podržanih DBMS je opsežan i uključuje: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle i druge. Najtestiraniji do sada su Oracle 12C Release1 RAC i Galera 3.12 klaster za MariaDB 10.1.19.
Pružatelji identiteta - društvena prijava
Moguće je koristiti prijavu s društvenih mreža. Da biste aktivirali mogućnost autentifikacije korisnika, koristite Keycloack administratorsku konzolu. Promjene u aplikacijskom kodu nisu potrebne, a ova je funkcionalnost dostupna izvan kutije i može se aktivirati u bilo kojoj fazi projekta.
Za autentifikaciju korisnika moguće je koristiti pružatelje OpenID/SAML identiteta.
Tipični scenariji autorizacije korištenjem OAuth2 u Keycloaku
Tijek autorizacijskog koda - koristi se s aplikacijama na strani poslužitelja. Jedna od najčešćih vrsta dopuštenja za autorizaciju jer je dobro prilagođena za poslužiteljske aplikacije gdje izvorni kod aplikacije i klijentski podaci nisu dostupni vanjskim osobama. Proces se u ovom slučaju temelji na preusmjeravanju. Aplikacija mora moći komunicirati s korisničkim agentom (user-agent), kao što je web-preglednik – kako bi primila API autorizacijske kodove preusmjerene preko korisničkog agenta.
implicitni tok - koriste ga mobilne ili web aplikacije (aplikacije koje se pokreću na uređaju korisnika).
Vrsta dopuštenja implicitne autorizacije koriste mobilne i web aplikacije gdje se ne može jamčiti povjerljivost klijenta. Vrsta implicitne dozvole također koristi preusmjeravanje korisničkog agenta, pri čemu se pristupni token prosljeđuje korisničkom agentu za daljnju upotrebu u aplikaciji. Time token postaje dostupan korisniku i drugim aplikacijama na korisnikovom uređaju. Ova vrsta autorizacijske dozvole ne potvrđuje identitet aplikacije, a sam proces se oslanja na URL za preusmjeravanje (prethodno registriran na usluzi).
Implicitni tijek ne podržava tokene za osvježavanje tokena pristupa.
Tijek dodjele vjerodajnica klijenta — koriste se kada aplikacija pristupa API-ju. Ova vrsta autorizacijske dozvole obično se koristi za međuposlužiteljske interakcije koje se moraju izvoditi u pozadini bez neposredne interakcije korisnika. Tijek dodjele vjerodajnica klijenta omogućuje web-usluzi (povjerljivom klijentu) korištenje vlastitih vjerodajnica umjesto oponašanja korisnika za autentifikaciju prilikom poziva druge web-usluge. Za višu razinu sigurnosti, moguće je da pozivna služba koristi certifikat (umjesto zajedničke tajne) kao vjerodajnicu.
Specifikacija OAuth2 opisana je u
JWT token i njegove prednosti
JWT (JSON Web Token) je otvoreni standard () koji definira kompaktan i samostalan način za siguran prijenos informacija između strana kao JSON objekt.
Prema standardu, token se sastoji od tri dijela u formatu base-64, odvojena točkama. Prvi dio naziva se zaglavlje koje sadrži tip tokena i naziv hash algoritma za dobivanje digitalnog potpisa. Drugi dio pohranjuje osnovne informacije (korisnik, atributi itd.). Treći dio je digitalni potpis.
. .
Nikada ne spremajte token u svoju bazu podataka. Budući da je važeći token ekvivalentan lozinci, pohranjivanje tokena je kao pohranjivanje lozinke u čistom tekstu.
Pristupni token je token koji svom vlasniku daje pristup sigurnim resursima poslužitelja. Obično ima kratak životni vijek i može sadržavati dodatne informacije kao što je IP adresa strane koja traži token.
Osvježi token je token koji omogućuje klijentima da zatraže nove pristupne tokene nakon što im istekne životni vijek. Ovi se tokeni obično izdaju na duži vremenski period.
Glavne prednosti korištenja u mikroservisnoj arhitekturi:
- Mogućnost pristupa različitim aplikacijama i uslugama putem jednokratne provjere autentičnosti.
- U nedostatku niza potrebnih atributa u korisničkom profilu, moguće ga je obogatiti podacima koji se mogu dodati korisnom teretu, uključujući automatizirano i on-the-fly.
- Nema potrebe za pohranjivanjem informacija o aktivnim sesijama, poslužiteljska aplikacija treba samo provjeriti potpis.
- Fleksibilnija kontrola pristupa putem dodatnih atributa u sadržaju.
- Korištenje potpisa tokena za zaglavlje i sadržaj povećava sigurnost rješenja u cjelini.
JWT token - sastav
Naslov - prema zadanim postavkama, zaglavlje sadrži samo vrstu tokena i algoritam koji se koristi za enkripciju.
Vrsta tokena pohranjena je u ključu "typ". Ključ 'type' se zanemaruje u JWT-u. Ako je ključ "typ" prisutan, njegova vrijednost mora biti JWT kako bi označila da je ovaj objekt JSON web token.
Drugi ključ "alg" definira algoritam koji se koristi za šifriranje tokena. Prema zadanim postavkama trebao bi biti postavljen na HS256. Zaglavlje je kodirano u base64.
{ "alg": "HS256", "type": "JWT"}
nosivost (sadržaj) - korisni teret pohranjuje sve informacije koje je potrebno provjeriti. Svaki ključ u sadržaju poznat je kao "zahtjev". Na primjer, u aplikaciju možete ući samo uz poziv (zatvorena promocija). Kada nekoga želimo pozvati na sudjelovanje, šaljemo mu pozivno pismo. Važno je provjeriti pripada li adresa e-pošte osobi koja prihvaća pozivnicu, stoga ćemo tu adresu uključiti u korisni teret, za to je pohranjujemo u ključ "e-pošta"
{ "e-pošta": "[e-pošta zaštićena]"}
Ključevi u nosivosti mogu biti proizvoljni. Ipak, postoji nekoliko rezerviranih:
- iss (Izdavatelj) - Identificira aplikaciju iz koje se token šalje.
- sub (Subject) - definira subjekt tokena.
- aud (Publika) je niz nizova ili URI-ja koji razlikuju velika i mala slova koji je popis primatelja ovog tokena. Kada primateljska strana primi JWT s danim ključem, mora provjeriti svoju prisutnost u primateljima - u suprotnom ignorirati token.
- exp (Vrijeme isteka) - Označava kada token ističe. Standard JWT zahtijeva da sve njegove implementacije odbiju istekle tokene. Ključ exp mora biti vremenska oznaka u unix formatu.
- nbf (Not Before) je vrijeme u unix formatu koje određuje trenutak kada token postaje valjan.
- iat (Issued At) - Ovaj ključ predstavlja vrijeme kada je token izdan i može se koristiti za određivanje starosti JWT-a. Iat ključ mora biti vremenska oznaka u Unix formatu.
- Jti (JWT ID) — niz koji definira jedinstveni identifikator ovog tokena, osjetljiv na velika i mala slova.
Važno je razumjeti da se sadržaj ne prenosi u kriptiranom obliku (iako se tokeni mogu ugniježditi i tada je moguće prenijeti kriptirane podatke). Stoga ne može pohraniti nikakve tajne podatke. Kao i zaglavlje, korisni teret je base64 kodiran.
Potpis - kada imamo naslov i nosivost, možemo izračunati potpis.
Base64-kodirano: uzimaju se zaglavlje i sadržaj, kombiniraju se u niz kroz točku. Zatim se ovaj niz i tajni ključ unose u algoritam šifriranja navedenog u zaglavlju ("alg" ključ). Ključ može biti bilo koji niz. Dulje žice će biti najpoželjnije jer će trebati više vremena da se uhvate.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Izgradnja Keycloak Failover Cluster arhitekture
Kada koristite jedan klaster za sve projekte, postoje povećani zahtjevi za SSO rješenje. Kada je broj projekata mali, ovi zahtjevi nisu toliko vidljivi za sve projekte, no s povećanjem broja korisnika i integracija rastu zahtjevi za dostupnošću i performansama.
Povećanje rizika od kvara jednog SSO-a povećava zahtjeve za arhitekturu rješenja i metode koje se koriste za redundantne komponente i dovodi do vrlo čvrstog SLA. U tom smislu, češće tijekom razvoja ili ranih faza implementacije rješenja, projekti imaju vlastitu infrastrukturu koja nije tolerantna na pogreške. Kako razvoj napreduje, potrebno je postaviti prilike za razvoj i skaliranje. Najfleksibilnije je izgraditi failover cluster korištenjem virtualizacije spremnika ili hibridnog pristupa.
Za rad u načinima klastera Aktivno/Aktivno i Aktivno/Pasivno, potrebno je osigurati konzistentnost podataka u relacijskoj bazi podataka - oba čvora baze podataka moraju biti sinkrono replicirana između različitih geo-distribuiranih podatkovnih centara.
Najjednostavniji primjer instalacije otporne na greške.
Koje su prednosti korištenja jednog klastera:
- Visoka dostupnost i izvedba.
- Podrška za načine rada: aktivno / aktivno, aktivno / pasivno.
- Mogućnost dinamičkog skaliranja - kada se koristi virtualizacija spremnika.
- Mogućnost centraliziranog upravljanja i nadzora.
- Jedinstveni pristup za identifikaciju/autentifikaciju/autorizaciju korisnika u projektima.
- Transparentnija interakcija između različitih projekata bez uključivanja korisnika.
- Mogućnost ponovne upotrebe JWT tokena u raznim projektima.
- Jedna točka povjerenja.
- Brže pokretanje projekata korištenjem mikroservisa/virtualizacije spremnika (nema potrebe za podizanjem i konfiguracijom dodatnih komponenti).
- Moguće je kupiti komercijalnu podršku od dobavljača.
Što tražiti pri planiranju klastera
DBMS
Keycloak koristi sustav upravljanja bazom podataka za pohranu: područja, klijenata, korisnika itd.
Podržan je širok raspon DBMS-a: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak dolazi s vlastitom ugrađenom relacijskom bazom podataka. Preporuča se koristiti za neopterećena okruženja - kao što su razvojna okruženja.
Za rad u načinima klastera Aktivno/Aktivno i Aktivno/Pasivno potrebna je konzistentnost podataka u relacijskoj bazi podataka, a oba čvora klastera baze podataka sinkrono se repliciraju između podatkovnih centara.
Distribuirana predmemorija (Infinspan)
Za ispravan rad klastera potrebna je dodatna sinkronizacija sljedećih vrsta predmemorija pomoću JBoss Data Grid-a:
Sesije autentifikacije - koriste se za spremanje podataka prilikom autentifikacije određenog korisnika. Zahtjevi iz ove predmemorije obično uključuju samo preglednik i Keycloak poslužitelj, ne i aplikaciju.
Akcijski tokeni koriste se za scenarije u kojima korisnik treba potvrditi radnju asinkrono (putem e-pošte). Na primjer, tijekom toka zaboravljene lozinke, predmemorija actionTokens Infinispan koristi se za praćenje metapodataka o pridruženim akcijskim tokenima koji su već korišteni, tako da se ne može ponovno upotrijebiti.
Spremanje u predmemoriju i poništavanje trajnih podataka - koristi se za spremanje u predmemoriju trajnih podataka kako bi se izbjegli nepotrebni upiti u bazu podataka. Kada bilo koji Keycloak poslužitelj ažurira podatke, svi ostali Keycloak poslužitelji u svim podatkovnim centrima trebaju znati za to.
Rad - Koristi se samo za slanje nevažećih poruka između čvorova klastera i podatkovnih centara.
Korisničke sesije - koriste se za pohranu podataka o korisničkim sesijama koje vrijede za vrijeme trajanja sesije korisnikovog preglednika. Predmemorija mora obraditi HTTP zahtjeve krajnjeg korisnika i aplikacije.
Brute force protection - koristi se za praćenje podataka o neuspjelim prijavama.
Balansiranje opterećenja
Balansiranje opterećenja jedina je ulazna točka za keycloak i mora podržavati ljepljive sesije.
Aplikacijski poslužitelji
Koriste se za kontrolu međusobne interakcije komponenti i mogu se virtualizirati ili kontejnerizirati pomoću postojećih alata za automatizaciju i dinamičkog skaliranja alata za automatizaciju infrastrukture. Najčešći scenariji implementacije u OpenShift, Kubernates, Rancher.
Time završavamo prvi dio – onaj teorijski. U sljedećoj seriji članaka bit će analizirani primjeri integracija s različitim pružateljima identiteta i primjeri postavki.
Izvor: www.habr.com