Ce este Keycloak și cum se instalează pas cu pas

Aproape fiecare aplicație modernă pe care o utilizați zilnic (e-mail, rețele sociale, intranet corporativ, tablouri de bord pentru clienți etc.) are un sistem în culise care decide cine sunteți și ce puteți accesa. Atunci când companiile încep să acumuleze aplicații, servicii și API-uri, gestionarea manuală a utilizatorilor, parolelor, permisiunilor și sesiunilor devine o adevărată bătaie de cap.

Keycloak este util pentru a rezolva această problemă : este o platformă de gestionare a identității și accesului care centralizează autentificarea, autorizarea și autentificarea unică pentru mai multe aplicații. În loc ca fiecare aplicație să implementeze propriul sistem de autentificare, roluri și recuperare a parolei, Keycloak gestionează toate acestea, iar aplicațiile se bazează pur și simplu pe acesta folosind standarde precum OAuth 2.0, OpenID Connect sau SAML 2.0.

Ce este Keycloak și ce rol joacă în securitatea IAM?

Keycloak este un furnizor de identitate (IdP) open-source, scris în Java și întreținut de Red Hat (fostul JBoss), licențiat sub Apache 2.0, deci poate fi utilizat și adaptat liber chiar și în medii comerciale. Există o versiune plătită, la nivel de întreprindere, numită Red Hat Single Sign-On, dar funcționalitatea de bază este aceeași.

Acest server de identitate oferă SSO, federație și multi-tenancy : permite unui utilizator să se conecteze o singură dată și să acceseze mai multe aplicații, ca acele aplicații să delege autentificarea către Keycloak și ca gestionarea utilizatorilor, grupurilor, atributelor și permisiunilor să se facă centralizat, fără a reimplementa roata în fiecare proiect.

Keycloak se diferențiază de alte soluții IAM (gratuite, open source sau proprietare) datorită maturității, ratei de adopție și compatibilității cu protocoalele standard. Chiar și așa, soluția potrivită pentru fiecare organizație va depinde de nevoile acesteia (suport comercial, SLA-uri, funcționalități specifice, implementare locală versus SaaS etc.).

Unul dintre punctele forte ale Keycloak este acela că combină mai multe componente: autentificare bazată pe OAuth 2.0 și OpenID Connect, suport SAML 2.0, autentificare socială ( Google , Facebook , GitHub etc.), integrare cu LDAP și Active Directory, administrare prin consolă web, CLI și REST API, precum și un model flexibil de utilizatori, grupuri și roluri care se reflectă în token-urile emise pentru aplicații.

Fundamente necesare: OAuth 2.0, OpenID Connect și JWT

Pentru a înțelege pe deplin ce face Keycloak, este util să înțelegem trei concepte cheie : OAuth 2.0, OpenID Connect (OIDC) și JSON Web Tokens (JWT). Nu trebuie să fii expert, dar înțelegerea ideilor generale este esențială, deoarece totul se învârte în jurul lor.

OAuth 2.0 ca și cadru de autorizare

OAuth 2.0 este un cadru standard de autorizare API utilizat de giganți precum Google, Facebook, Microsoft, GitHub și LinkedIn. Funcția sa principală este de a permite unei aplicații (client) să acceseze resursele unui utilizator dintr-o altă aplicație sau API, cu permisiunea explicită a utilizatorului, fără a partaja constant acreditările.

În loc să trimită un nume de utilizator și o parolă la fiecare solicitare , OAuth 2.0 introduce conceptul de token de acces: un token de acces cu durată scurtă de viață trimis odată cu apelurile HTTP către API, care este apoi validat de API. IdP-ul (cum ar fi Keycloak) emite acest token după verificarea identității și a consimțământului utilizatorului.

Standardul definește mai multe fluxuri de autorizare (tipuri de granturi) pentru a adapta procesul la tipul de client: aplicații backend securizate, SPA-uri bazate pe browser, aplicații mobile , dispozitive limitate, comunicații machine-to-machine etc. Fiecare flux specifică ce se schimbă la fiecare pas (coduri de autorizare, token-uri, acreditări etc.).

Cele patru roluri fundamentale ale OAuth 2.0 sunt:

