Sincronizzare le identità Zitadel tra più ambienti senza trascinare il database
Quando colleghi un'applicazione a un identity provider, ogni utente locale guadagna una colonna con l'identificativo esterno. Quella colonna è preziosa e fragile: costa migliaia di chiamate API per essere ricostruita, e applicarla alla riga sbagliata assegna l'identità di una persona a un'altra. Come l'ho portata fra ambienti diversi con un file di poche decine di kilobyte, una guardia che aborta invece di indovinare, e un'operazione ripetibile senza conseguenze. Continua a leggere
Ultima modifica:
Attivare l'autenticazione a due fattori su un pannello di posta sembra una spunta da mettere, finché non ti accorgi che il codice via email finirebbe su una casella tecnica che per standard è recapitata all'operatore e non al cliente. Il difetto non è il secondo fattore: è che l'identità di accesso è una casella e non una persona. Il percorso di rimedio in tre passi, come si convive con i due sistemi durante la transizione, e le scadenze NIS2 reali che lo rendono urgente. 
Aggiungere il single sign-on a un prodotto che gira anche presso clienti senza identity provider non è mettere un flag: è progettare due forme del prodotto che convivono nello stesso codice. E siccome il flusso coinvolge due applicazioni, la modalità effettiva non è una configurazione ma un'intersezione, che va scoperta invece che assunta. Il pattern della negoziazione, il degrado direzionale, la macchina a cinque stati e come si collauda un prodotto che le ha tutte. 
Il collegamento che porta l'utente da un'applicazione all'altra già autenticato e sulla risorsa giusta è la funzionalità che tutti vogliono e che quasi nessuno implementa senza aprire un buco. Il problema non è l'autenticazione, che il protocollo risolve: è che un URL è un dato che l'utente controlla, e ogni parametro che ci metti diventa qualcosa su cui qualcuno proverà a barare. L'invariante che ho adottato, i vettori che ho provato e i compromessi che ho accettato. 
Mettere i permessi dentro il token è la prima ottimizzazione che viene in mente e la più difficile da disfare: risparmia una query e, in cambio, rende la revoca inefficace fino alla scadenza. Ma rileggerli non basta, perché fra il controllo e l'uso resta una finestra in cui lo stato può cambiare. Il pattern che chiude entrambe le falle, il codice che lo implementa e la disciplina che impedisce a un'operazione nuova di sfuggire alla classificazione. 
C'è un momento, in ogni migrazione verso il single sign-on, in cui l'applicazione smette di avere la password dell'utente. Sembra un progresso e lo è, ma se quella password serviva anche ad accedere ai dati, in quell'istante hai silenziosamente rimosso il controllo di accesso e nessun test se ne accorge. Come ho ricostruito il recinto a livello applicativo, perché un solo livello non basta, come si enumera davvero la superficie da proteggere, e il buco cross-tenant che l'audit ha trovato. 
Un identity provider sa chi sei e non sa niente di cosa puoi fare, perché i permessi veri dipendono da contratti, anagrafiche e stati che vivono nel tuo gestionale. Il pattern che ne esce è un monolite Laravel che diventa resource server e autorità di autorizzazione per le altre applicazioni, senza account di servizio e senza duplicare una riga di logica. Il middleware, la risoluzione deterministica dell'identità e il punto in cui quasi tutti sbagliano. 
Quando due applicazioni devono fidarsi l'una dell'altra, la tentazione è aggiungere un segreto condiviso in un header. Non serve: se entrambe parlano con lo stesso identity provider, il token dell'utente è già una prova crittografica di chi sta chiamando. Il codice reale che valida quella prova, con la firma verificata in locale, il projectId nell'audience, l'autenticazione del client tramite chiave privata e i test che dimostrano che i casi sbagliati vengono respinti. 
Due istanze di un binario stateless dietro un bilanciatore sembrano il caso più semplice di alta disponibilità, e lo sarebbero se non ci fosse una fase che tocca lo schema del database. È quella fase a imporre un ordine fra i nodi, a rendere l'aggiornamento asimmetrico e a decidere se il rollback funziona ancora. La sequenza completa, lo script che la esegue, i codici di uscita per la pipeline, cosa monitorare davvero e le due cose che con la versione 4 sono cambiate. 
La guida ufficiale all'installazione di Zitadel su Linux si apre dichiarando che non vale per la versione 4 e ti manda su Docker. Il deploy nativo però funziona ancora, e i binari sono lì fra gli artefatti di rilascio: quello che cambia è che i componenti da installare sono due e non più uno. Questa è la procedura completa su Debian, con i tre file di configurazione, l'unità systemd che regge un audit, lo split di routing, cosa salvare davvero e i tre modi in cui si rompe.