V vsakem velikem podjetju in X5 Retail Group ni nobena izjema, saj se z razvojem povečuje število projektov, ki zahtevajo avtorizacijo uporabnikov. Sčasoma je potreben nemoten prehod uporabnikov iz ene aplikacije v drugo, nato pa je treba uporabiti en sam strežnik Single-Sing-On (SSO). A kaj, ko se ponudniki identitet, kot je AD ali drugi, ki nimajo dodatnih atributov, že uporabljajo v različnih projektih. Na pomoč bo priskočil razred sistemov, imenovan "identification brokers". Najbolj funkcionalni so njeni predstavniki, kot so Keycloak, Gravitee Access management itd. Najpogosteje so primeri uporabe lahko različni: strojna interakcija, sodelovanje uporabnika itd. Rešitev mora podpirati prilagodljivo in razširljivo funkcionalnost, ki združuje vse zahteve v enem, in takšne rešitve ima naše podjetje zdaj posrednika indikacije - Keycloak.
Keycloak je odprtokodni izdelek za identifikacijo in nadzor dostopa, ki ga vzdržuje RedHat. Je osnova za izdelke podjetja, ki uporabljajo SSO - RH-SSO.
Osnovni pojmi
Preden se začnete ukvarjati z rešitvami in pristopi, se morate odločiti glede terminov in zaporedja procesov:
Identifikacija je postopek za prepoznavanje subjekta po njegovem identifikatorju (z drugimi besedami, to je definicija imena, prijave ali številke).
Preverjanje pristnosti - gre za postopek avtentikacije (uporabnik se preveri z geslom, pismo se preveri z elektronskim podpisom itd.)
Dovoljenje - to je zagotavljanje dostopa do vira (na primer do e-pošte).
Identity Broker Keycloak
keycloak je odprtokodna rešitev za upravljanje identitete in dostopa, zasnovana za uporabo v IS, kjer je mogoče uporabiti vzorce arhitekture mikrostoritev.
Keycloak ponuja funkcije, kot so enotna prijava (SSO), posredniška identiteta in družabna prijava, zveza uporabnikov, adapterji odjemalcev, skrbniška konzola in konzola za upravljanje računa.
Osnovna funkcionalnost, ki jo podpira Keycloak:
- Enkratna prijava in enkratna odjava za aplikacije brskalnika.
- Podpora za OpenID/OAuth 2.0/SAML.
- Identity Brokering – avtentikacija z uporabo zunanjih ponudnikov identitete OpenID Connect ali SAML.
- Social Login - Google, GitHub, Facebook, Twitter podpora za identifikacijo uporabnikov.
- User Federation - sinhronizacija uporabnikov iz strežnikov LDAP in Active Directory ter drugih ponudnikov identitet.
- Most Kerberos - uporaba strežnika Kerberos za samodejno preverjanje pristnosti uporabnikov.
- Administratorska konzola - za poenoteno upravljanje nastavitev in možnosti rešitev preko spleta.
- Konzola za upravljanje računa - za samostojno upravljanje uporabniškega profila.
- Prilagoditev rešitve na podlagi celostne grafične podobe podjetja.
- Preverjanje pristnosti 2FA – podpora TOTP/HOTP z uporabo Google Authenticator ali FreeOTP.
- Potek prijave - možna je samoregistracija uporabnika, obnovitev in ponastavitev gesla ter drugo.
- Upravljanje sej - skrbniki lahko upravljajo uporabniške seje z ene same točke.
- Token Mappers - vezava uporabniških atributov, vlog in drugih zahtevanih atributov na žetone.
- Prilagodljivo upravljanje pravilnikov v področju, aplikaciji in uporabnikih.
- Podpora za CORS – odjemalski adapterji imajo vgrajeno podporo za CORS.
- Vmesniki ponudnika storitev (SPI) – veliko število SPI-jev, ki vam omogočajo prilagajanje različnih vidikov strežnika: tokov preverjanja pristnosti, ponudnikov identitete, preslikave protokolov in več.
- Odjemalski adapterji za aplikacije JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Podpora za delo z različnimi aplikacijami, ki podpirajo knjižnico OpenID Connect Relying Party ali SAML 2.0 Service Provider Library.
- Razširljivo z uporabo vtičnikov.
Za procese CI / CD in avtomatizacijo procesov upravljanja v Keycloaku je mogoče uporabiti REST API / JAVA API. Dokumentacija je na voljo v elektronski obliki:
REST API
Java API
Ponudniki identitete podjetja (lokalno)
Možnost avtentikacije uporabnikov prek storitev User Federation.
Uporabi se lahko tudi prehodno preverjanje pristnosti – če se uporabniki preverjajo pristnosti na delovnih postajah s Kerberos (LDAP ali AD), se lahko samodejno preverjajo pri Keycloak, ne da bi morali ponovno vnesti uporabniško ime in geslo.
Za avtentikacijo in nadaljnjo avtorizacijo uporabnikov je možno uporabiti relacijski DBMS, ki je najbolj uporaben za razvojna okolja, saj ne vključuje dolgotrajnih nastavitev in integracij v zgodnjih fazah projektov. Keycloak privzeto uporablja vgrajeno DBMS za shranjevanje nastavitev in uporabniških podatkov.
Seznam podprtih DBMS je obsežen in vključuje: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle in druge. Najbolj preizkušena sta do sedaj Oracle 12C Release1 RAC in gruča Galera 3.12 za MariaDB 10.1.19.
Ponudniki identitet - social login
Možna je uporaba prijave iz socialnih omrežij. Če želite aktivirati možnost avtentikacije uporabnikov, uporabite skrbniško konzolo Keycloack. Spremembe kode aplikacije niso potrebne in ta funkcionalnost je na voljo takoj po namestitvi in jo je mogoče aktivirati v kateri koli fazi projekta.
Za avtentikacijo uporabnikov je možno uporabiti ponudnike OpenID/SAML Identity.
Tipični avtorizacijski scenariji z uporabo OAuth2 v Keycloaku
Potek avtorizacijske kode - uporablja se z aplikacijami na strani strežnika. Ena najpogostejših vrst dovoljenj za avtorizacijo, ker je zelo primerna za strežniške aplikacije, kjer izvorna koda aplikacije in podatki odjemalca niso na voljo zunanjim osebam. Postopek v tem primeru temelji na preusmeritvi. Aplikacija mora biti sposobna komunicirati z uporabniškim agentom (user-agent), kot je spletni brskalnik, da prejme avtorizacijske kode API, preusmerjene prek uporabniškega agenta.
implicitni tok - uporabljajo jih mobilne ali spletne aplikacije (aplikacije, ki se izvajajo na uporabnikovi napravi).
Vrsta dovoljenja za implicitno avtorizacijo uporabljajo mobilne in spletne aplikacije, kjer ni mogoče zagotoviti zaupnosti odjemalca. Vrsta implicitnega dovoljenja uporablja tudi preusmeritev uporabniškega agenta, pri čemer se žeton dostopa posreduje uporabniškemu agentu za nadaljnjo uporabo v aplikaciji. S tem postane žeton na voljo uporabniku in drugim aplikacijam v uporabnikovi napravi. Ta vrsta avtorizacijskega dovoljenja ne preverja pristnosti aplikacije, sam postopek pa se opira na preusmeritveni URL (prej registriran pri storitvi).
Implicit Flow ne podpira žetonov osveževanja žetona dostopa.
Tok odobritve poverilnic odjemalca — se uporabljajo, ko aplikacija dostopa do API-ja. Ta vrsta avtorizacijskega dovoljenja se običajno uporablja za interakcije med strežniki, ki jih je treba izvesti v ozadju brez takojšnje interakcije uporabnika. Tok odobritve poverilnic odjemalca spletni storitvi (zaupnemu odjemalcu) omogoča uporabo lastnih poverilnic, namesto da se predstavlja kot uporabnik za preverjanje pristnosti pri klicu druge spletne storitve. Za višjo raven varnosti je mogoče, da kličoča storitev kot poverilnico uporabi potrdilo (namesto skupne skrivnosti).
Specifikacija OAuth2 je opisana v
Žeton JWT in njegove prednosti
JWT (spletni žeton JSON) je odprt standard (), ki definira kompakten in samostojen način za varen prenos informacij med strankami kot objekt JSON.
V skladu s standardom je žeton sestavljen iz treh delov v formatu base-64, ločenih s pikami. Prvi del se imenuje glava, ki vsebuje vrsto žetona in ime zgoščevalnega algoritma za pridobitev digitalnega podpisa. V drugem delu so shranjeni osnovni podatki (uporabnik, atributi itd.). Tretji del je digitalni podpis.
. .
Nikoli ne shranjujte žetona v svojo DB. Ker je veljaven žeton enakovreden geslu, je shranjevanje žetona podobno shranjevanju gesla v čistem besedilu.
Dostopni žeton je žeton, ki lastniku omogoča dostop do varnih virov strežnika. Običajno ima kratko življenjsko dobo in lahko vsebuje dodatne informacije, kot je naslov IP stranke, ki zahteva žeton.
Osveži žeton je žeton, ki odjemalcem omogoča, da zahtevajo nove dostopne žetone po preteku njihove življenjske dobe. Ti žetoni se običajno izdajo za daljše časovno obdobje.
Glavne prednosti uporabe v mikrostoritveni arhitekturi:
- Možnost dostopa do različnih aplikacij in storitev z enkratno avtentikacijo.
- V odsotnosti številnih zahtevanih atributov v uporabniškem profilu je možno obogatiti s podatki, ki jih je mogoče dodati koristnemu tovoru, vključno z avtomatiziranimi in sprotnimi.
- Podatkov o aktivnih sejah ni treba shranjevati, strežniška aplikacija mora samo preveriti podpis.
- Prilagodljivejši nadzor dostopa z dodatnimi atributi v obremenitvi.
- Uporaba podpisa žetona za glavo in obremenitev poveča varnost rešitve kot celote.
Žeton JWT – sestava
Naslov - privzeto glava vsebuje samo vrsto žetona in algoritem, uporabljen za šifriranje.
Vrsta žetona je shranjena v ključu "typ". Ključ 'type' je v JWT prezrt. Če je ključ »typ« prisoten, mora biti njegova vrednost JWT, kar pomeni, da je ta predmet spletni žeton JSON.
Drugi ključ "alg" definira algoritem, uporabljen za šifriranje žetona. Privzeto mora biti nastavljen na HS256. Glava je kodirana v base64.
{ "alg": "HS256", "type": "JWT"}
nosilnost (vsebina) - tovor hrani vse informacije, ki jih je treba preveriti. Vsak ključ v obremenitvi je znan kot "zahtevek". Na primer, v aplikacijo lahko vstopite samo s povabilom (zaprta promocija). Ko želimo nekoga povabiti k sodelovanju, mu pošljemo vabilo. Pomembno je preveriti, ali e-poštni naslov pripada osebi, ki sprejme povabilo, zato bomo ta naslov vključili v koristni tovor, za to ga shranimo v ključ "e-pošta".
{ "E-naslov": "[e-pošta zaščitena]"}
Ključi v tovoru so lahko poljubni. Vendar pa je nekaj rezerviranih:
- iss (izdajatelj) – Identificira aplikacijo, iz katere se pošilja žeton.
- sub (Subject) - definira predmet žetona.
- aud (Občinstvo) je niz nizov ali URI-jev, ki razlikujejo velike in male črke, ki je seznam prejemnikov tega žetona. Ko prejemna stran prejme JWT z danim ključem, mora preveriti svojo prisotnost v prejemnikih – v nasprotnem primeru zanemari žeton.
- exp (Expiration Time) – Označuje, kdaj žeton poteče. Standard JWT zahteva, da vse njegove izvedbe zavrnejo žetone, ki so potekli. Ključ exp mora biti časovni žig v formatu Unix.
- nbf (Not Before) je čas v formatu unix, ki določa trenutek, ko žeton postane veljaven.
- iat (Izdan ob) – ta ključ predstavlja čas, ko je bil žeton izdan, in ga je mogoče uporabiti za določitev starosti JWT. Ključ iat mora biti časovni žig v formatu Unix.
- Jti (JWT ID) — niz, ki določa enolični identifikator tega žetona, občutljiv na velike in male črke.
Pomembno je razumeti, da se koristni tovor ne prenaša v šifrirani obliki (čeprav so žetoni lahko ugnezdeni in je nato mogoče prenašati šifrirane podatke). Zato ne more shraniti nobenih tajnih informacij. Tako kot glava je koristni tovor kodiran base64.
Podpis - ko imamo naslov in obremenitev, lahko izračunamo podpis.
Kodirano Base64: vzeta sta glava in tovor, združena v niz s piko. Nato sta ta niz in skrivni ključ vnesena v šifrirni algoritem, določen v glavi (ključ "alg"). Ključ je lahko kateri koli niz. Najbolj zaželene bodo daljše vrvice, saj bo trajalo dlje, da jih poberete.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Gradnja arhitekture gruče za preklop Keycloak
Pri uporabi ene same gruče za vse projekte so povečane zahteve za rešitev SSO. Pri majhnem številu projektov te zahteve niso tako opazne pri vseh projektih, z večanjem števila uporabnikov in integracij pa se povečujejo zahteve po razpoložljivosti in zmogljivosti.
Povečanje tveganja posamezne napake SSO poveča zahteve za arhitekturo rešitve in metode, ki se uporabljajo za redundantne komponente, ter vodi do zelo tesne pogodbe o ravni storitev. V zvezi s tem imajo projekti pogosteje med razvojem ali zgodnjimi fazami implementacije rešitev lastno infrastrukturo, ki ni odporna na napake. Ko razvoj napreduje, je treba določiti priložnosti za razvoj in povečanje. Najbolj prilagodljivo je zgraditi samodejni grozd z uporabo virtualizacije vsebnika ali hibridnega pristopa.
Za delo v načinih gruče Aktivno/Aktivno in Aktivno/Pasivno je treba zagotoviti konsistentnost podatkov v relacijski bazi podatkov – obe vozlišči baze podatkov morata biti sinhrono podvojeni med različnimi geografsko porazdeljenimi podatkovnimi centri.
Najenostavnejši primer namestitve, odporne na napake.
Kakšne so prednosti uporabe ene same gruče:
- Visoka razpoložljivost in zmogljivost.
- Podpora za načine delovanja: aktivno / aktivno, aktivno / pasivno.
- Možnost dinamičnega prilagajanja - pri uporabi virtualizacije vsebnika.
- Možnost centraliziranega upravljanja in spremljanja.
- Enoten pristop za identifikacijo/avtentikacijo/avtorizacijo uporabnikov v projektih.
- Bolj pregledna interakcija med različnimi projekti brez sodelovanja uporabnikov.
- Možnost ponovne uporabe žetona JWT v različnih projektih.
- Ena sama točka zaupanja.
- Hitrejši zagon projektov z uporabo mikrostoritev/virtualizacije vsebnikov (ni potrebe po dvigovanju in konfiguriranju dodatnih komponent).
- Od prodajalca je mogoče kupiti komercialno podporo.
Na kaj morate biti pozorni pri načrtovanju grozda
DBMS
Keycloak uporablja sistem za upravljanje baze podatkov za shranjevanje: področij, odjemalcev, uporabnikov itd.
Podprt je širok nabor DBMS: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak ima lastno vgrajeno relacijsko bazo podatkov. Priporočljiva je uporaba za neobremenjena okolja - kot so razvojna okolja.
Za delo v načinih gruče Aktivno/Aktivno in Aktivno/Pasivno je potrebna konsistentnost podatkov v relacijski bazi podatkov in obe vozlišči gruče baze podatkov se sinhrono podvajata med podatkovnimi centri.
Porazdeljeni predpomnilnik (Infinspan)
Za pravilno delovanje gruče je potrebna dodatna sinhronizacija naslednjih vrst predpomnilnikov z uporabo JBoss Data Grid:
Avtentikacijske seje – uporabljajo se za shranjevanje podatkov pri avtentikaciji določenega uporabnika. Zahteve iz tega predpomnilnika običajno vključujejo le brskalnik in strežnik Keycloak, ne pa aplikacije.
Žetoni dejanj se uporabljajo za scenarije, kjer mora uporabnik dejanje potrditi asinhrono (prek e-pošte). Na primer, med tokom pozabljenega gesla se predpomnilnik actionTokens Infinispan uporablja za spremljanje metapodatkov o povezanih žetonih dejanj, ki so že bili uporabljeni, zato ga ni mogoče ponovno uporabiti.
Predpomnjenje in razveljavitev trajnih podatkov – uporablja se za predpomnjenje trajnih podatkov, da se izognete nepotrebnim poizvedbam v bazi podatkov. Ko kateri koli strežnik Keycloak posodobi podatke, morajo za to vedeti vsi drugi strežniki Keycloak v vseh podatkovnih centrih.
Delo – Uporablja se samo za pošiljanje neveljavnih sporočil med vozlišči gruče in podatkovnimi centri.
Uporabniške seje – uporabljajo se za shranjevanje podatkov o uporabniških sejah, ki veljajo za čas trajanja seje uporabnikovega brskalnika. Predpomnilnik mora obdelati zahteve HTTP končnega uporabnika in aplikacije.
Zaščita na silo - uporablja se za sledenje podatkov o neuspešnih prijavah.
Izravnavanje obremenitve
Izravnalnik obremenitve je ena sama vstopna točka za keycloak in mora podpirati lepljive seje.
Aplikacijski strežniki
Uporabljajo se za nadzor interakcije komponent med seboj in jih je mogoče virtualizirati ali kontejnerizirati z uporabo obstoječih orodij za avtomatizacijo in dinamičnega skaliranja orodij za avtomatizacijo infrastrukture. Najpogostejši scenariji uvajanja v OpenShift, Kubernates, Rancher.
S tem zaključujemo prvi del – teoretični. V naslednji seriji člankov bodo analizirani primeri integracij z različnimi ponudniki identitet in primeri nastavitev.
Vir: www.habr.com