Un solo login per tutte le tue app self-hosted: come costruire il tuo SSO con Authentik

Il self-hosting ha un piccolo problema che scopri soltanto dopo aver installato abbastanza applicazioni.

All’inizio hai un server e magari Nextcloud.

• Poi arriva Immich.
• Poi Paperless-ngx.
• Poi Grafana.
• Poi Portainer.
• Poi Open WebUI per la tua AI locale.

E improvvisamente ti ritrovi con sei applicazioni, sei utenti, sei password e sei sistemi di autenticazione differenti. Non è esattamente l’idea di infrastruttura ordinata che avevamo in mente.

La soluzione si chiama Single Sign-On, o semplicemente SSO.

L’idea è molto semplice: un’identità, un login, tutte le applicazioni.

Vediamo come funziona e soprattutto come possiamo realizzarlo gratuitamente in un’infrastruttura self-hosted.

Il problema: ogni applicazione vuole il suo account

Immaginiamo di avere questo piccolo server:

Immich          → foto
Paperless-ngx   → documenti
Grafana         → monitoraggio
Open WebUI      → intelligenza artificiale
Portainer       → Docker
Vikunja         → attività

Normalmente ciascun software mantiene il proprio database degli utenti.

Mario cambia password?

Deve cambiarla in più applicazioni.

Un collaboratore lascia l’azienda?

Bisogna ricordarsi di disabilitarlo ovunque.

Vogliamo imporre l’autenticazione a due fattori?

Dobbiamo verificare se ciascun programma la supporta e configurarla separatamente.

Con SSO cambiamo completamente l’architettura.

                    ┌── Immich
                    │
                    ├── Paperless
UTENTE → AUTHENTIK ─┼── Grafana
                    │
                    ├── Open WebUI
                    │
                    └── altre applicazioni

Le applicazioni non si occupano più direttamente dell’autenticazione.

La delegano a un sistema centrale.

Questo sistema viene chiamato Identity Provider, o IdP.

Che cos’è OpenID Connect?

Uno degli standard più utilizzati per realizzare questo meccanismo è OpenID Connect, abbreviato OIDC.

Attenzione a non confonderlo con OAuth 2.0.

OAuth riguarda principalmente l’autorizzazione: stabilisce cosa un’applicazione può fare per conto di un utente.

OpenID Connect aggiunge invece il livello relativo all’identità.

In termini molto semplificati:

Apri Immich
      ↓
Immich ti manda ad Authentik
      ↓
Effettui il login
      ↓
Authentik conferma la tua identità
      ↓
Torni su Immich già autenticato

La password viene gestita dall’Identity Provider.

Immich riceve invece un token che gli permette di sapere chi sei.

La cosa interessante: puoi ospitare anche l’Identity Provider

Quando pensiamo al pulsante:

Accedi con Google

stiamo già utilizzando un sistema simile.

Google sta facendo da Identity Provider.

Ma se stiamo costruendo un’infrastruttura self-hosted, perché non ospitare anche la nostra identità?

Possiamo farlo.

Tra le soluzioni open source più interessanti troviamo:

Authentik
Authelia
Keycloak

E qui nasce la prima domanda.

Quale scegliere?

Authentik, Authelia o Keycloak?

Sono tre progetti eccellenti, ma non fanno esattamente lo stesso lavoro.

Authelia

Authelia è particolarmente interessante quando abbiamo molte applicazioni dietro un reverse proxy.

È leggero e nasce proprio come livello di autenticazione davanti ai servizi.

Lo prenderei in considerazione soprattutto per un homelab o per infrastrutture relativamente semplici.

Authentik

Authentik è probabilmente il compromesso più interessante per chi vuole costruire un vero Identity Provider senza entrare immediatamente nella complessità enterprise.

Ha un’interfaccia grafica moderna e può gestire OIDC, SAML e diversi scenari di autenticazione.

Per il nostro progetto sceglierei Authentik.

Keycloak

Keycloak gioca in un campionato leggermente differente.

È una piattaforma IAM completa, adatta anche a infrastrutture aziendali complesse, federazione LDAP/Active Directory, realm differenti e configurazioni avanzate.

È potentissimo.

Ma per autenticare cinque applicazioni sul nostro VPS rischiamo di utilizzare un carro armato per andare al supermercato.

Installiamo Authentik

Il modo più pratico per iniziare è utilizzare Docker.

Prima di procedere controlliamo sempre la documentazione ufficiale del progetto perché immagini, variabili e procedure possono cambiare tra una release e l’altra.

L’architettura tipica comprende Authentik e il relativo database.

Una volta avviato, possiamo dedicargli un sottodominio, ad esempio:

auth.provatoo.net

Naturalmente nel vostro caso utilizzerete il vostro dominio.

Il risultato interessante è che quell’indirizzo diventerà la porta d’ingresso della nostra infrastruttura.

Il reverse proxy

In una configurazione reale probabilmente avremo già qualcosa come:

Nginx Proxy Manager
Traefik
Caddy
NGINX

davanti ai container.

Potremo quindi avere:

foto.example.it      → Immich
docs.example.it      → Paperless
ai.example.it        → Open WebUI
monitor.example.it   → Grafana
auth.example.it      → Authentik

