In ogni grande azienda, e X5 Retail Group non fa eccezione, man mano che si sviluppa, aumenta il numero di progetti che richiedono l'autorizzazione dell'utente. Nel corso del tempo, è necessaria una transizione fluida degli utenti da un'applicazione all'altra e quindi la necessità di utilizzare un singolo server Single-Sing-On (SSO). Ma che dire se in vari progetti vengono già utilizzati provider di identità come AD o altri che non dispongono di attributi aggiuntivi? Una classe di sistemi chiamati "intermediari di identificazione" verrà in soccorso. I più funzionali sono i suoi rappresentanti, come Keycloak, Gravitee Access Management, ecc. Molto spesso, i casi d'uso possono essere diversi: interazione con la macchina, partecipazione dell'utente, ecc. La soluzione deve supportare funzionalità flessibili e scalabili in grado di combinare tutti i requisiti in uno, e per tali soluzioni la nostra azienda ora ha un broker di riferimento: Keycloak.
Keycloak è un prodotto open source per il controllo dell'identità e degli accessi gestito da RedHat. Costituisce la base per i prodotti dell'azienda che utilizzano SSO - RH-SSO.
concetti
Prima di iniziare ad affrontare soluzioni e approcci, dovresti decidere in termini e sequenza dei processi:
identificazione è una procedura per riconoscere un soggetto in base al suo identificatore (in altre parole, questa è la definizione di un nome, login o numero).
autenticazione - questa è una procedura di autenticazione (l'utente viene controllato con una password, la lettera viene controllata con una firma elettronica, ecc.)
Autorizzazione - questa è la fornitura di accesso a una risorsa (ad esempio, alla posta elettronica).
Mantello chiave dell'intermediario di identità
Mantello delle chiavi è una soluzione open source di gestione delle identità e degli accessi progettata per l'uso nell'IS in cui è possibile utilizzare modelli di architettura di microservizi.
Keycloak offre funzionalità come single sign-on (SSO), identità intermediata e accesso social, federazione utenti, adattatori client, console di amministrazione e console di gestione degli account.
Funzionalità di base supportate da Keycloak:
- Single Sign On e Single Sign Out per le applicazioni browser.
- Supporto per OpenID/OAuth 2.0/SAML.
- Intermediazione di identità: autenticazione tramite OpenID Connect esterno o provider di identità SAML.
- Accesso social: supporto Google, GitHub, Facebook, Twitter per l'identificazione dell'utente.
- Federazione utenti: sincronizzazione degli utenti dai server LDAP e Active Directory e da altri provider di identità.
- Bridge Kerberos: utilizza un server Kerberos per l'autenticazione automatica dell'utente.
- Console di amministrazione: per la gestione unificata delle impostazioni e delle opzioni della soluzione tramite il Web.
- Console di gestione account - per l'autogestione del profilo utente.
- Personalizzazione della soluzione in base alla corporate identità dell'azienda.
- Autenticazione 2FA: supporto TOTP/HOTP utilizzando Google Authenticator o FreeOTP.
- Flussi di accesso: sono possibili l'autoregistrazione dell'utente, il recupero e la reimpostazione della password e altro ancora.
- Gestione delle sessioni: gli amministratori possono gestire le sessioni utente da un unico punto.
- Token Mapper: associano attributi utente, ruoli e altri attributi richiesti ai token.
- Gestione flessibile delle policy tra realm, applicazioni e utenti.
- Supporto CORS: gli adattatori client dispongono del supporto CORS integrato.
- Interfacce del fornitore di servizi (SPI): un gran numero di SPI che consentono di personalizzare vari aspetti del server: flussi di autenticazione, provider di identità, mappatura dei protocolli e altro ancora.
- Adattatori client per applicazioni JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Supporto per lavorare con varie applicazioni che supportano la libreria OpenID Connect Relying Party o la libreria del fornitore di servizi SAML 2.0.
- Espandibile tramite plugin.
Per i processi CI/CD, nonché per l'automazione dei processi di gestione in Keycloak, è possibile utilizzare l'API REST/API JAVA. La documentazione è disponibile elettronicamente:
API REST
API JAVA
Provider di identità aziendali (on-premise)
Possibilità di autenticare gli utenti tramite i servizi di Federazione Utenti.
È possibile utilizzare anche l'autenticazione pass-through: se gli utenti si autenticano su workstation con Kerberos (LDAP o AD), possono essere automaticamente autenticati su Keycloak senza dover inserire nuovamente nome utente e password.
Per l'autenticazione e l'ulteriore autorizzazione degli utenti è possibile utilizzare un DBMS relazionale, che è particolarmente applicabile per gli ambienti di sviluppo, poiché non comporta lunghe impostazioni e integrazioni nelle prime fasi dei progetti. Per impostazione predefinita, Keycloak utilizza un DBMS integrato per memorizzare le impostazioni e i dati dell'utente.
L'elenco dei DBMS supportati è ampio e include: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle e altri. I più testati finora sono Oracle 12C Release1 RAC e il cluster Galera 3.12 per MariaDB 10.1.19.
Provider di identità: accesso social
È possibile utilizzare un login dai social network. Per attivare la possibilità di autenticare gli utenti, utilizzare la console di amministrazione Keycclock. Non sono necessarie modifiche al codice dell'applicazione e questa funzionalità è disponibile immediatamente e può essere attivata in qualsiasi fase del progetto.
È possibile utilizzare provider di identità OpenID/SAML per l'autenticazione dell'utente.
Scenari di autorizzazione tipici che utilizzano OAuth2 in Keycloak
Flusso del codice di autorizzazione - utilizzato con applicazioni lato server. Uno dei tipi più comuni di autorizzazione perché è particolarmente adatto per le applicazioni server in cui il codice sorgente dell'applicazione e i dati client non sono disponibili agli esterni. Il processo in questo caso si basa sul reindirizzamento. L'applicazione deve essere in grado di comunicare con un agente utente (agente utente), ad esempio un browser Web, per ricevere i codici di autorizzazione API reindirizzati tramite l'agente utente.
Flusso implicito - utilizzato da applicazioni mobili o web (applicazioni in esecuzione sul dispositivo dell'utente).
Il tipo di autorizzazione di autorizzazione implicita viene utilizzato dalle applicazioni mobili e Web in cui la riservatezza del client non può essere garantita. Il tipo di autorizzazione implicita utilizza anche il reindirizzamento dell'agente utente, per cui il token di accesso viene passato all'agente utente per un ulteriore utilizzo nell'applicazione. Ciò rende il token disponibile all'utente e ad altre applicazioni sul dispositivo dell'utente. Questo tipo di autorizzazione non autentica l'identità dell'applicazione e il processo stesso si basa su un URL di reindirizzamento (precedentemente registrato con il servizio).
Il flusso implicito non supporta i token di aggiornamento dei token di accesso.
Flusso di concessione delle credenziali del cliente - vengono utilizzati quando l'applicazione accede all'API. Questo tipo di autorizzazione viene in genere utilizzata per le interazioni da server a server che devono essere eseguite in background senza l'interazione immediata dell'utente. Il flusso di concessione delle credenziali client consente a un servizio Web (client confidenziale) di utilizzare le proprie credenziali invece di impersonare un utente per l'autenticazione quando chiama un altro servizio Web. Per un livello di sicurezza più elevato, è possibile che il servizio chiamante utilizzi un certificato (invece di un segreto condiviso) come credenziale.
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 trasferire in modo sicuro le informazioni tra le parti come oggetto JSON.
Secondo lo standard, il token è composto da tre parti in formato base 64, separate da punti. La prima parte è detta header, che contiene il tipo di token e il nome dell'algoritmo di hash per ottenere la firma digitale. La seconda parte memorizza le informazioni di base (utente, attributi, ecc.). La terza parte è la firma digitale.
. .
Non archiviare mai un token nel tuo DB. Poiché un token valido equivale a una password, archiviare il token è come archiviare la password in testo non crittografato.
Token di accesso è un token che garantisce al suo proprietario l'accesso a risorse del server sicure. Di solito ha una durata breve e può contenere informazioni aggiuntive come l'indirizzo IP della parte che richiede il token.
Aggiorna token è un token che consente ai client di richiedere nuovi token di accesso una volta scaduta la loro durata. Questi token vengono solitamente emessi per un lungo periodo di tempo.
I principali vantaggi dell'utilizzo nell'architettura dei microservizi:
- Possibilità di accedere a varie applicazioni e servizi tramite l'autenticazione una tantum.
- In assenza di una serie di attributi richiesti nel profilo utente, è possibile arricchirlo con dati che possono essere aggiunti al payload, anche automatizzati e al volo.
- Non è necessario archiviare informazioni sulle sessioni attive, l'applicazione server deve solo verificare la firma.
- Controllo degli accessi più flessibile tramite attributi aggiuntivi nel payload.
- L'uso di una firma token per l'intestazione e il payload aumenta la sicurezza della soluzione nel suo insieme.
Token JWT - composizione
Titolo - per impostazione predefinita, l'intestazione contiene solo il tipo di token e l'algoritmo utilizzato per la crittografia.
Il tipo del token è memorizzato nella chiave "typ". La chiave "tipo" viene ignorata nel JWT. Se è presente la chiave "typ", il suo valore deve essere JWT per indicare che questo oggetto è un Web Token JSON.
La seconda chiave "alg" definisce l'algoritmo utilizzato per crittografare il token. Dovrebbe essere impostato su HS256 per impostazione predefinita. L'intestazione è codificata in base64.
{ "alg": "HS256", "typ": "JWT"}
carico utile (contenuto) - il payload memorizza tutte le informazioni che devono essere controllate. Ogni chiave nel payload è nota come "reclamo". Ad esempio, puoi accedere all'applicazione solo su invito (promo chiusa). Quando vogliamo invitare qualcuno a partecipare, gli inviamo una lettera di invito. È importante verificare che l'indirizzo email appartenga alla persona che accetta l'invito, quindi includeremo questo indirizzo nel payload, per questo lo memorizzeremo nella chiave "email"
{ "e-mail": "[email protected]"}
Le chiavi nel carico utile possono essere arbitrarie. Tuttavia, ce ne sono alcuni riservati:
- iss (Emittente): identifica l'applicazione da cui viene inviato il token.
- sub (Oggetto) - definisce l'oggetto del token.
- aud (Audience) è un array di stringhe o URI con distinzione tra maiuscole e minuscole che è un elenco dei destinatari di questo token. Quando il lato ricevente riceve un JWT con la chiave specificata, deve verificare la presenza di se stesso nei destinatari, altrimenti ignora il token.
- exp (Tempo di scadenza): indica quando scade il token. Lo standard JWT richiede che tutte le sue implementazioni rifiutino i token scaduti. La chiave exp deve essere un timestamp in formato Unix.
- nbf (Not Before) è un tempo in formato Unix che determina il momento in cui il token diventa valido.
- iat (Issued At): questa chiave rappresenta l'ora 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 univoco di questo token, con distinzione tra maiuscole e minuscole.
È importante comprendere che il payload non viene trasmesso in forma crittografata (anche se i token possono essere annidati ed è quindi possibile trasmettere dati crittografati). Pertanto, non può memorizzare alcuna informazione segreta. Come l'intestazione, il payload è codificato base64.
Firma - quando abbiamo un titolo e un carico utile, possiamo calcolare la firma.
Codifica Base64: vengono presi l'intestazione e il carico utile, vengono combinati in una stringa tramite un punto. Quindi questa stringa e la chiave segreta vengono immesse nell'algoritmo di crittografia specificato nell'intestazione (chiave "alg"). La chiave può essere qualsiasi stringa. Le corde più lunghe saranno le più preferite poiché richiederanno più tempo per essere raccolte.
{"alg":"RSA1_5","carico utile":"A128CBC-HS256"}
Creazione di un'architettura cluster di failover Keycloak
Quando si utilizza un singolo cluster per tutti i progetti, aumentano i requisiti per una soluzione SSO. Quando il numero di progetti è piccolo, questi requisiti non sono così evidenti per tutti i progetti, tuttavia, con l’aumento del numero di utenti e delle integrazioni, aumentano i requisiti di disponibilità e prestazioni.
L’aumento del rischio di singolo errore SSO aumenta i requisiti per l’architettura della soluzione e i metodi utilizzati per i componenti ridondanti e porta a uno SLA molto rigido. A questo proposito, più spesso durante lo sviluppo o le prime fasi di implementazione delle soluzioni, i progetti dispongono di una propria infrastruttura non tollerante ai guasti. Man mano che lo sviluppo avanza, è necessario stabilire opportunità di sviluppo e di ridimensionamento. La soluzione più flessibile è creare un cluster di failover utilizzando la virtualizzazione del contenitore o un approccio ibrido.
Per funzionare nelle modalità cluster Attivo/Attivo e Attivo/Passivo, è necessario garantire la coerenza dei dati in un database relazionale: entrambi i nodi del database devono essere replicati in modo sincrono tra diversi data center distribuiti geograficamente.
L'esempio più semplice di installazione tollerante agli errori.
Quali sono i vantaggi dell'utilizzo di un singolo cluster:
- Elevata disponibilità e prestazioni.
- Supporto per modalità operative: Attivo/Attivo, Attivo/Passivo.
- Capacità di scalare dinamicamente quando si utilizza la virtualizzazione del contenitore.
- Possibilità di gestione e monitoraggio centralizzato.
- Approccio unificato per l'identificazione/autenticazione/autorizzazione degli utenti nei progetti.
- Interazione più trasparente tra diversi progetti senza interazione da parte dell'utente.
- La possibilità di riutilizzare il token JWT in vari progetti.
- Unico punto di fiducia.
- Avvio più rapido di progetti utilizzando microservizi/virtualizzazione dei contenitori (non è necessario sollevare e configurare componenti aggiuntivi).
- È possibile acquistare supporto commerciale dal venditore.
Cosa cercare quando si pianifica un cluster
DBMS
Keycloak utilizza un sistema di gestione del database per archiviare: regni, clienti, utenti, ecc.
È supportata un'ampia gamma di DBMS: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak viene fornito con il proprio database relazionale integrato. Se ne consiglia l'utilizzo per ambienti non caricati, come gli ambienti di sviluppo.
Per lavorare in modalità cluster attivo/attivo e attivo/passivo, è necessaria la coerenza dei dati in un database relazionale ed entrambi i nodi del cluster di database vengono replicati in modo sincrono tra i data center.
Cache distribuita (Infinspan)
Affinché il cluster funzioni correttamente, è necessaria un'ulteriore sincronizzazione dei seguenti tipi di cache utilizzando JBoss Data Grid:
Sessioni di autenticazione: utilizzate per salvare i dati durante l'autenticazione di un utente specifico. Le richieste da questa cache in genere includono solo il browser e il server Keycloak, non l'applicazione.
I token di azione vengono utilizzati per scenari in cui l'utente deve confermare un'azione in modo asincrono (tramite posta elettronica). Ad esempio, durante un flusso di password dimenticata, la cache actionTokens Infinispan viene utilizzata per tenere traccia dei metadati sui token di azione associati che sono già stati utilizzati, quindi non può essere riutilizzata.
Memorizzazione nella cache e invalidazione dei dati persistenti: utilizzato per memorizzare nella cache i dati persistenti per evitare query non necessarie al database. Quando un server Keycloak aggiorna i dati, tutti gli altri server Keycloak in tutti i data center devono saperlo.
Lavoro: utilizzato solo per inviare messaggi non validi tra nodi cluster e data center.
Sessioni utente: utilizzate per archiviare dati sulle sessioni utente validi per la durata della sessione del browser dell'utente. La cache deve elaborare le richieste HTTP dall'utente finale e dall'applicazione.
Protezione dalla forza bruta: utilizzata per tenere traccia dei dati sugli accessi non riusciti.
Bilancio del carico
Il sistema di bilanciamento del carico è il singolo punto di ingresso per keycloak e deve supportare sessioni permanenti.
Server delle applicazioni
Vengono utilizzati per controllare l'interazione dei componenti tra loro e possono essere virtualizzati o containerizzati utilizzando gli strumenti di automazione esistenti e il ridimensionamento dinamico degli strumenti di automazione dell'infrastruttura. Gli scenari di distribuzione più comuni in OpenShift, Kubernates, Rancher.
Con questo si conclude la prima parte, quella teorica. Nella prossima serie di articoli verranno analizzati esempi di integrazioni con diversi provider di identità ed esempi di impostazioni.
Fonte: habr.com