• Proprietarul resurselor: de obicei utilizatorul ale cărui date doriți să le consultați sau să le modificați.
• Clientaplicația (web, mobilă, IoT, backend…) care dorește să acționeze în numele utilizatorului.
• server de resurse: API-ul care expune datele și validează token-urile de acces.
• Server de autorizareIdP-ul (Keycloak) care autentifică utilizatorul și emite token-uri.

În plus, OAuth 2.0 introduce conceptul de domenii de aplicare , care definesc gradul de permisiune pe care utilizatorul îl acordă aplicației: citirea e-mailurilor, postarea pe o rețea socială, accesarea unui profil de bază etc. Tokenul emis codifică permisiunile care au fost efectiv acordate clientului.

OpenID Connect: un strat de identitate peste OAuth 2.0

OpenID Connect (OIDC) adaugă identitate la OAuth 2.0 . În timp ce OAuth se ocupă de autorizare (ce poate face o aplicație), OIDC se concentrează pe identificarea, într-un mod standardizat, a utilizatorului autentificat și a modului de obținere a datelor sale de bază.

OIDC definește endpoint-uri și metadate bine cunoscute, cum ar fi documentul de descoperire publicat pe rută /.well-known/openid-configuration unde furnizorul specifică adrese URL de autorizare, token-uri, chei publice, informații despre utilizator etc. Acest lucru permite configurarea aproape automată a aplicațiilor.

De asemenea, oferă endpoint-ul UserInfo , care este utilizat pentru a recupera informații despre utilizatorul autentificat (nume, e-mail etc.) folosind un token de acces valid. Este foarte comun în integrările bazate pe Keycloak să se citească aceste date după autentificare pentru a popula profilurile de utilizator în aplicație.

Access_token și jetoane web JSON (JWT)

În multe implementări moderne, token-ul de acces este un JWT (JSON Web Token). Acesta este un standard (RFC 7519) pentru reprezentarea revendicărilor ca JSON semnate digital, în trei părți separate prin puncte: antet, payload și semnătură, toate codificate în URL Base64.

