Riscrivere la logica di autenticazione in ogni applicazione lascia credenziali duplicate, policy di password che divergono e nessun punto unico da cui togliere un accesso. Un server di Identity and Access Management (IAM) sposta quella logica fuori dall’applicazione: l’applicazione smette di custodire password e si limita a verificare token firmati da un’autorità esterna. Keycloak — progetto della comunità WildFly, sponsorizzato da Red Hat e rilasciato sotto licenza Apache 2.0 — è una delle implementazioni Open Source di questo modello; la prima release di produzione è del settembre 2014 e la versione corrente è la 1.9.

Contesto e problema

In un’azienda con dieci applicazioni interne, l’autenticazione fatta in casa diventa dieci tabelle utenti, dieci meccanismi di reset password, dieci formati di sessione. Quando un dipendente se ne va, revocargli l’accesso dipende dal ricordarsi tutti e dieci i sistemi. La parte difficile non è scrivere il codice di login: è tenerlo coerente e tracciabile man mano che i sistemi crescono.

Spostare l’identità in un servizio dedicato è uno schema descritto da specifiche pubbliche: OAuth 2.0 (RFC 6749, ottobre 2012) per l’autorizzazione delegata, OpenID Connect (Core 1.0, febbraio 2014) per l’autenticazione costruita sopra OAuth 2.0, SAML 2.0 (OASIS, 2005) per parlare con i sistemi enterprise più datati. Un server IAM, in concreto, è un’implementazione di questi protocolli, con sopra una console di amministrazione e un archivio utenti.

Architettura

Keycloak organizza tutto in realm: un realm è uno spazio isolato, con i propri utenti, ruoli, client e chiavi di firma. Un client è un’applicazione registrata che chiede di autenticare; un singolo realm può servire decine di client che condividono lo stesso bacino di utenti.

Il flusso tipico con OpenID Connect è l’Authorization Code Flow descritto nella Core 1.0. L’applicazione non vede mai la password: reindirizza il browser a Keycloak, che autentica l’utente e restituisce un codice di autorizzazione. L’applicazione scambia quel codice per un ID token e un access token, entrambi JWT firmati. La verifica lato applicazione si riduce a controllare la firma con la chiave pubblica del realm (esposta su un endpoint JWKS) e i claim — iss, aud, exp. Nessuna interrogazione a un database di sessioni condiviso, nel caso comune.

Le applicazioni dialogano con il server tramite adapter ufficiali per Java (server applicativi JBoss/WildFly, Tomcat, Jetty), per il browser via JavaScript, e per Node.js. Un adapter incapsula la gestione del redirect, lo scambio del codice e la validazione del token, così che il codice applicativo veda solo l’utente già autenticato. Dove l’adapter non c’è, l’applicazione parla OIDC o SAML direttamente, perché gli endpoint sono standard.

L’archivio utenti predefinito è un database relazionale, ma la federazione sposta l’archivio su directory esterne: si configurano provider LDAP e Active Directory come fonti, con sincronizzazione degli utenti e mapping degli attributi sul modello interno. L’utente vive in LDAP; Keycloak ne tiene una proiezione locale per ruoli e sessioni.

Il punto critico

Tra un server IAM e un blocco di codice di login, la differenza pratica sta nella sessione SSO centralizzata. Con il Single Sign-On l’utente si autentica una volta e raggiunge tutti i client del realm senza ripetere il login; il rovescio è il Single Logout, che chiude la sessione su tutti i client insieme. Dieci sistemi separati questo non lo sanno fare: ciascuno ha la propria idea di “sessione attiva” e non sa nulla degli altri.

L’identity brokering porta lo schema verso l’esterno. Keycloak può fare da intermediario con provider di identità di terze parti — Google, GitHub, o qualunque provider OIDC/SAML — riportando le identità in arrivo nel modello del realm. L’applicazione vede un solo emittente di token (Keycloak) anche quando l’autenticazione vera è avvenuta altrove. Il broker traduce; l’applicazione resta legata a una sola autorità.

Il dettaglio da non trascurare riguarda le chiavi di firma. Tutta la fiducia del sistema poggia sull’applicazione che verifica firma e claim del token nel modo giusto. Un adapter mal configurato che accetta token senza controllare aud o exp, o che salta la verifica della firma, manda all’aria la centralizzazione: il server è solido, ma la sicurezza reale è quella del verificatore più debole.

Implicazioni

Delegare l’identità a un server dedicato concentra in un punto le decisioni prima sparse: policy di password, durata dei token, autenticazione multi-fattore, revoca. La console di amministrazione web tiene questi controlli per realm — client, ruoli, mapper, sessioni — senza chiedere modifiche al codice delle applicazioni quando una policy cambia. Aggiungere la MFA a tutte le applicazioni del realm diventa un passo di configurazione, non un rilascio coordinato su dieci codebase.

C’è anche una ricaduta sull’audit. Con l’autenticazione concentrata, “chi è entrato, quando, da dove, su cosa” è una domanda con una sola fonte di risposta. È il contrario dello scenario di partenza, dove la stessa domanda significa interrogare dieci log in dieci formati.

Limiti

La centralizzazione crea un punto di dipendenza: se il server di identità è irraggiungibile, le nuove autenticazioni si fermano. Le sessioni già aperte con token a vita breve reggono fino alla scadenza, ma login e refresh hanno bisogno del server raggiungibile, e questo obbliga a trattarlo come componente ad alta disponibilità, non come servizio accessorio.

La federazione LDAP introduce una doppia rappresentazione dell’utente, con i problemi di consistenza di ogni sincronizzazione: cosa succede quando un attributo cambia in LDAP ma la proiezione locale non è ancora aggiornata, o quando un utente viene rimosso a monte. Sono questioni di configurazione e di intervallo di sincronizzazione, ma vanno decise in modo esplicito.

Alla data odierna, infine, Keycloak non figura ancora tra le implementazioni OpenID Connect certificate dalla OpenID Foundation. Implementa OIDC e SAML secondo le specifiche, e l’interoperabilità con altri provider conformi è la norma, ma dove i requisiti sono stringenti conviene verificare la certificazione formale di conformità per la versione e i flussi che si intende usare.

Immagine di copertina: Logo dello standard OAuth: la scritta “OAuth” in minuscolo con una grande “O” stilizzata su sfondo chiaro — logo di Chris Messina, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:Oauth_logo.svg