În orice companie mare, iar X5 Retail Group nu face excepție, pe măsură ce se dezvoltă, numărul de proiecte care necesită autorizarea utilizatorului crește. De-a lungul timpului, este necesară o tranziție fără întreruperi a utilizatorilor de la o aplicație la alta și apoi este nevoie de utilizarea unui singur server Single-Sing-On (SSO). Dar ce zici când furnizorii de identitate precum AD sau alții care nu au atribute suplimentare sunt deja utilizați în diverse proiecte. O clasă de sisteme numite „brokeri de identificare” va veni în ajutor. Cei mai funcționali sunt reprezentanții săi, precum Keycloak, Gravitee Access management etc. Cel mai adesea, cazurile de utilizare pot fi diferite: interacțiunea cu mașina, participarea utilizatorului etc. Soluția trebuie să suporte funcționalități flexibile și scalabile care să poată combina toate cerințele într-una singură, și astfel de soluții compania noastră are acum un broker de indicație - Keycloak.
Keycloak este un produs open source de control al identității și accesului menținut de RedHat. Este baza pentru produsele companiei folosind SSO - RH-SSO.
Concepte de bază
Înainte de a începe să vă ocupați de soluții și abordări, ar trebui să decideți în termenii și secvența proceselor:
identificare este o procedură de recunoaștere a unui subiect după identificatorul său (cu alte cuvinte, aceasta este definiția unui nume, autentificare sau număr).
autentificare - aceasta este o procedură de autentificare (utilizatorul este verificat cu o parolă, scrisoarea este verificată cu o semnătură electronică etc.)
autorizare - aceasta este furnizarea de acces la o resursă (de exemplu, la e-mail).
Identity Broker Keycloak
Mantaua cheii este o soluție open source de gestionare a identității și a accesului concepută pentru utilizare în IS, unde pot fi utilizate modele de arhitectură de microservicii.
Keycloak oferă funcții precum conectare unică (SSO), identitate intermediată și conectare la rețele sociale, federație de utilizatori, adaptoare pentru clienți, consolă de administrare și consolă de gestionare a contului.
Funcționalitate de bază susținută de Keycloak:
- Single-Sign On și Single-Sign Out pentru aplicațiile browser.
- Suport pentru OpenID/OAuth 2.0/SAML.
- Identity Brokering - autentificare folosind furnizori externi de identitate OpenID Connect sau SAML.
- Conectare socială - Google, GitHub, Facebook, Twitter suport pentru identificarea utilizatorului.
- User Federation - sincronizarea utilizatorilor de pe serverele LDAP și Active Directory și alți furnizori de identitate.
- Puntea Kerberos - folosind un server Kerberos pentru autentificarea automată a utilizatorilor.
- Consola de administrare - pentru gestionarea unificată a setărilor și a opțiunilor de soluție prin Web.
- Consola de gestionare a contului - pentru auto-gestionarea profilului de utilizator.
- Personalizarea soluției pe baza identității corporative a companiei.
- Autentificare 2FA - suport TOTP/HOTP folosind Google Authenticator sau FreeOTP.
- Fluxuri de conectare - auto-înregistrarea utilizatorului, recuperarea și resetarea parolei și altele sunt posibile.
- Managementul sesiunilor - administratorii pot gestiona sesiunile utilizatorilor dintr-un singur punct.
- Token Mappers - leagă atributele utilizatorului, roluri și alte atribute necesare la token-uri.
- Gestionare flexibilă a politicilor în domeniu, aplicație și utilizatori.
- Suport CORS - Adaptoarele client au suport CORS încorporat.
- Interfețe pentru furnizori de servicii (SPI) - Un număr mare de SPI-uri care vă permit să personalizați diverse aspecte ale serverului: fluxuri de autentificare, furnizori de identitate, mapare de protocol și multe altele.
- Adaptoare client pentru aplicații JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Suport pentru lucrul cu diverse aplicații care acceptă biblioteca OpenID Connect Relying Party sau biblioteca SAML 2.0 Service Provider.
- Extensibil folosind plugin-uri.
Pentru procesele CI/CD, precum și automatizarea proceselor de management în Keycloak, poate fi utilizat API-ul REST/JAVA API. Documentația este disponibilă electronic:
API-ul REST
API-ul Java
Furnizori de identitate de întreprindere (on-premise)
Abilitatea de a autentifica utilizatorii prin serviciile User Federation.
Autentificarea directă poate fi, de asemenea, utilizată - dacă utilizatorii se autentifică împotriva stațiilor de lucru cu Kerberos (LDAP sau AD), atunci aceștia pot fi autentificați automat la Keycloak fără a fi nevoie să-și introducă din nou numele de utilizator și parola.
Pentru autentificarea și autorizarea ulterioară a utilizatorilor, este posibil să se utilizeze un SGBD relațional, care este cel mai aplicabil pentru mediile de dezvoltare, deoarece nu implică setări și integrări lungi în etapele incipiente ale proiectelor. În mod implicit, Keycloak folosește un DBMS încorporat pentru a stoca setările și datele utilizatorului.
Lista de SGBD acceptate este extinsă și include: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle și altele. Cele mai testate până acum sunt Oracle 12C Release1 RAC și Galera 3.12 cluster pentru MariaDB 10.1.19.
Furnizori de identitate - autentificare socială
Este posibil să utilizați o autentificare din rețelele sociale. Pentru a activa capacitatea de a autentifica utilizatorii, utilizați consola de administrare Keycloack. Nu sunt necesare modificări ale codului aplicației, iar această funcționalitate este disponibilă imediat și poate fi activată în orice etapă a proiectului.
Este posibil să utilizați furnizorii de identitate OpenID/SAML pentru autentificarea utilizatorilor.
Scenarii tipice de autorizare folosind OAuth2 în Keycloak
Fluxul codului de autorizare - utilizat cu aplicații de pe partea serverului. Unul dintre cele mai comune tipuri de permisiuni de autorizare, deoarece este potrivit pentru aplicațiile server în care codul sursă al aplicației și datele clientului nu sunt disponibile pentru persoane din afară. Procesul în acest caz se bazează pe redirecționare. Aplicația trebuie să poată comunica cu un agent de utilizator (agent de utilizator), cum ar fi un browser web - pentru a primi coduri de autorizare API redirecționate prin agentul de utilizator.
flux implicit - utilizat de aplicații mobile sau web (aplicații care rulează pe dispozitivul utilizatorului).
Tipul de autorizare implicită este utilizat de aplicațiile mobile și web în care confidențialitatea clientului nu poate fi garantată. Tipul de permisiune implicită utilizează, de asemenea, redirecționarea agentului utilizator, prin care jetonul de acces este transmis agentului utilizator pentru utilizare ulterioară în aplicație. Acest lucru face ca tokenul să fie disponibil utilizatorului și altor aplicații de pe dispozitivul utilizatorului. Acest tip de permisiune de autorizare nu autentifică identitatea aplicației, iar procesul în sine se bazează pe o adresă URL de redirecționare (înregistrată anterior cu serviciul).
Implicit Flow nu acceptă jetoane de reîmprospătare a jetoanelor de acces.
Flux de acordare a acreditărilor clientului — sunt utilizate atunci când aplicația accesează API-ul. Acest tip de permisiune de autorizare este utilizat de obicei pentru interacțiunile server-la-server care trebuie efectuate în fundal fără interacțiunea imediată a utilizatorului. Fluxul de acordare a acreditărilor clientului permite unui serviciu web (client confidențial) să folosească propriile acreditări în loc să uzurpare identitatea unui utilizator pentru a se autentifica atunci când apelează un alt serviciu web. Pentru un nivel mai ridicat de securitate, este posibil ca serviciul de apelare să folosească un certificat (în loc de un secret partajat) ca autentificare.
Specificația OAuth2 este descrisă în
Jetonul JWT și beneficiile acestuia
JWT (JSON Web Token) este un standard deschis () care definește o modalitate compactă și autonomă de a transfera în siguranță informații între părți ca obiect JSON.
Conform standardului, jetonul este format din trei părți în format base-64, separate prin puncte. Prima parte se numește antet, care conține tipul de token și numele algoritmului hash pentru obținerea unei semnături digitale. A doua parte stochează informațiile de bază (utilizator, atribute etc.). A treia parte este semnătura digitală.
. .
Nu stocați niciodată un token în DB. Deoarece un token valid este echivalent cu o parolă, stocarea simbolului este ca și cum ar fi stocarea parolei în text clar.
Jeton de acces este un simbol care îi acordă proprietarului acces la resursele serverului securizate. De obicei, are o durată de viață scurtă și poate conține informații suplimentare, cum ar fi adresa IP a părții care solicită simbolul.
Jeton de reîmprospătare este un token care permite clienților să solicite noi token-uri de acces după ce durata lor de viață a expirat. Aceste jetoane sunt de obicei emise pentru o perioadă lungă de timp.
Principalele avantaje ale utilizării în arhitectura microservicii:
- Abilitatea de a accesa diverse aplicații și servicii prin autentificare unică.
- În absența unui număr de atribute necesare în profilul utilizatorului, este posibil să se îmbogățească cu date care pot fi adăugate la sarcina utilă, inclusiv automate și din mers.
- Nu este nevoie să stocați informații despre sesiunile active, aplicația server trebuie doar să verifice semnătura.
- Control mai flexibil al accesului prin atribute suplimentare în sarcina utilă.
- Utilizarea unei semnături de simbol pentru antet și încărcare utilă crește securitatea soluției în ansamblu.
Jeton JWT - compoziție
Titlu - în mod implicit, antetul conține doar tipul de token și algoritmul folosit pentru criptare.
Tipul jetonului este stocat în cheia „typ”. Tasta „type” este ignorată în JWT. Dacă este prezentă cheia „typ”, valoarea acesteia trebuie să fie JWT pentru a indica faptul că acest obiect este un JSON Web Token.
A doua cheie „alg” definește algoritmul folosit pentru a cripta jetonul. Ar trebui să fie setată implicit la HS256. Antetul este codificat în base64.
{ "alg": "HS256", "type": "JWT"}
sarcină utilă (conținut) - sarcina utilă stochează orice informație care trebuie verificată. Fiecare cheie din sarcina utilă este cunoscută ca „revendicare”. De exemplu, poți intra în aplicație doar prin invitație (promoție închisă). Când vrem să invităm pe cineva să participe, îi trimitem o scrisoare de invitație. Este important să verificați dacă adresa de e-mail aparține persoanei care acceptă invitația, așa că vom include această adresă în încărcătură, pentru aceasta o stocăm în cheia „e-mail”
{ "e-mail": "[e-mail protejat]"}
Cheile în sarcina utilă pot fi arbitrare. Cu toate acestea, există câteva rezervate:
- iss (Emitent) - Identifică aplicația de la care este trimis jetonul.
- sub (Subiect) - definește subiectul jetonului.
- aud (Audience) este o matrice de șiruri de caractere sau URI-uri care țin cont de majuscule și minuscule, care este o listă a destinatarilor acestui simbol. Când partea de primire primește un JWT cu cheia dată, trebuie să verifice prezența ei înșiși în destinatari - în caz contrar, ignorați jetonul.
- exp (Timp de expirare) - Indică când expiră jetonul. Standardul JWT cere ca toate implementările sale să respingă token-urile expirate. Cheia exp trebuie să fie un marcaj temporal în format Unix.
- nbf (Nu înainte) este un timp în format unix care determină momentul în care jetonul devine valid.
- iat (Emis la) - Această cheie reprezintă momentul în care a fost emis jetonul și poate fi folosită pentru a determina vârsta JWT. Cheia iat trebuie să fie un marcaj temporal în format Unix.
- Jti (JWT ID) — un șir care definește identificatorul unic al acestui token, ținând cont de majuscule și minuscule.
Este important de înțeles că sarcina utilă nu este transmisă în formă criptată (deși token-urile pot fi imbricate și apoi este posibil să se transmită date criptate). Prin urmare, nu poate stoca nicio informație secretă. La fel ca antetul, sarcina utilă este codificată base64.
Semnătură - când avem titlu și sarcină utilă, putem calcula semnătura.
Codificare Base64: antetul și sarcina utilă sunt preluate, sunt combinate într-un șir printr-un punct. Apoi acest șir și cheia secretă sunt introduse în algoritmul de criptare specificat în antet (cheia „alg”). Cheia poate fi orice șir. Corzile mai lungi vor fi cele mai preferate, deoarece ridicarea va dura mai mult.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Construirea unei arhitecturi de cluster de failover Keycloak
Când utilizați un singur cluster pentru toate proiectele, există cerințe crescute pentru o soluție SSO. Când numărul de proiecte este mic, aceste cerințe nu sunt atât de vizibile pentru toate proiectele, totuși, odată cu creșterea numărului de utilizatori și integrări, cerințele de disponibilitate și performanță cresc.
Creșterea riscului de eșec unic al SSO crește cerințele pentru arhitectura soluției și metodele utilizate pentru componentele redundante și duce la un SLA foarte strict. În acest sens, mai des în timpul dezvoltării sau etapelor incipiente de implementare a soluțiilor, proiectele au propria infrastructură care nu este tolerantă la erori. Pe măsură ce dezvoltarea progresează, este necesar să se creeze oportunități de dezvoltare și extindere. Cel mai flexibil este să construiți un cluster de failover folosind virtualizarea containerelor sau o abordare hibridă.
Pentru a funcționa în modurile de cluster Activ/Activ și Active/Pasive, este necesar să se asigure consistența datelor într-o bază de date relațională - ambele noduri de bază de date trebuie să fie replicate sincron între diferite centre de date geo-distribuite.
Cel mai simplu exemplu de instalare tolerantă la erori.
Care sunt beneficiile utilizării unui singur cluster:
- Disponibilitate și performanță ridicate.
- Suport pentru moduri de operare: Active / Active, Active / Pasive.
- Abilitatea de a scala dinamic - atunci când utilizați virtualizarea containerului.
- Posibilitate de gestionare și monitorizare centralizată.
- Abordare unificată pentru identificarea/autentificarea/autorizarea utilizatorilor în proiecte.
- Interacțiune mai transparentă între diferite proiecte fără implicarea utilizatorului.
- Abilitatea de a reutiliza simbolul JWT în diverse proiecte.
- Un singur punct de încredere.
- Lansare mai rapidă a proiectelor folosind microservicii/virtualizarea containerelor (nu este nevoie să ridicați și să configurați componente suplimentare).
- Este posibil să achiziționați suport comercial de la furnizor.
Ce să căutați atunci când planificați un cluster
SGBD
Keycloak folosește un sistem de gestionare a bazelor de date pentru a stoca: tărâmuri, clienți, utilizatori etc.
Este acceptată o gamă largă de SGBD: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak vine cu propria sa bază de date relațională încorporată. Se recomandă utilizarea pentru medii neîncărcate - cum ar fi mediile de dezvoltare.
Pentru a lucra în modurile de cluster Activ/Activ și Activ/Pasiv, este necesară consecvența datelor într-o bază de date relațională și ambele noduri ale clusterului de baze de date sunt replicate sincron între centrele de date.
Cache distribuită (Infinspan)
Pentru ca clusterul să funcționeze corect, este necesară o sincronizare suplimentară a următoarelor tipuri de cache folosind JBoss Data Grid:
Sesiuni de autentificare - utilizate pentru a salva date la autentificarea unui anumit utilizator. Solicitările din acest cache includ de obicei doar browserul și serverul Keycloak, nu aplicația.
Tokenurile de acțiune sunt folosite pentru scenariile în care utilizatorul trebuie să confirme o acțiune în mod asincron (prin e-mail). De exemplu, în timpul unui flux de uitare a parolei, cache-ul actionTokens Infinispan este folosit pentru a ține evidența metadatelor despre jetoanele de acțiune asociate care au fost deja utilizate, astfel încât nu pot fi reutilizate.
Memorarea în cache și invalidarea datelor persistente - utilizate pentru a stoca în cache datele persistente pentru a evita interogările inutile la baza de date. Când orice server Keycloak actualizează datele, toate celelalte servere Keycloak din toate centrele de date trebuie să știe despre acestea.
Lucru - Folosit numai pentru a trimite mesaje nevalide între nodurile clusterului și centrele de date.
Sesiuni utilizator - utilizate pentru a stoca date despre sesiunile utilizator care sunt valabile pe durata sesiunii de browser a utilizatorului. Cache-ul trebuie să proceseze solicitările HTTP de la utilizatorul final și de la aplicație.
Protecția forței brute - folosită pentru a urmări datele despre conectări eșuate.
Echilibrarea sarcinii
Echilibratorul de încărcare este singurul punct de intrare pentru keycloak și trebuie să accepte sesiuni sticky.
Servere de aplicații
Sunt folosite pentru a controla interacțiunea componentelor între ele și pot fi virtualizate sau containerizate folosind instrumente de automatizare existente și scalarea dinamică a instrumentelor de automatizare a infrastructurii. Cele mai comune scenarii de implementare în OpenShift, Kubernates, Rancher.
Aceasta se încheie prima parte - cea teoretică. În următoarea serie de articole vor fi analizate exemple de integrări cu diverși furnizori de identitate și exemple de setări.
Sursa: www.habr.com