Antetul indică informații tehnice despre token. (algoritmul de semnătură, tipul de token și adesea identificatorul cheii utilizate, kidSarcina utilă conține revendicările, cum ar fi:

• exp: data expirării.
• IAT: ora emisiunii.
• iss: emitent, de obicei adresa URL a IdP-ului.
• sub: identificator unic de utilizator.
• aud: publicul căruia îi este direcționat token-ul.
• jti: identificatorul unic al token-ului.

Semnătura este generată cu o cheie privată sau secretă.Prin urmare, orice modificare a token-ului rupe semnătura și este detectată în timpul validării. API-ul obține cheia publică de la IdP datorită proprietății jwks_uri din documentul de descoperire, care indică un fișier JSON care conține lista cheilor publice și a acestora kid.

Keycloak permite, de asemenea, personalizarea token-urilor emise : se pot adăuga revendicări suplimentare pe baza atributelor utilizatorului, a grupurilor, a rolurilor sau chiar a valorilor fixe. Acest lucru se realizează folosind mapper-e configurate per client sau per domeniu de aplicare al clientului, asigurându-se că API-urile primesc exact informațiile de care au nevoie.

Arhitectura Keycloak: Tărâmuri, Utilizatori, Grupuri și Roluri

Keycloak își organizează configurația în Realms (Regimi) , care sunt ca niște „servere de identitate virtuală” în cadrul unei singure instalări. Alți furnizori numesc ceva similar chiriaș sau director. Fiecare regie are proprii utilizatori, grupuri, clienți, politici și setări independente.

În mod implicit, există o zonă specială numită master , care ar trebui rezervată pentru sarcini administrative globale, cum ar fi crearea și gestionarea altor zone. Utilizatorul administrator poate gestiona mai multe zone din aceeași consolă fără a fi nevoie să se conecteze cu conturi diferite pentru fiecare dintre ele.

Într-o zonă de control (realm), puteți defini utilizatori locali , le puteți atribui atribute personalizate, îi puteți grupa și îi puteți lega de roluri. Modelul este conceput astfel încât informațiile relevante să fie reflectate în token-urile consumate de aplicație (roluri, grupuri, date de profil, semnalizatoare de securitate etc.).

Grupurile vă permit să organizați utilizatorii ierarhic : un grup poate avea subgrupuri (copii), iar un utilizator moștenește atributele și rolurile tuturor grupurilor din care face parte, inclusiv ale părinților. Acest lucru permite modele de autorizare extrem de flexibile, fără a fi nevoie să repetați configurațiile pentru fiecare utilizator.

În ceea ce privește rolurile, există două niveluri principale :

• Roluri în tărâm: valori globale în cadrul domeniului, utilizate mult pentru permisiuni între proprietăți.
• Roluri de client: specific unei anumite aplicații, permițând o granularitate fină pentru fiecare serviciu.

Keycloak acceptă roluri compozite , adică roluri care includ alte roluri. Acest lucru ajută la gruparea permisiunilor și la atribuirea lor simultană utilizatorilor sau grupurilor, deși este recomandat să nu îl utilizați excesiv pentru a evita complicarea administrării sau afectarea performanței.

Instalarea Keycloak în modul de dezvoltare: Docker, Kubernetes și VM

Pentru a configura un mediu de laborator cu Keycloak există mai multe opțiuni simple: container Docker, implementare în Kubernetes (de exemplu cu Minikube) sau instalare clasică într-o mașină virtuală cu Linux și OpenJDK.

Keycloak în Docker

Cea mai rapidă metodă de a porni Keycloak pentru testare Implică rularea unui container cu imaginea oficială, expunerea portului 8080 și transmiterea numelui de utilizator și a parolei de administrator prin variabile de mediu, pornirea în modul start-dev (fără HTTPS și cu bază de date H2 încorporată):

Cu o singură comandă Docker se obține un server funcțional în http://localhost:8080, suficient pentru a juca cu consola de administrare, a crea realm-uri, utilizatori, clienți și a testa integrări de bază.

Keycloak în Kubernetes cu Minikube

Dacă deja lucrezi cu Kubernetes, poți implementa cu ușurință Keycloak folosind manifestele de probă din depozitul oficial. Creezi o implementare și un serviciu, apoi deschizi un tunel cu Minikube pentru a accesa serviciul de pe mașina ta, de obicei din nou pe portul 8080.

Această abordare este ideală pentru simularea unor medii mai apropiate de producție (cu pod-uri, servicii, configurații externe etc.) și pentru experimentarea cu implementări controlate, scalare și upgrade-uri ale Keycloak pe clustere K8s.

Keycloak pe Ubuntu cu OpenJDK și PostgreSQL (mod avansat dev)

O altă posibilitate este configurarea Keycloak pe o mașină virtuală Ubuntu folosind OpenJDK și o bază de date PostgreSQL locală, cu un certificat autosemnat și un nume de gazdă personalizat. Deși este încă un scenariu de testare, este mai aproape de o topologie de producție.

Pașii tipici includ :

• Actualizați sistemul de operare și instalați Java (de exemplu, OpenJDK 11 sau o versiune ulterioară).
• Instalați PostgreSQL (în mod ideal pe un server separat, deși într-un laborator poate fi pe aceeași mașină).
• Creați un utilizator și o bază de date specifice pentru Keycloak și acordați-i privilegiile corespunzătoare.
• Creați un utilizator de sistem fără privilegii (de exemplu, keycloak) pentru a rula serviciul.
• Descărcați distribuția oficială Keycloak, dezarhivați-o în /opt/keycloak și ajustați permisiunile.
• Generați un certificat X.509 autosemnat cu OpenSSL și puneți-l în keycloak.conf împreună cu parametrii de conexiune PostgreSQL și hostname dorit.
• Definiți o unitate systemd Pentru a porni Keycloak în modul de dezvoltare la pornirea sistemului, setați acreditările de administrator prin intermediul variabilelor de mediu.

Odată ce serviciul rulează , acesta este accesat de obicei prin HTTPS pe portul 8443 folosind numele de gazdă configurat. Dacă se utilizează un certificat autosemnat, acesta va trebui să fie considerat de încredere în browser (prin importarea CA-ului sau a certificatului în sine în depozitul de certificate de încredere al mașinii).

Implementări avansate: disponibilitate ridicată, PostgreSQL și proxy invers

Când trecem de la laborator la producție , imaginea se schimbă: trebuie să ne gândim la disponibilitate ridicată, persistență robustă a datelor, certificate valide și, adesea, un proxy invers care centralizează accesul HTTPS și echilibrarea încărcării.

Un model destul de comun este implementarea mai multor noduri Keycloak în spatele unui echilibrator de încărcare (cum ar fi Nginx) și utilizarea unei baze de date PostgreSQL în modul de disponibilitate ridicată ca backend de persistență. Scopul este de a elimina punctele unice de eroare atât pentru stratul de aplicație, cât și pentru cel de date.

În acest tip de arhitectură, se parcurg de obicei pași precum următorii :

• Pregătiți serverele Linux actualizate (Debian/Ubuntu) și instalați dependențele: unzip, wget, openjdk, openssl, Etc
• Creați un utilizator de sistem keycloak cu casă înăuntru /opt/keycloak și fără permisiuni de conectare interactivă privilegiate.
• Descărcați versiunea dorită de Keycloak, dezarhivați-o și atribuiți proprietatea utilizatorului dedicat.
• Creați o bază de date specifică în PostgreSQL, cu utilizatorul și privilegiile corespunzătoare, ajustând și proprietarul schemei și permisiunile implicite pentru tabele.
• Generați certificate autosemnate (sau utilizați certificate de la o CA internă) pentru nodurile Keycloak și configurați HTTPS pe serverul de aplicații.
• Regla keycloak.conf Pentru a vă conecta la VIP-ul PostgreSQL, definiți porturile HTTP/HTTPS, certificatele, parametrii proxy, numele de gazdă, stiva de cluster (de exemplu, UDP) și nivelurile de jurnalizare.
• Definiți un serviciu systemd simplu că cizmă Cheie cu kc.sh start o kc.sh start --optimizedgestionarea repornirilor automate în caz de defecțiuni.

Pe stratul de publicare și echilibrare a încărcării, Nginx este de obicei implementat ca un proxy invers HTTPS, cu propriul certificat TLS și o configurație upstream care indică nodurile Keycloak pe porturile lor backend (de obicei 8080 dacă TLS este terminat în Nginx).

Pentru a elimina punctele unice de eroare în echilibratorul de încărcare , este obișnuit să configurați două noduri Nginx în stare de disponibilitate ridicată folosind Keepalived. Acest instrument gestionează o adresă IP virtuală flotantă (VIP) care este promovată pe unul dintre servere ca master și, în caz de eroare, comută la nodul de rezervă, menținând continuitatea serviciului.

Configurarea înregistrării unui domeniu, utilizatorilor și aplicației (clientului)

După ce Keycloak este configurat și funcționează, următorul pas logic este să creăm o zonă pentru utilizatorii și aplicațiile noastre și, de acolo, să definim utilizatori, grupuri, roluri și clienți (aplicațiile care vor delega autentificarea către Keycloak).

Din Consola de administrare, creați o nouă zonă pur și simplu introducând numele acesteia. Din acel moment, veți avea un spațiu izolat cu propriile setări. Printre primele setări, următoarele sunt de obicei utile:

• Configurați SMTP pentru trimiterea de e-mailuri (verificare e-mail, recuperare parolă, notificări).
• Activați dacă doriți Profil de utilizator declarativ, care vă permite să definiți în mod declarativ ce atribute va avea un utilizator, ce validări se aplică și dacă acestea pot fi editate de către utilizator.
• Ajustați parametrii de conectare: permiteți sau dezactivați auto-înregistrarea, memorați sesiunea între repornirile browserului, permiteți recuperarea parolei etc.

Crearea unui utilizator într-o zonă este la fel de simplă ca completarea unui formular cu un nume de utilizator, o adresă de e-mail, un prenume și un nume de familie. Apoi, setezi parola acestuia (temporară sau permanentă) din fila de acreditări. De acolo, îi poți atribui grupuri, roluri și atribute suplimentare.

Keycloak oferă o Consolă de cont dedicată utilizatorilor finali , unde aceștia își pot vizualiza și modifica datele de profil, își pot schimba parola, pot revizui sesiunile active și pot gestiona factori de autentificare suplimentari. Este o modalitate foarte convenabilă de a delega utilizatorului o parte din administrarea de bază a contului.

Impersonarea este o altă caracteristică interesantă : un administrator cu permisiuni poate „impersona” un utilizator din consolă pentru a reproduce probleme, a verifica permisiunile etc., fără a fi nevoie de parola utilizatorului.

Pentru ca o aplicație să utilizeze Keycloak ca IdP , aceasta trebuie să fie înregistrată ca și client. În secțiunea Clienți, se creează un nou ID de client, tipul este specificat ca OpenID Connect (cu excepția cazului în care se utilizează SAML) și se selectează fluxurile OAuth 2.0 permise: Flux standard (cod de autorizare), Acorduri de acces direct (parolă), Implicit, Acreditări client (conturi de serviciu), Cod dispozitiv, CIBA etc.

Configurația clientului determină, de asemenea, dacă este necesară autentificarea clientului (secret client sau certificate), ce URI-uri de redirecționare sunt valide și ce origini web sunt permise (foarte important în SPA-uri datorită politicilor CORS). De acolo, aplicația poate utiliza biblioteci oficiale sau terțe pentru a delega autentificarea către Keycloak prin OIDC.

Integrare cu directoare externe și alți furnizori de identitate

Keycloak poate funcționa ca o sursă locală de identități (utilizatori, grupuri și roluri definite în propria bază de date) sau poate acționa ca un broker de identități pentru unul sau mai mulți furnizori externi.

O integrare foarte comună este cu Azure Active Directory : Azure AD stochează utilizatorii și grupurile corporative, iar Keycloak se conectează ca un client OIDC pentru a descărca identități și grupuri, mapându-le la utilizatorii și rolurile locale. Acest lucru evită duplicarea identităților și a sarcinilor administrative pe mai multe site-uri.

În termeni generali, pentru a utiliza Azure AD ca IdP extern, faceți următoarele:

• Înregistrați o aplicație în Azure AD, obțineți ID-ul clientului acesteia și creați un secret client.
• Configurați în Azure AD URI-urile de redirecționare către Keycloak (punctul final al brokerului OIDC în realmul corespunzător).
• Ajustați revendicările care vor fi emise în token în aplicația Azure AD, de exemplu, prin includerea grupurilor de utilizatori.
• În Keycloak, creați un furnizor de identitate OpenID Connect care să indice punctele finale Azure (autorizare, token, deconectare, informații utilizator) și să configurați ID-ul clientului, secretul clientului și parametrii de conectare doriți.

Odată ce se stabilește încrederea între cele două , când un utilizator se conectează prin Azure AD, Keycloak creează (sau sincronizează) utilizatorul local și poate mapa grupuri Azure la roluri Keycloak folosind mapper-uri avansate. De exemplu, grupul „Dezvoltatori” din Azure poate fi tradus în rolul „Dezvoltatori” din Keycloak, care va fi apoi implementat în aplicații și servicii integrate (cum ar fi Jenkins).

Pe lângă Azure AD, Keycloak vă permite să federați identități cu LDAP, Active Directory clasic, alți IdP-uri OIDC, furnizori de rețele sociale (Google, Facebook, GitHub etc.) și multe altele, permițându-vă să combinați mai multe surse simultan în aceeași zonă.

Securitate suplimentară: roboți, CAPTCHA și cele mai bune practici

Deși Keycloak consolidează considerabil securitatea în autentificare (MFA, politici de parolă, blocarea contului, controlul sesiunilor etc.), paginile de conectare, înregistrare și recuperare a parolei rămân ținte clare pentru roboți și atacuri automate.

Pentru a atenua aceste tipuri de amenințări , se recomandă combinarea Keycloak cu mecanisme anti-boți, cum ar fi soluțiile CAPTCHA conforme cu GDPR, care fac distincția între traficul uman și cel automat, fără a compromite experiența utilizatorului. Aceste soluții sunt de obicei integrate în formularele de conectare și înregistrare, adăugând un nivel suplimentar de apărare împotriva atacurilor de tip „credential stuffing”, a creării în masă de conturi sau a abuzului de fluxuri de recuperare a parolelor.

Dincolo de CAPTCHA, alte bune practici includ monitorizarea jurnalelor de acces , configurarea alertelor pentru creșteri anormale ale încercărilor eșuate, revizuirea periodică a token-urilor emise și a duratei acestora, asigurarea că doar endpoint-urile necesare sunt expuse la exterior și menținerea Keycloak și a dependențelor sale actualizate cu cele mai recente patch-uri de securitate.

Întregul ecosistem de funcționalități (SSO, multi-tenancy, integrare cu directoare externe, token-uri configurabile, implementări de înaltă disponibilitate și protecție împotriva roboților) face din Keycloak un instrument foarte puternic pentru centralizarea autentificării și autorizării aplicațiilor moderne, ajutând companiile să își consolideze postura de securitate fără a sacrifica experiența utilizatorului sau a reinventa continuu gestionarea identităților.