Tutti utilizzano HTTPS.

Ma soprattutto possono utilizzare la stessa identità.

Colleghiamo la prima applicazione

Supponiamo che Immich supporti OpenID Connect.

In Authentik creiamo un’applicazione.

Il provider ci fornirà informazioni come:

Client ID
Client Secret
Issuer URL
Authorization Endpoint
Token Endpoint

Dall’altra parte dovremo comunicare ad Authentik dove può riportare l’utente dopo l’autenticazione.

È la famosa:

Redirect URI

Il meccanismo, una volta compreso, si ripete praticamente per tutte le applicazioni compatibili.

E quindi posso eliminare tutte le password?

Non proprio.

Ed è importante capirlo.

L’SSO non significa necessariamente che le applicazioni non abbiano più account locali.

Dipende dall’implementazione.

Inoltre è sempre prudente conservare un accesso amministrativo di emergenza.

Perché abbiamo appena creato un problema nuovo.

Abbiamo creato le chiavi del regno

Prima avevamo:

password A
password B
password C
password D

Adesso abbiamo:

IDENTITÀ CENTRALE

Fantastico dal punto di vista della gestione.

Molto delicato dal punto di vista della sicurezza.

Se qualcuno compromette l’Identity Provider potrebbe potenzialmente ottenere accesso a numerosi servizi.

Per questo l’account centrale deve essere protetto seriamente.

Come minimo:

• MFA;
• meglio ancora passkey quando disponibili;
• HTTPS;
• aggiornamenti regolari;
• backup;
• protezione dell’account amministratore;
• recovery code conservati offline;
• accesso amministrativo di emergenza.

Centralizzare l’identità significa semplificare la gestione.

Significa anche centralizzare una parte del rischio.

La famigerata “SSO tax”

Ed eccoci alla parte più curiosa.

Alcuni software supportano tecnicamente SAML oppure OpenID Connect, ma rendono questa possibilità disponibile soltanto nel piano Business o Enterprise.

Il risultato è paradossale.

Hai:

• il tuo server;
• il tuo database;
• il tuo Identity Provider;
• la tua infrastruttura;

ma devi pagare per poter dire all’applicazione:

“usa il mio sistema di autenticazione”.

Questo fenomeno è stato soprannominato SSO tax.

Per un’azienda SaaS può essere una strategia commerciale comprensibile.

Nel mondo self-hosted, però, la questione diventa molto più discutibile.

Se scelgo un software proprio per mantenere il controllo della mia infrastruttura, considero il supporto a un Identity Provider personalizzato quasi una caratteristica infrastrutturale, non un lusso enterprise.

Controllare prima di installare

Da questo nasce una nuova regola che vale la pena aggiungere alla nostra checklist quando scegliamo software self-hosted.

Non chiediamoci soltanto:

È open source?
Ha Docker?
Posso fare backup?
Ha una API?

Aggiungiamo:

Supporta OIDC?

E subito dopo:

È incluso gratuitamente?

Può sembrare un dettaglio quando abbiamo due applicazioni.

Quando ne abbiamo venti, non lo è più.

Anche l’AI self-hosted entra nel nostro SSO

Ed è qui che questa guida si collega agli esperimenti che abbiamo fatto con l’intelligenza artificiale locale.

Supponiamo di avere:

Ollama
   ↓
Open WebUI

Open WebUI diventa l’interfaccia attraverso la quale i nostri utenti utilizzano i modelli.

Se l’installazione è personale, nessun problema.

Ma immaginiamo di utilizzarla in un piccolo team.

Invece di creare un nuovo database di password possiamo collegare anche l’interfaccia AI al nostro Identity Provider.

La struttura diventa:

                         ┌─ Documenti
                         │
UTENTE → IDENTITÀ → SSO ─┼─ Dashboard
                         │
                         ├─ Foto
                         │
                         └─ AI

A questo punto non stiamo più semplicemente installando applicazioni Docker.

Stiamo costruendo una piccola infrastruttura cloud privata.

SSO non è una funzione enterprise

Questo è probabilmente il punto più interessante.

Per anni abbiamo associato Single Sign-On a Microsoft 365, Active Directory e grandi infrastrutture aziendali.

Il self-hosting ha cambiato parecchio le cose.

Una famiglia con un home server può averne bisogno.

Un freelance con dieci applicazioni può averne bisogno.

Una piccola azienda può averne bisogno.

Un laboratorio che sperimenta con servizi AI può averne bisogno.

Perché il problema non è la dimensione dell’organizzazione.

È quante identità dobbiamo amministrare.

Conclusione

All’inizio del nostro viaggio self-hosted installiamo applicazioni.

Poi iniziamo a usare Docker.

Aggiungiamo un reverse proxy.

Configuriamo HTTPS.

Facciamo backup.

Installiamo un modello AI.

E prima o poi arriviamo inevitabilmente all’identità.

È in quel momento che il nostro server smette di essere una raccolta di container e comincia ad assomigliare a una vera infrastruttura.

Un solo account.

MFA centralizzata.

Accesso controllato.

Applicazioni indipendenti.

E soprattutto una nuova regola da ricordare prima di scegliere il prossimo software da installare:

se devo ospitare io l’applicazione, voglio poter ospitare anche la mia identità.