In qualsiasi grande azienda, anche X5 Retail Group non fa eccezione, con il progresso aumentano i progetti che richiedono l'autenticazione degli utenti. Nel tempo, si rende necessario un passaggio fluido degli utenti da un'applicazione all'altra e sorge quindi la necessità di utilizzare un server Single Sign-On (SSO) unificato. Ma cosa fare quando provider di identità come AD o altri, privi di attributi aggiuntivi, sono già utilizzati in vari progetti? A questo punto interviene una classe di sistemi chiamata «broker di identità». I rappresentanti più funzionali sono quelli come Keycloak, Gravitee Access Management e altri. Le scenografie di utilizzo possono variare: interazione tra macchine, coinvolgimento degli utenti, ecc. La soluzione deve supportare funzionalità flessibili e scalabili, in grado di unire tutte le esigenze in un'unica piattaforma, e attualmente la nostra soluzione aziendale è il broker di identità – Keycloak.
Keycloak è un prodotto open source progettato per l'identificazione e il controllo degli accessi, supportato da RedHat. È la base per i prodotti dell'azienda che utilizzano SSO – RH-SSO.
Concetti di base
Prima di iniziare a esplorare soluzioni e approcci, è necessario chiarire i termini e la sequenza dei processi:
Identificazione è la procedura di riconoscimento di un soggetto tramite il suo identificatore (in parole semplici, questo significa determinare il nome, il login o il numero).
Autenticazione è la procedura di autenticazione (l'utente viene verificato tramite una password, un'email viene controllata tramite firma elettronica, ecc.)
Autenticazione è il processo di concessione dell'accesso a una risorsa (ad esempio, a un'email).
Il broker di identificazione Keycloak
Keycloak è una soluzione open source per la gestione dell'identità e degli accessi, progettata per l'uso in sistemi informatici in cui possono essere impiegati modelli di architettura a microservizi.
Keycloak offre funzionalità come accesso unico (SSO), broker di identità e accesso sociale, federazione utenti, adattatori client, console di amministrazione e console di gestione degli account.
Funzionalità di base supportate in Keycloak:
- Single Sign-On e Single Sign-Out per applicazioni web.
- Supporto per OpenID/OAuth 2.0/SAML.
- Identity Brokering – autenticazione tramite provider di identità esterni OpenID Connect o SAML.
- Accesso sociale – supporto per Google, GitHub, Facebook, Twitter per l'identificazione degli utenti.
- Federazione utenti – sincronizzazione degli utenti da server LDAP e Active Directory e altri provider di identità.
- Kerberos bridge – utilizzo del server Kerberos per l'autenticazione automatica degli utenti.
- Admin Console – per la gestione centralizzata delle impostazioni e delle configurazioni della soluzione tramite web.
- Account Management Console – per la gestione autonoma del profilo degli utenti.
- Personalizzazione della soluzione in base all'identità aziendale.
- Autenticazione 2FA – supporto TOTP/HOTP tramite Google Authenticator o FreeOTP.
- Login Flows – possibilità di auto-registrazione degli utenti, recupero e reset della password e altre opzioni.
- Gestione delle sessioni – gli amministratori possono gestire le sessioni degli utenti da un'unica interfaccia.
- Token Mappers – associamento degli attributi utenti, dei ruoli e di altri attributi richiesti ai token.
- Gestione flessibile delle politiche tramite realm, applicazioni e utenti.
- Supporto CORS – gli adattatori client hanno il supporto CORS integrato.
- Interfacce del fornitore di servizi (SPI) – un ampio numero di SPI consente di configurare vari aspetti del funzionamento del server: flussi di autenticazione, provider di identità, mappature di protocollo e molto altro.
- Adattatori client per applicazioni JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Supporto per l'interazione con diverse applicazioni che utilizzano la libreria OpenID Connect Relying Party o la libreria SAML 2.0 Service Provider.
- Possibilità di estensione tramite plugin.
Per i processi CI/CD e per l'automazione della gestione in Keycloak, è possibile utilizzare le API REST/JAVA. La documentazione è disponibile in formato elettronico:
REST API
API JAVA
Provider di identità a livello aziendale (On-Premise)
Possibilità di autenticazione degli utenti tramite servizi di User Federation.
È possibile utilizzare anche l'autenticazione silos — se gli utenti si autenticano sulle stazioni di lavoro con Kerberos (LDAP o AD), possono essere automaticamente autenticati su Keycloak senza dover reinserire nome utente e password.
Per l'autenticazione e la successiva autorizzazione degli utenti è possibile utilizzare un database relazionale, il che è particolarmente utile per gli ambienti di sviluppo, poiché non richiede configurazioni e integrazioni lunghe nelle fasi iniziali dei progetti. Per impostazione predefinita, Keycloak utilizza un database integrato per memorizzare le impostazioni e i dati degli utenti.
L'elenco dei database supportati è ampio e include: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle e altri. I più testati fino ad oggi sono Oracle 12C Release1 RAC e il cluster Galera 3.12 per MariaDB 10.1.19.
Provider di identità — accesso sociale
È possibile utilizzare l'accesso tramite social network. Per attivare la possibilità di autenticare gli utenti, si utilizza la console di amministrazione Keycloak. Non è necessario apportare modifiche al codice delle applicazioni, e questa funzionalità è disponibile "out of the box" e può essere attivata in qualsiasi fase di implementazione del progetto.
Per l'autenticazione degli utenti è possibile utilizzare fornitori di identità OpenID/SAML.
Scenari tipici di autorizzazione utilizzando OAuth2 in Keycloak
Authorization Code Flow — utilizzato con applicazioni server-side. Uno dei tipi più comuni di autorizzazione, poiché è ben adatto per le applicazioni server, in cui il codice sorgente dell'applicazione e i dati del cliente non sono accessibili a terzi. In questo caso, il processo si basa sul reindirizzamento. L'applicazione deve essere in grado di interagire con l'agente utente, come un browser web, per ricevere codici di autorizzazione API reindirizzati attraverso l'agente utente.
Implicit Flow — utilizzato da applicazioni mobili o web (applicazioni in esecuzione sul dispositivo dell'utente).
Il tipo di autorizzazione implicita è utilizzato da applicazioni mobili e web, dove non può essere garantita la privacy del cliente. Il tipo di autorizzazione implicita utilizza anche il reindirizzamento dell'agente utente, in cui il token di accesso viene passato all'agente utente per un ulteriore utilizzo nell'applicazione. Questo rende il token accessibile all'utente e ad altre applicazioni sul dispositivo dell'utente. Con questo tipo di autorizzazione non viene effettuata autenticazione dell'applicazione, e l'intero processo si basa sull'URL di reindirizzamento (registrato in precedenza nel servizio).
Il Flusso Implicito non supporta i token di aggiornamento del token di accesso (refresh tokens).
Flusso Client Credentials Grant — vengono utilizzati quando un'applicazione accede a un'API. Questo tipo di autorizzazione è generalmente usato per interazioni "server-server", che devono essere eseguite in background senza un'interazione immediata con l'utente. Il flusso di fornitura delle credenziali del cliente consente a un servizio web (cliente riservato) di utilizzare le proprie credenziali invece di un'identità dell'utente per l'autenticazione quando richiama un altro servizio web. Per un livello di sicurezza più elevato, il servizio chiamante può utilizzare un certificato (anziché un segreto condiviso) come credenziali.
La specifica OAuth2 è descritta in
Token JWT e i suoi vantaggi
JWT (JSON Web Token) — uno standard aperto (), che definisce un modo compatto e autonomo per la trasmissione sicura di informazioni tra le parti sotto forma di oggetto JSON.
Secondo lo standard, il token è composto da tre parti in formato base-64, separate da punti. La prima parte è chiamata intestazione (header), che contiene il tipo di token e il nome dell'algoritmo di hash utilizzato per generare la firma digitale. La seconda parte contiene le informazioni principali (utente, attributi, ecc.). La terza parte è la firma digitale.
..
Non conservare mai il token nel tuo database. Un token valido è equivalente a una password; memorizzarlo significa trattarlo come una password in chiaro.
Access-token è un token che fornisce al suo proprietario accesso a risorse protette del server. Di solito ha una breve durata e può contenere informazioni aggiuntive, come l'indirizzo IP della parte che richiede il token.
Refresh-token è un token che consente ai client di richiedere nuovi access-token una volta scaduti. Questi token vengono generalmente emessi per periodi più lunghi.
Principali vantaggi nell'applicazione in un'architettura a microservizi:
- Possibilità di accedere a diverse applicazioni e servizi tramite un'unica autenticazione.
- In assenza di alcuni attributi richiesti nel profilo utenti, è possibile arricchire i dati aggiungendo informazioni che possono essere integrate, anche in modo automatizzato e "al volo".
- Non è necessario conservare informazioni sulle sessioni attive, l'applicazione server deve solo verificare la firma.
- Maggiore flessibilità nella gestione degli accessi grazie ad attributi aggiuntivi nel payload.
- L'uso della firma del token per l'intestazione e il payload aumenta la sicurezza complessiva della soluzione.
Token JWT — composizione
Intestazione — di default, l'intestazione contiene solo il tipo di token e l'algoritmo utilizzato per la crittografia.
Il tipo di token è memorizzato nella chiave «typ». La chiave «typ» è ignorata nel JWT. Se la chiave «typ» è presente, il suo valore deve essere JWT, per indicare che questo oggetto è un JSON Web Token.
La seconda chiave «alg» determina l'algoritmo utilizzato per crittografare il token. Di default, deve essere impostato su HS256. L'intestazione è codificata in base64.
{ "alg": "HS256", "typ": "JWT"}
Payload (contenuto) — nel payload si trova qualsiasi informazione da verificare. Ogni chiave nel payload è conosciuta come "affermazione". Ad esempio, è possibile accedere all'applicazione solo su invito (promozione chiusa). Quando vogliamo invitare qualcuno a partecipare, gli inviamo un'email di invito. È importante verificare che l'indirizzo email appartenga alla persona che accetta l'invito, quindi includeremo questo indirizzo nel payload, conservandolo sotto la chiave "e-mail".
{ "email": "example@x5.ru" }
Le chiavi nel payload possono essere arbitrarie. Tuttavia, ci sono alcune riservate:
- iss (Issuer) — determina l'applicazione da cui viene inviato il token.
- sub (Subject) — determina il soggetto del token.
- aud (Audience) – un array di stringhe sensibili al maiuscolo/minuscolo o URI, che costituisce l'elenco dei destinatari di questo token. Quando il destinatario riceve un JWT con questa chiave, deve verificare la propria presenza nell'elenco dei destinatari; in caso contrario, deve ignorare il token.
- exp (Expiration Time) — indica quando scade la validità del token. Lo standard JWT richiede che, in tutte le sue implementazioni, i token scaduti vengano rifiutati. La chiave exp deve essere un timestamp in formato unix.
- nbf (Not Before) — è un timestamp in formato unix che definisce il momento in cui il token diventa valido.
- iat (Issued At) — questa chiave rappresenta il momento in cui il token è stato emesso e può essere utilizzata per determinare l'età del JWT. La chiave iat deve essere un timestamp in formato unix.
- Jti (JWT ID) — una stringa che definisce l'identificatore unico di questo token, facendo distinzione tra maiuscole e minuscole.
È importante comprendere che il payload non viene trasmesso in forma crittografata (anche se i token possono essere annidati e quindi è possibile trasmettere dati crittografati). Pertanto, non è possibile memorizzare informazioni segrete al suo interno. Come l'intestazione, il payload è codificato in base64.
Firma — quando abbiamo l'intestazione e il payload, possiamo calcolare la firma.
I codici sono codificati in base64: intestazione e payload, uniti in una stringa tramite un punto. Questa stringa e la chiave segreta vengono quindi inserite nell'algoritmo di crittografia specificato nell'intestazione (chiave "alg"). Qualsiasi stringa può essere utilizzata come chiave. Stringhe più lunghe sono preferibili, poiché richiedono più tempo per essere decifrate.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Costruzione dell'architettura di un cluster Keycloak ad alta disponibilità
Utilizzando un singolo cluster per tutti i progetti, si presentano maggiori requisiti per la soluzione SSO. Quando il numero di progetti è limitato, queste esigenze non si fanno sentire così fortemente per tutti i progetti; tuttavia, con l'aumento degli utenti e delle integrazioni, aumentano anche i requisiti per l'accessibilità e le prestazioni.
Aumentare i rischi di fallimento di un SSO unico aumenta i requisiti architetturali della soluzione e dei metodi di backup dei componenti, portando a un SLA molto rigido. Per questo motivo, nella fase di progettazione o nelle fasi iniziali di implementazione delle soluzioni, i progetti spesso dispongono di un'infrastruttura non ridondante. Con l'evoluzione è necessario considerare le capacità di sviluppo e scalabilità. È più flessibile costruire un cluster di alta disponibilità utilizzando la virtualizzazione a container o un approccio ibrido.
Per operare in modalità Active/Active e Active/Passive in un cluster, è necessario garantire la coerenza dei dati in un database relazionale: entrambi i nodi del database devono essere replicati in modo sincrono tra i diversi data center geograficamente distribuiti.
Il più semplice esempio di installazione resiliente.
Quali vantaggi offre l'uso di un cluster unico:
- Alta disponibilità e prestazioni.
- Supporto per modalità operative: Active/Active, Active/Passive.
- Possibilità di scalabilità dinamica — utilizzando la virtualizzazione a container.
- Possibilità di gestione e monitoraggio centralizzati.
- Un approccio unificato per l'identificazione/autenticazione/autorizzazione degli utenti nei progetti.
- Un'interazione più trasparente tra progetti diversi senza la necessità degli utenti.
- Possibilità di riutilizzare il token JWT in vari progetti.
- Unico punto di fiducia.
- Avvio più rapido dei progetti grazie all'uso di microservizi/virtualizzazione dei container (non è necessaria l'installazione e la configurazione di componenti aggiuntivi).
- Possibilità di acquisire supporto commerciale dal fornitore.
Cosa considerare nella pianificazione di un cluster.
DBMS
Keycloak utilizza un sistema di gestione del DBMS per memorizzare: realms, clients, users, ecc.
Supporta una vasta gamma di DBMS: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak viene fornito con un proprio database relazionale integrato. Si raccomanda l'uso per ambienti poco caricati, come gli ambienti di sviluppo.
Per operare in modalità Active/Active e Active/Passive, è necessario garantire la coerenza dei dati nel database relazionale e entrambi i nodi del cluster dei database sono replicati sincronicamente tra i data center.
Cache distribuita (Infinspan)
Per il corretto funzionamento del cluster è necessaria una sincronizzazione aggiuntiva dei seguenti tipi di cache utilizzando JBoss Data Grid:
Sessioni di autenticazione — utilizzate per memorizzare i dati durante l'autenticazione di un particolare utente. Le richieste da questa cache solitamente includono solo il browser e il server Keycloak, e non l'applicazione.
Token di azione — utilizzati in scenari in cui l'utente deve confermare un'azione in modo asincrono (via email). Ad esempio, durante il flusso di ripristino della password, la cache actionTokens Infinispan è utilizzata per tracciare i metadati sui token d'azione correlati che sono già stati utilizzati, pertanto non possono essere riutilizzati.
Caching e invalidazione dei dati persistenti – utilizzati per memorizzare nella cache i dati permanenti, così da evitare richieste superflue al database. Quando un server Keycloak aggiorna i dati, tutti gli altri server Keycloak in tutti i datacenter devono esserne informati.
Work — utilizzato solo per inviare messaggi di invalidazione tra i nodi del cluster e i datacenter.
Le sessioni utente — vengono utilizzate per salvare i dati delle sessioni utente che rimangono validi durante la sessione del browser dell'utente. La cache deve gestire le richieste HTTP dall'utente finale e dalle applicazioni.
Protezione contro attacchi di forza bruta — serve per monitorare i dati sui tentativi di accesso non riusciti.
Bilanciamento del carico
Il bilanciatore di carico è il punto di ingresso unico in Keycloak e deve supportare le sticky sessions.
Server delle applicazioni
Vengono utilizzati per controllare l'interazione tra i componenti e possono essere virtualizzati o contenitorizzati utilizzando gli strumenti di automazione esistenti e il scaling dinamico delle infrastrutture. Gli scenari di distribuzione più comuni includono OpenShift, Kubernetes, Rancher.
Questa è la prima parte — teorica — del contenuto. Nei prossimi cicli di articoli verranno esaminati esempi di integrazioni con diversi fornitori di identificazione e impostazioni.
Fonte: habr.com
