U svakoj velikoj kompaniji, a X5 Retail Group nije izuzetak, kako se razvija, povećava se broj projekata koji zahtijevaju autorizaciju korisnika. Vremenom je neophodan nesmetan prelazak korisnika iz jedne aplikacije u drugu, a onda postoji potreba za korišćenjem jednog Single-Sing-On (SSO) servera. Ali šta je kada se provajderi identiteta kao što su AD ili drugi koji nemaju dodatne atribute već koriste u raznim projektima. U pomoć će priskočiti klasa sistema pod nazivom "posrednici za identifikaciju". Najfunkcionalniji su njeni predstavnici, kao što su Keycloak, Gravitee Access management, itd. Najčešće slučajevi upotrebe mogu biti različiti: interakcija mašine, učešće korisnika itd. Rješenje mora podržavati fleksibilnu i skalabilnu funkcionalnost koja može kombinirati sve zahtjeve u jednom, a takva rješenja naša kompanija sada ima posrednika indikacija - Keycloak.
Keycloak je proizvod otvorenog koda za identitet i kontrolu pristupa koji održava RedHat. To je osnova za proizvode kompanije koji koriste SSO - RH-SSO.
Osnovni pojmovi
Prije nego što počnete da se bavite rješenjima i pristupima, trebali biste odlučiti o terminima i redoslijedu procesa:
Identifikacija je postupak za prepoznavanje subjekta po njegovom identifikatoru (drugim riječima, ovo je definicija imena, logina ili broja).
Autentifikacija - ovo je postupak autentifikacije (korisnik se provjerava lozinkom, pismo se provjerava elektronskim potpisom itd.)
Autorizacija - ovo je pružanje pristupa resursu (na primjer, e-pošti).
Identity Broker Keycloak
keycloak je rješenje za upravljanje identitetom i pristupom otvorenog koda dizajnirano za korištenje u IS-u gdje se mogu koristiti obrasci mikroservisne arhitekture.
Keycloak nudi funkcije kao što su jedinstvena prijava (SSO), brokerski identitet i prijava na društvenim mrežama, korisnička federacija, klijentski adapteri, administratorska konzola i konzola za upravljanje računima.
Osnovna funkcionalnost koju podržava Keycloak:
- Single-Sign On i Single-Sign Out za aplikacije pretraživača.
- Podrška za OpenID/OAuth 2.0/SAML.
- Identity Brokering - autentifikacija pomoću eksternih OpenID Connect ili SAML dobavljača identiteta.
- Društvena prijava - podrška za Google, GitHub, Facebook, Twitter za identifikaciju korisnika.
- Federacija korisnika - sinhronizacija korisnika sa LDAP i Active Directory servera i drugih provajdera identiteta.
- Kerberos most - korištenje Kerberos servera za automatsku autentifikaciju korisnika.
- Admin Console - za objedinjeno upravljanje postavkama i opcijama rješenja putem weba.
- Konzola za upravljanje nalogom - za samostalno upravljanje korisničkim profilom.
- Prilagođavanje rješenja bazirano na korporativnom identitetu kompanije.
- 2FA autentifikacija - TOTP/HOTP podrška uz Google Authenticator ili FreeOTP.
- Tokovi prijave - moguća je samoregistracija korisnika, vraćanje lozinke i resetovanje i drugo.
- Upravljanje sesijama - administratori mogu upravljati sesijama korisnika iz jedne tačke.
- Token Mappers - povezivanje korisničkih atributa, uloga i drugih potrebnih atributa za tokene.
- Fleksibilno upravljanje politikama u području, aplikaciji i korisnicima.
- CORS podrška - Klijentski adapteri imaju ugrađenu CORS podršku.
- Interfejsi dobavljača usluga (SPI) – Veliki broj SPI-ova koji vam omogućavaju da prilagodite različite aspekte servera: tokove provjere autentičnosti, dobavljače identiteta, mapiranje protokola i još mnogo toga.
- Klijentski adapteri za JavaScript aplikacije, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Podrška za rad sa različitim aplikacijama koje podržavaju biblioteku OpenID Connect Relying Party ili SAML 2.0 biblioteku dobavljača usluga.
- 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 elektronskim putem:
REST API
Java API
Pružaoci identiteta preduzeća (lokalni)
Mogućnost autentifikacije korisnika putem usluga User Federation.
Prolazna autentifikacija se također može koristiti - ako se korisnici autentifikuju na radnim stanicama sa Kerberos-om (LDAP ili AD), tada se mogu automatski autentifikovati na Keycloak bez potrebe da ponovo unose svoje korisničko ime i lozinku.
Za autentifikaciju i dalju autorizaciju korisnika moguće je koristiti relacioni DBMS, koji je najprimenljiviji za razvojna okruženja, jer ne podrazumeva dugotrajna podešavanja i integracije u ranim fazama projekta. Po defaultu, Keycloak koristi ugrađeni DBMS za spremanje postavki i korisničkih podataka.
Lista podržanih DBMS-a je opsežna 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žaoci identiteta - društvena prijava
Moguće je koristiti prijavu sa društvenih mreža. Da aktivirate mogućnost autentifikacije korisnika, koristite Keycloack administratorsku konzolu. Promjene u kodu aplikacije nisu potrebne i ova funkcionalnost je dostupna izvan kutije i može se aktivirati u bilo kojoj fazi projekta.
Moguće je koristiti OpenID/SAML dobavljače identiteta za autentifikaciju korisnika.
Tipični scenariji autorizacije koji koriste OAuth2 u Keycloaku
Tok koda autorizacije - koristi se sa aplikacijama na strani servera. Jedan od najčešćih tipova autorizacijskih dozvola jer je vrlo prikladan za serverske aplikacije gdje izvorni kod aplikacije i podaci klijenta nisu dostupni autsajderima. Proces se u ovom slučaju zasniva na preusmjeravanju. Aplikacija mora biti u mogućnosti da stupi u interakciju s korisničkim agentom (korisničkim agentom), kao što je web pretraživač - da prima API autorizacijske kodove preusmjerene preko korisničkog agenta.
implicitni tok - koriste mobilne ili web aplikacije (aplikacije koje se pokreću na korisnikovom uređaju).
Tip dozvole implicitne autorizacije koriste mobilne i web aplikacije gdje se ne može garantirati povjerljivost klijenta. Implicitni tip dozvole također koristi preusmjeravanje korisničkog agenta, pri čemu se pristupni token prosljeđuje korisničkom agentu za dalju upotrebu u aplikaciji. Ovo čini token dostupnim korisniku i drugim aplikacijama na korisnikovom uređaju. Ova vrsta dozvole za autorizaciju ne potvrđuje identitet aplikacije, a sam proces se oslanja na URL za preusmjeravanje (prethodno registriran u servisu).
Implicitni tok ne podržava tokene za osvježavanje tokena pristupa.
Tok dodjele akreditiva klijenta — koriste se kada aplikacija pristupa API-ju. Ova vrsta autorizacijske dozvole se obično koristi za interakcije između poslužitelja koje se moraju izvesti u pozadini bez neposredne interakcije korisnika. Tok dodjele vjerodajnica klijenta omogućava web servisu (povjerljivi klijent) da koristi svoje vlastite vjerodajnice umjesto da se lažno predstavlja kao korisnik za provjeru autentičnosti prilikom pozivanja druge web usluge. Za viši nivo sigurnosti, moguće je da usluga poziva da koristi sertifikat (umesto zajedničke tajne) kao akreditiv.
OAuth2 specifikacija je opisana 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 objekta.
Prema standardu, token se sastoji od tri dijela u formatu base-64, odvojenih tačkama. Prvi dio se zove zaglavlje, koje sadrži tip tokena i naziv hash algoritma za dobijanje digitalnog potpisa. Drugi dio pohranjuje osnovne informacije (korisnik, atributi, itd.). Treći dio je digitalni potpis.
. .
Nikada nemojte pohranjivati token u svoju DB. Budući da je važeći token ekvivalent lozinke, pohranjivanje tokena je kao pohranjivanje lozinke u čistom tekstu.
Pristupni token je token koji svom vlasniku daje pristup sigurnim serverskim resursima. Obično ima kratak vijek trajanja i može sadržavati dodatne informacije kao što je IP adresa strane koja traži token.
Osvježi token je token koji omogućava klijentima da zatraže nove pristupne tokene nakon što im istekne životni vijek. Ovi tokeni se obično izdaju na duži vremenski period.
Glavne prednosti upotrebe u mikroservisnoj arhitekturi:
- Mogućnost pristupa raznim aplikacijama i uslugama putem jednokratne provjere autentičnosti.
- U nedostatku određenog broja potrebnih atributa u korisničkom profilu, moguće je obogatiti podacima koji se mogu dodati korisnom učitavanju, uključujući automatske i on-the-fly.
- Nema potrebe za pohranjivanjem informacija o aktivnim sesijama, serverska aplikacija treba samo da provjeri potpis.
- Fleksibilnija kontrola pristupa kroz dodatne atribute u teretu.
- Upotreba potpisa tokena za zaglavlje i korisni teret povećava sigurnost rješenja u cjelini.
JWT token - sastav
Header - po defaultu, zaglavlje sadrži samo tip tokena i algoritam koji se koristi za šifriranje.
Tip tokena je pohranjen u ključu "typ". Ključ 'type' se zanemaruje u JWT-u. Ako je ključ "typ" prisutan, njegova vrijednost mora biti JWT da bi se pokazalo da je ovaj objekt JSON Web Token.
Drugi ključ "alg" definira algoritam koji se koristi za šifriranje tokena. Podrazumevano bi trebao biti postavljen na HS256. Zaglavlje je kodirano u base64.
{ "alg": "HS256", "type": "JWT"}
nosivost (sadržaj) - nosivost pohranjuje sve informacije koje je potrebno provjeriti. Svaki ključ u korisnom učitavanju poznat je kao "zahtjev". Na primjer, u aplikaciju možete ući samo uz pozivnicu (zatvorena promocija). Kada želimo nekoga pozvati da učestvuje, šaljemo mu pozivno pismo. Važno je provjeriti da email adresa pripada osobi koja prihvata pozivnicu, tako da ćemo ovu adresu uključiti u payload, zbog toga je pohranjujemo u ključu "email"
{ "e-pošta": "[email zaštićen]"}
Ključevi u nosivosti mogu biti proizvoljni. Ipak, postoji nekoliko rezervisanih:
- iss (Izdavač) - Identificira aplikaciju iz koje se šalje token.
- sub (Subject) - definira subjekt tokena.
- aud (Audience) je niz nizova ili URI-ja koji su osjetljivi na velika i mala slova, a to je lista primatelja ovog tokena. Kada strana primateljica primi JWT sa datim ključem, ona mora provjeriti prisutnost sebe u primaocima - u suprotnom zanemariti token.
- exp (Vrijeme isteka) - Označava kada token ističe. JWT standard zahtijeva da sve njegove implementacije odbiju istekle tokene. Ključ exp mora biti vremenska oznaka u unix formatu.
- nbf (Ne prije) je vrijeme u unix formatu koje određuje trenutak kada token postaje važeći.
- iat (Issued At) - Ovaj ključ predstavlja vrijeme kada je token izdat 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 korisni teret ne prenosi u šifriranom obliku (iako se tokeni mogu ugniježditi i tada je moguće prenijeti šifrirane podatke). Stoga ne može pohraniti nikakve tajne informacije. Kao i zaglavlje, korisni teret je kodiran base64.
Potpis - kada imamo naslov i nosivost, možemo izračunati potpis.
Base64 kodirano: zaglavlje i korisni teret se uzimaju, kombinuju se u niz kroz tačku. Zatim se ovaj niz i tajni ključ unose u algoritam šifriranja koji je naveden u zaglavlju (ključ "alg"). Ključ može biti bilo koji niz. Duže žice će biti najpoželjnije jer će im trebati više vremena za podizanje.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Izgradnja Keycloak Failover klastera 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 uočljivi za sve projekte, međutim, s povećanjem broja korisnika i integracija, povećavaju se zahtjevi za dostupnošću i performansama.
Povećanje rizika od kvara jednog SSO-a povećava zahtjeve za arhitekturom rješenja i metodama koje se koriste za redundantne komponente i dovodi do vrlo tesnog SLA-a. S tim u vezi, češće tokom razvoja ili ranih faza implementacije rješenja, projekti imaju vlastitu infrastrukturu koja nije otporna na greške. Kako razvoj napreduje, potrebno je postaviti mogućnosti za razvoj i skaliranje. Najfleksibilnije je izgraditi klaster za prevazilaženje greške koristeći virtualizaciju kontejnera ili hibridni pristup.
Za rad u aktivnim/aktivnim i aktivnim/pasivnim režimima klastera, potrebno je osigurati konzistentnost podataka u relacijskoj bazi podataka – oba čvora baze podataka moraju biti sinhrono replicirana između različitih geo-distribuiranih centara podataka.
Najjednostavniji primjer instalacije otporne na greške.
Koje su prednosti korištenja jednog klastera:
- Visoka dostupnost i performanse.
- Podrška za režime rada: Active / Active, Active / Passive.
- Mogućnost dinamičkog skaliranja - kada se koristi virtualizacija kontejnera.
- 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 ponovnog korištenja JWT tokena u različitim projektima.
- Jedinstvena tačka poverenja.
- Brže pokretanje projekata pomoću mikroservisa/virtuelizacije kontejnera (nema potrebe za podizanjem i konfiguracijom dodatnih komponenti).
- Moguće je kupiti komercijalnu podršku od prodavca.
Na šta treba obratiti pažnju prilikom planiranja klastera
DBMS
Keycloak koristi sistem upravljanja bazom podataka za skladištenje: domena, klijenata, korisnika itd.
Podržan je širok spektar DBMS-a: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak dolazi sa vlastitom ugrađenom relacijskom bazom podataka. Preporučuje se upotreba za neopterećena okruženja - kao što su razvojna okruženja.
Za rad u aktivnim/aktivnim i aktivnim/pasivnim načinima klastera, potrebna je konzistentnost podataka u relacijskoj bazi podataka, a oba čvora klastera baze podataka se sinhrono repliciraju između centara podataka.
Distribuirana keš memorija (Infinspan)
Za ispravan rad klastera potrebna je dodatna sinhronizacija sljedećih tipova predmemorije koristeći JBoss Data Grid:
Autentifikacijske sesije - koriste se za spremanje podataka prilikom provjere autentičnosti određenog korisnika. Zahtjevi iz ove keš memorije obično uključuju samo pretraživač i Keycloak server, a ne aplikaciju.
Tokeni akcije se koriste za scenarije u kojima korisnik treba asinhrono potvrditi akciju (putem e-pošte). Na primjer, tokom toka zaboravljanja lozinke, actionTokens Infinispan keš se koristi za praćenje metapodataka o povezanim tokenima akcije koji su već korišteni, tako da se ne mogu ponovo koristiti.
Keširanje i poništavanje trajnih podataka – koristi se za keširanje trajnih podataka kako bi se izbjegli nepotrebni upiti bazi podataka. Kada bilo koji Keycloak server ažurira podatke, svi ostali Keycloak serveri u svim data centrima moraju znati o tome.
Posao – Koristi se samo za slanje nevažećih poruka između čvorova klastera i centara podataka.
Korisničke sesije - koriste se za pohranjivanje podataka o korisničkim sesijama koje su važeće za vrijeme trajanja sesije pretraživača korisnika. Keš memorija mora obraditi HTTP zahtjeve od krajnjeg korisnika i aplikacije.
Zaštita grubom silom - koristi se za praćenje podataka o neuspjelim prijavama.
Balansiranje opterećenja
Balansator opterećenja je jedinstvena ulazna tačka u keycloak i mora podržavati ljepljive sesije.
Serveri aplikacija
Koriste se za kontrolu interakcije komponenti jedna s drugom i mogu se virtuelizirati ili kontejnerizirati korištenjem postojećih alata za automatizaciju i dinamičkog skaliranja alata za automatizaciju infrastrukture. Najčešći scenariji implementacije u OpenShift, Kubernates, Rancher.
Ovim je završen prvi dio – teorijski. U sljedećoj seriji članaka analizirat će se primjeri integracija s različitim provajderima identiteta i primjeri postavki.
izvor: www.habr.com