In ogni grande cumpagnia, è X5 Retail Group ùn hè micca eccezzioni, cumu si sviluppa, u numeru di prughjetti chì necessitanu l'autorizazione di l'utilizatori aumenta. À u tempu, a transizione senza saldatura di l'utilizatori da una applicazione à l'altru hè necessaria, è dopu ci hè bisognu di utilizà un servitore Single-Sing-On (SSO). Ma chì succede quandu i fornituri d'identità cum'è AD o altri chì ùn anu micca attributi supplementari sò digià utilizati in diversi prughjetti. Una classa di sistemi chjamati "brokers d'identificazione" venerà in salvezza. U più funziunale sò i so rapprisentanti, cum'è Keycloak, Gravitee Access management, etc. A maiò spessu, i casi d'usu pò esse diffirenti: interazzione di machina, participazione di l'utilizatori, etc. A suluzione deve sustene a funziunalità flexible è scalabile chì ponu cumminà tutte e esigenze in una sola, è una tale suluzione in a nostra cumpagnia hè avà un indicatore broker - Keycloak.
Keycloak hè un pruduttu d'identità open source è cuntrollu di accessu mantinutu da RedHat. Hè a basa per i prudutti di a cumpagnia chì utilizanu SSO - RH-SSO.
Cuncetti basi
Prima di cumincià à trattà cù suluzioni è avvicinamenti, duvete decide in termini è sequenza di prucessi:
Identificazione hè una prucedura per ricunnosce un sughjettu cù u so identificatore (in altre parolle, questu hè a definizione di un nome, login o numeru).
Autenticazione - Questa hè una prucedura di autentificazione (l'utilizatore hè verificatu cù una password, a lettera hè verificata cù una firma elettronica, etc.)
Accedi - questu hè a prestazione di accessu à una risorsa (per esempiu, à e-mail).
Identity Broker Keycloak
chiavi hè una soluzione di gestione di l'identità è l'accessu open source pensata per l'usu in IS induve i mudelli di l'architettura di microserviziu ponu esse utilizati.
Keycloak offre funzioni cum'è Single Sign-on (SSO), identità mediata è login suciale, federazione d'utilizatori, adattatori di clientella, cunsola di amministrazione è cunsola di gestione di cunti.
Funzionalità basica supportata da Keycloak:
- Single-Sign On è Single-Sign Out per l'applicazioni di u navigatore.
- Supportu per OpenID/OAuth 2.0/SAML.
- Identity Brokering - autentificazione utilizendu OpenID Connect esterni o fornitori di identità SAML.
- Login suciale - Google, GitHub, Facebook, Twitter supportu per l'identificazione di l'utilizatori.
- User Federation - sincronizazione di l'utilizatori da i servitori LDAP è Active Directory è altri fornitori di identità.
- Ponte Kerberos - utilizendu un servitore Kerberos per l'autentificazione automatica di l'utilizatori.
- Admin Console - per una gestione unificata di paràmetri è opzioni di suluzione via Web.
- Account Management Console - per l'autogestione di u prufilu d'utilizatore.
- Personalizazione di a suluzione basatu annantu à l'identità corporativa di a cumpagnia.
- Autenticazione 2FA - Supportu TOTP / HOTP cù Google Authenticator o FreeOTP.
- Flussi di login - autoregistrazione di l'utilizatori, ricuperazione di password è resettate, è altri sò pussibuli.
- Gestione di sessione - l'amministratori ponu gestisce e sessioni d'utilizatori da un puntu unicu.
- Token Mappers - attributi di l'utilizatori, roli è altri attributi richiesti à i tokens.
- Gestione di pulitica flessibile in u regnu, l'applicazione è l'utilizatori.
- Support CORS - L'adattatori di clientella anu un supportu CORS integratu.
- Service Provider Interfaces (SPI) - Un gran numaru di SPI chì permettenu di persunalizà diversi aspetti di u servitore: flussi di autentificazione, fornitori di identità, mapping di protokollu, è più.
- Adattatori client per applicazioni JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Supportu per travaglià cù diverse applicazioni chì supportanu a libreria OpenID Connect Relying Party o SAML 2.0 Service Provider Library.
- Espandibile cù plugins.
Per i prucessi CI / CD, è ancu per l'automatizazione di i prucessi di gestione in Keycloak, l'API REST / JAVA API pò esse aduprata. A documentazione hè dispunibule elettronicamente:
REST API
API Java
Fornitori d'identità di l'impresa (on-premise)
Capacità di autentificà l'utilizatori attraversu i servizii di a Federazione di l'Utenti.
L'autentificazione pass-through pò ancu esse aduprata - se l'utilizatori si autentificanu contr'à stazioni di travagliu cù Kerberos (LDAP o AD), ponu esse autentificati automaticamente in Keycloak senza avè da inserisce novu u so nome d'utilizatore è a password.
Per l'autentificazione è l'autorizazione ulteriore di l'utilizatori, hè pussibule utilizà un DBMS relazionale, chì hè più appiecabile per l'ambienti di sviluppu, postu chì ùn implica micca longu paràmetri è integrazioni in i primi fasi di prughjetti. Per automaticamente, Keycloak usa un DBMS integratu per almacenà paràmetri è dati d'utilizatori.
A lista di DBMS supportati hè larga è include: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle è altri. I più pruvati finu à avà sò Oracle 12C Release1 RAC è Galera 3.12 cluster per MariaDB 10.1.19.
Fornitori d'identità - login suciale
Hè pussibule aduprà un login da e rete suciale. Per attivà a capacità di autentificà l'utilizatori, utilizate a cunsola di amministratore Keycloack. I cambiamenti in u codice di l'applicazione ùn sò micca necessariu è sta funziunalità hè dispunibule fora di a scatula è pò esse attivata in ogni stadiu di u prugettu.
Hè pussibule aduprà i fornitori d'identità OpenID / SAML per l'autentificazione di l'utilizatori.
Scenari d'autorizazione tipici chì utilizanu OAuth2 in Keycloak
Flussu di codice d'autorizazione - utilizatu cù l'applicazioni di u servitore. Unu di i tipi più cumuni di permessu d'autorizazione perchè hè bè adattatu per l'applicazioni di u servitore induve u codice fonte di l'applicazione è i dati di u cliente ùn sò micca dispunibili per i stranieri. U prucessu in questu casu hè basatu annantu à a redirezzione. L'applicazione deve esse capace di cumunicà cù un agente d'utilizatore (user-agent), cum'è un navigatore web - per riceve codici d'autorizazione API rediretti attraversu l'agente d'utilizatore.
flussu implicitu - utilizatu da l'applicazioni mobile o web (applicazioni in esecuzione nantu à u dispositivu di l'utilizatore).
U tipu di permessu d'autorizazione implicita hè utilizatu da l'applicazioni mobile è web induve a cunfidenziale di u cliente ùn pò esse garantita. U tipu di permessu implicitu usa ancu a redirezzione di l'agente di l'utilizatori, per quale u token d'accessu hè passatu à l'agente d'utilizatore per un usu più in l'applicazione. Questu rende u token dispunibule per l'utilizatore è altre applicazioni nantu à u dispositivu di l'utilizatore. Stu tipu di permessu d'autorizazione ùn autentifica micca l'identità di l'applicazione, è u prucessu stessu s'appoghja nantu à un URL di redirect (previamente registratu cù u serviziu).
Implicit Flow ùn sustene micca i token di rinfrescante di token d'accessu.
Flussu di cuncessione di credenziali di u cliente - sò usati quandu l'applicazione accede à l'API. Stu tipu di permessu d'autorizazione hè tipicamente utilizatu per l'interazzione di u servitore à u servitore chì deve esse realizatu in u fondu senza interazzione immediata di l'utilizatori. U flussu di cuncessione di credenziali di u cliente permette à un serviziu web (cliente cunfidenziale) di utilizà e so credenziali inveci di impersoning un utilizatore per autentificà quandu chjama un altru serviziu web. Per un livellu più altu di sicurità, hè pussibule per u serviziu di chjamà aduprà un certificatu (invece di un sicretu spartutu) cum'è credencial.
A specificazione OAuth2 hè descritta in
Token JWT è i so benefici
JWT (JSON Web Token) hè un standard apertu () chì definisce un modu compactu è autonomu per trasfiriri in modu sicuru l'infurmazioni trà partiti cum'è un oggettu JSON.
Sicondu u standard, u token hè custituitu di trè parti in formatu base-64, siparati da punti. A prima parte hè chjamata header, chì cuntene u tipu di token è u nome di l'algoritmu di hash per ottene una firma digitale. A seconda parte guarda l'infurmazioni basi (utilizatori, attributi, etc.). A terza parte hè a firma digitale.
. .
Ùn mai guardà un token in a vostra DB. Perchè un token validu hè equivalente à una password, almacenà u token hè cum'è almacenà a password in testu chjaru.
Token d'accessu hè un token chì dà u so pruprietariu accessu à e risorse di u servitore sicuru. Di solitu hà una vita curta è pò purtà infurmazioni supplementari cum'è l'indirizzu IP di u partitu chì dumanda u token.
Refresh token hè un token chì permette à i clienti di dumandà novi tokens d'accessu dopu chì a so vita hè scaduta. Questi tokens sò generalmente emessi per un longu periodu di tempu.
I vantaghji principali di l'usu in l'architettura di microserviziu:
- Capacità di accede à diverse applicazioni è servizii attraversu l'autentificazione una volta.
- In l'absenza di una quantità di attributi necessarii in u prufilu di l'utilizatori, hè pussibule arricchisce cù dati chì ponu esse aghjuntu à a carica utile, cumpresi l'automatizazione è a mosca.
- Ùn ci hè micca bisognu di almacenà l'infurmazioni nantu à e sessioni attive, l'applicazione di u servitore solu deve verificà a firma.
- Cuntrolu d'accessu più flessibile attraversu attributi supplementari in u payload.
- L'usu di una firma di token per l'intestazione è u payload aumenta a sicurità di a suluzione in tuttu.
JWT token - cumpusizioni
Header - per automaticamente, l'intestazione cuntene solu u tipu di token è l'algoritmu utilizatu per a criptografia.
U tipu di u token hè guardatu in a chjave "typ". A chjave "tipu" hè ignorata in u JWT. Se a chjave "typ" hè presente, u so valore deve esse JWT per indicà chì questu ughjettu hè un JSON Web Token.
A seconda chjave "alg" definisce l'algoritmu utilizatu per criptà u token. Deve esse stabilitu à HS256 per difettu. L'intestazione hè codificata in base64.
{ "alg": "HS256", "type": "JWT"}
carica (cuntenutu) - u payload guarda ogni infurmazione chì deve esse verificata. Ogni chjave in u payload hè cunnisciuta cum'è "reclamazione". Per esempiu, pudete entre in l'applicazione solu per invitu (promozione chjusa). Quandu vulemu invità à qualchissia per participà, li mandemu una lettera d'invitu. Hè impurtante di verificà chì l'indirizzu email appartene à a persona chì accetta l'invitu, cusì includemu questu indirizzu in u payload, per questu avemu guardatu in a chjave "email"
{ "email": "[email prutettu]"}
Chjavi in u payload pò esse arbitrariu. Tuttavia, ci sò uni pochi riservati:
- iss (Emittente) - Identifica l'applicazione da quale u token hè mandatu.
- sub (Subject) - definisce u sughjettu di u token.
- aud (Audience) hè un array di stringhe o URI sensible à u casu chì hè una lista di i destinatari di stu token. Quandu u latu di riceve riceve un JWT cù a chjave data, deve verificà a presenza di sè stessu in i destinatari - altrimenti ignurà u token.
- exp (Expiration Time) - Indica quandu u token scade. U standard JWT richiede tutte e so implementazioni per rifiutà i tokens scaduti. A chjave exp deve esse un timestamp in formatu Unix.
- nbf (Not Before) hè un tempu in formatu Unix chì determina u mumentu quandu u token diventa validu.
- iat (Issued At) - Questa chjave rapprisenta u tempu chì u token hè statu emessu è pò esse usatu per determinà l'età di u JWT. A chjave iat deve esse un timestamp in formatu Unix.
- Jti (JWT ID) - una stringa chì definisce l'identificatore unicu di stu token, sensible à u casu.
Hè impurtante di capisce chì u payload ùn hè micca trasmessu in forma criptata (ancu se i tokens ponu esse nidificati è hè pussibule di trasmette dati criptati). Dunque, ùn pò micca almacenà alcuna infurmazione secreta. Cum'è l'intestazione, a carica hè codificata in base64.
Signature - quandu avemu un titulu è una carica utile, pudemu calculà a firma.
Base64-coded: l'intestazione è u payload sò pigliati, sò cumminati in una stringa attraversu un puntu. Allora sta stringa è a chjave secreta sò input à l'algoritmu di criptografia specificatu in l'intestazione ("alg"). A chjave pò esse ogni stringa. E corde più lunghe seranu più preferite postu chì duverà più tempu per piglià.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Custruì un'architettura di cluster di failover Keycloak
Quandu si usa un cluster unicu per tutti i prughjetti, ci sò esigenze aumentate per una soluzione SSO. Quandu u nùmeru di prughjetti hè chjuca, queste esigenze ùn sò micca cusì notevuli per tutti i prughjetti, in ogni modu, cù un aumentu di u numeru di utilizatori è integrazioni, i requisiti per a dispunibilità è u rendiment aumentanu.
Aumentà u risicu di fallimentu SSO unicu aumenta i requisiti per l'architettura di suluzione è i metudi utilizati per i cumpunenti ridondanti è porta à un SLA assai strettu. In questu sensu, più spessu durante u sviluppu o i primi stadi di implementazione di suluzioni, i prughjetti anu a so propria infrastruttura non-fault-tolerant. Quandu u sviluppu avanza, hè necessariu di stabilisce opportunità per u sviluppu è a scala. Hè più flessibile per custruisce un cluster di failover utilizendu a virtualizazione di u containeru o un approcciu hibridu.
Per travaglià in i modi di cluster Active / Active è Active / Passive, hè necessariu di assicurà a coerenza di dati in una basa di dati relazionale - i dui nodi di basa di dati devenu esse replicati in modu sincronu trà i diversi centri di dati geo-distribuiti.
L'esempiu più simplice di una stallazione tolerante à i difetti.
Chì sò i vantaghji di utilizà un cluster unicu:
- Alta dispunibilità è prestazione.
- Supportu per i modi operativi: Active / Active, Active / Passive.
- Capacità di scala dinamicamente - quandu si usa a virtualizazione di u containeru.
- Possibilità di gestione è surviglianza centralizata.
- Approcciu unificatu per l'identificazione / autentificazione / auturizazione di l'utilizatori in i prughjetti.
- Interazione più trasparente trà e diverse prughjetti senza implicazione di l'utilizatori.
- A capacità di riutilizà u token JWT in diversi prughjetti.
- Puntu unicu di fiducia.
- Lanciamentu più veloce di prughjetti chì utilizanu microservizi / virtualizazione di cuntainer (ùn hè bisognu di elevà è cunfigurà cumpunenti supplementari).
- Hè pussibule cumprà supportu cummerciale da u venditore.
Cosa à circà quandu si pianificà un cluster
DBMS
Keycloak usa un sistema di gestione di basa di dati per almacenà: regni, clienti, utilizatori, etc.
Una larga gamma di DBMS hè supportata: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak vene cù a so propria basa di dati relazionale integrata. Hè cunsigliatu à aduprà per ambienti micca caricati - cum'è ambienti di sviluppu.
Per travaglià in i modi di cluster Active / Active è Active / Passive, a coerenza di dati in una basa di dati relazionale hè necessaria, è i dui nodi di cluster di basa di dati sò replicati sincronicamente trà i centri di dati.
Cache distribuita (Infinspan)
Per chì u cluster funziunà bè, hè necessaria una sincronizazione supplementaria di i seguenti tipi di cache chì utilizanu JBoss Data Grid:
Sessioni di autentificazione - utilizatu per salvà dati quandu autentificà un utilizatore specificu. E dumande da questa cache includenu solu u navigatore è u servitore Keycloak, micca l'applicazione.
I tokens d'azzione sò usati per scenarii induve l'utilizatore hà bisognu di cunfirmà una azione in modu asincronu (via email). Per esempiu, durante un flussu di password scurdate, u cache actionTokens Infinispan hè utilizatu per guardà i metadati nantu à i tokens d'azzione assuciati chì sò digià stati utilizati, perchè ùn pò micca esse riutilizzati.
Cache è invalidazione di dati persistenti - utilizatu per cache dati persistenti per evità dumande innecessarii à a basa di dati. Quandu qualsiasi servitore Keycloak aghjurnà i dati, tutti l'altri servitori Keycloak in tutti i centri di dati anu bisognu di sapè.
U travagliu - Adupratu solu per mandà missaghji invalidi trà i nodi di cluster è i centri di dati.
Sessioni d'utilizatori - utilizati per almacenà dati nantu à e sessioni d'utilizatori chì sò validi per a durata di a sessione di u navigatore di l'utilizatori. A cache deve processà e richieste HTTP da l'utilizatori finali è l'applicazione.
Prutezzione di forza bruta - utilizata per seguità i dati nantu à i logins falluti.
Equilibratu di carica
U bilanciatore di carica hè u puntu d'entrata unicu à u keycloak è deve sustene e sessioni appiccicose.
Servitori di Applicazioni
Sò usati per cuntrullà l'interazzione di cumpunenti cù l'altri è ponu esse virtualizzati o cuntainerizati cù l'arnesi d'automatizazione esistenti è a scala dinamica di l'automatizazione di l'infrastruttura. I scenarii di implementazione più cumuni in OpenShift, Kubernates, Rancher.
Questu cuncludi a prima parte - quella teorica. In a prossima serie di articuli, esempi di integrazioni cù diversi fornitori di identità è esempi di paràmetri seranu analizati.
Source: www.habr.com