Migrazione Nextcloud verso un nuovo Identity Provider: LDAP, OpenID Connect, Entra ID e Keycloak

Migrare un ambiente Nextcloud non significa semplicemente trasferire file da un sistema a un altro.

In un’infrastruttura aziendale, uno degli aspetti più delicati riguarda infatti l’identità degli utenti e tutte le relazioni che nel tempo vengono create tra utenti, dati, gruppi, condivisioni, permessi e applicazioni.

Il problema diventa particolarmente importante quando si decide di modificare l’architettura di autenticazione, ad esempio passando:

• da LDAP a OpenID Connect;
• da Active Directory a un Identity Provider moderno;
• da LDAP a Microsoft Entra ID;
• da LDAP a Keycloak;
• da autenticazione locale a Single Sign-On;
• da sistemi di autenticazione differenti a una piattaforma IAM centralizzata.

Una migrazione progettata in modo errato può portare Nextcloud a interpretare l’identità fornita dal nuovo Identity Provider come un utente completamente nuovo.

Il rischio è che l’utente riesca ad autenticarsi correttamente ma non ritrovi più i propri file, le condivisioni, i gruppi o le autorizzazioni precedenti.

Per questo motivo la migrazione dell’Identity Provider dovrebbe essere considerata non come una semplice modifica del sistema di login, ma come un vero progetto di continuità dell’identità digitale.

Il principio fondamentale di una corretta migrazione può essere sintetizzato così:

Il sistema di autenticazione può cambiare, ma l’identità dell’utente all’interno di Nextcloud dovrebbe rimanere stabile.

Dal punto di vista dell’utente finale, il cambiamento dovrebbe idealmente essere trasparente.

Dopo l’accesso attraverso il nuovo Identity Provider dovrebbe continuare a trovare:

• i propri file;
• le proprie cartelle;
• le condivisioni;
• i gruppi;
• le Team Folder;
• le autorizzazioni;
• le preferenze;
• le configurazioni delle applicazioni.

Per raggiungere questo risultato è necessario capire quali identificativi vengono utilizzati prima e dopo la migrazione.

Strategia 1: creare nuovi utenti e trasferire i dati

Una prima possibilità consiste nel creare nuovi account utilizzando il nuovo Identity Provider e trasferire successivamente i dati dai vecchi utenti.

Questa strategia può essere valida quando:

• gli utenti sono pochi;
• le condivisioni sono relativamente semplici;
• i gruppi non hanno strutture particolarmente complesse;
• l’organizzazione vuole riorganizzare gli account;
• esistono utenti legacy da eliminare;
• la migrazione viene utilizzata per riprogettare la struttura dell’ambiente.

La procedura può comprendere:

1. creazione dei nuovi utenti;
2. trasferimento della proprietà dei file;
3. verifica delle condivisioni;
4. ricostruzione dei gruppi;
5. verifica dei permessi;
6. controllo delle Team Folder;
7. verifica delle applicazioni;
8. test con gli utenti;
9. disabilitazione degli account precedenti.

Il punto importante è comprendere che trasferire i file non significa necessariamente trasferire tutte le relazioni associate all’utente.

Le diverse applicazioni Nextcloud possono utilizzare riferimenti all’identità in modalità differenti.

Per questo motivo ogni ambiente deve essere analizzato individualmente.

Quando conviene trasferire i dati verso nuovi account

Questa strategia è generalmente adatta ad ambienti relativamente piccoli.

Ad esempio:

• 10 utenti;
• 20 utenti;
• piccoli gruppi aziendali;
• poche Team Folder;
• struttura delle condivisioni semplice.

Quando invece gli utenti diventano centinaia o migliaia e Nextcloud viene utilizzato da anni, ricostruire manualmente tutte le relazioni può diventare estremamente complesso.

In questi casi può essere preferibile preservare direttamente l’identità esistente.

Strategia 2: rimappare l’identità dell’utente

La seconda possibilità consiste nel fare in modo che il nuovo Identity Provider venga associato all’identità Nextcloud già esistente.

In altre parole, invece di creare un nuovo utente si cerca di modificare soltanto il modo in cui quell’utente viene autenticato.

L’identità Nextcloud rimane quindi la stessa.

Il concetto può essere rappresentato così:

Prima

LDAP → Utente Nextcloud → File / Gruppi / Condivisioni

Dopo

OpenID Connect → stesso Utente Nextcloud → stessi File / Gruppi / Condivisioni

Questa strategia può essere particolarmente interessante negli ambienti enterprise.

Una corretta strategia di mapping può consentire di conservare:

• proprietà dei file;
• condivisioni;
• appartenenza ai gruppi;
• autorizzazioni;
• Team Folder;
• configurazioni;
• riferimenti applicativi;
• cronologia delle collaborazioni.

Questo riduce notevolmente l’impatto della migrazione sugli utenti finali.

L’identity mapping è particolarmente interessante quando sono presenti:

• centinaia o migliaia di utenti;
• numerosi gruppi;
• molte condivisioni;
• Team Folder complesse;
• anni di dati;
• integrazioni con altre applicazioni.

Richiede però un’analisi tecnica molto più accurata.

Un mapping errato può infatti causare:

• account duplicati;
• perdita dell’accesso ai dati;
• associazione dell’identità all’utente sbagliato;
• problemi sui permessi;
• problemi nelle applicazioni integrate.

Uno degli scenari sempre più frequenti è il passaggio da LDAP a OpenID Connect (OIDC).

LDAP continua a essere ampiamente utilizzato come directory aziendale, ma le architetture moderne tendono sempre più spesso a separare:

Directory degli utenti

da

Sistema di autenticazione

In questa architettura Nextcloud non deve necessariamente verificare direttamente username e password.

Può delegare l’autenticazione a un Identity Provider.

Il modello diventa:

Utente → Identity Provider → Nextcloud

L’Identity Provider certifica l’identità dell’utente e Nextcloud concede l’accesso sulla base delle informazioni ricevute.

OpenID Connect, OAuth 2.0 e SAML

Nelle moderne architetture IAM si incontrano spesso tre tecnologie:

• OpenID Connect;
• OAuth 2.0;
• SAML.

È importante non confonderle.

In modo semplificato:

OAuth 2.0 riguarda principalmente la delega dell’autorizzazione.

OpenID Connect aggiunge a OAuth 2.0 un livello dedicato all’identità e all’autenticazione.

SAML è un protocollo di federazione delle identità molto diffuso nelle infrastrutture enterprise.

Nextcloud può essere integrato in architetture SSO che utilizzano queste tecnologie a seconda dello scenario.

Integrare Nextcloud con Microsoft Entra ID

Microsoft Entra ID è frequentemente utilizzato dalle aziende che utilizzano Microsoft 365 e servizi cloud Microsoft.

Integrare Nextcloud con Entra ID permette di inserire Nextcloud all’interno della stessa architettura centralizzata di autenticazione.

Questo può consentire di utilizzare funzionalità come:

• Single Sign-On;
• Multi-Factor Authentication;
• Conditional Access;
• gestione centralizzata degli account;
• policy aziendali;
• gestione del ciclo di vita degli utenti.

La parte più delicata della migrazione consiste nel determinare quale claim fornito da Entra ID deve essere associato all’utente Nextcloud esistente.

Il semplice utilizzo dell’indirizzo email può non essere sempre la soluzione più sicura perché l’email può cambiare nel corso della vita dell’utente.

Quando possibile è quindi preferibile progettare la relazione sulla base di identificatori stabili.

Integrare Nextcloud con Keycloak

Keycloak è una piattaforma open source particolarmente interessante quando si desidera mantenere un maggiore controllo sull’infrastruttura di autenticazione.

Supporta:

• OpenID Connect;
• OAuth 2.0;
• SAML;
• identity federation.

Keycloak può inoltre collegarsi a differenti sorgenti di identità, tra cui:

• LDAP;
• Active Directory;
• altri Identity Provider;
• directory aziendali;
• sistemi di autenticazione esterni.

È quindi possibile creare un’architettura come:

LDAP / Active Directory

↓

Keycloak

↓

Nextcloud

↓

altre applicazioni aziendali

Keycloak diventa in questo caso uno strato centralizzato di gestione dell’identità.

Cambiare l’autenticazione di Nextcloud può diventare l’occasione per ripensare l’intera architettura di Identity and Access Management.

Un sistema IAM centralizzato può permettere di gestire:

• autenticazione;
• Single Sign-On;
• Multi-Factor Authentication;
• provisioning;
• deprovisioning;
• gruppi;
• policy di accesso;
• federazione delle identità;
• applicazioni aziendali.

Nextcloud non rappresenta quindi un sistema isolato.

Diventa una delle applicazioni collegate alla piattaforma centrale di Identity Management.

Un possibile modello può essere:

Identity Provider

↓

Nextcloud
 ERP
 CRM
 VPN
 Applicazioni interne
 Portali aziendali

Questo consente di applicare policy di autenticazione coerenti a più servizi.

Cosa verificare prima di migrare Nextcloud

Prima della migrazione è consigliabile effettuare un assessment completo.

Tra gli elementi da verificare:

Utenti

• numero degli utenti;
• utenti attivi;
• utenti disabilitati;
• account di servizio;
• utenti locali Nextcloud.

Identificativi

• UID;
• UUID;
• attributi LDAP;
• objectGUID;
• username;
• email;
• claim OIDC.

Gruppi

• gruppi LDAP;
• gruppi locali;
• gruppi utilizzati nelle applicazioni;
• gruppi utilizzati nelle Team Folder.

Dati

• file personali;
• proprietà;
• condivisioni;
• storage esterni.

Applicazioni

Verificare tutte le applicazioni Nextcloud che possono memorizzare riferimenti agli utenti.

Team Folder

Controllare:

• proprietari;
• gruppi;
• ACL;
• permessi;
• condivisioni.

Perché serve un ambiente di test

Una migrazione dell’identità dovrebbe essere testata prima di essere applicata all’ambiente di produzione.

Idealmente dovrebbe essere predisposto un ambiente Nextcloud di test sufficientemente rappresentativo.

È opportuno verificare:

• autenticazione;
• riconoscimento dell’utente;
• file personali;
• proprietà;
• condivisioni;
• gruppi;
• Team Folder;
• applicazioni;
• provisioning;
• deprovisioning;
• account duplicati.

È particolarmente utile selezionare utenti con caratteristiche differenti.

Ad esempio:

• utente semplice;
• utente appartenente a molti gruppi;
• responsabile di Team Folder;
• utente con molte condivisioni;
• amministratore;
• utente presente da molti anni.

Migrazione Nextcloud: ambiente piccolo o infrastruttura enterprise?

Non esiste una strategia universale.

Per un ambiente piccolo potrebbe essere sufficiente:

nuovo account → trasferimento dati → verifica → dismissione vecchio account

Per una piattaforma enterprise può essere preferibile:

nuovo Identity Provider → identity mapping → mantenimento dell’utente esistente

La complessità cresce con il numero di relazioni presenti all’interno della piattaforma.

Un Nextcloud utilizzato da cinque anni da mille utenti può contenere milioni di relazioni tra:

• utenti;
• file;
• gruppi;
• condivisioni;
• permessi;
• applicazioni.

In questo scenario ricreare semplicemente gli account potrebbe non essere una strategia sostenibile.

La migrazione dell’Identity Provider è un progetto di Business Continuity

La migrazione dovrebbe quindi preservare una catena fondamentale:

Utente → Identità → Dati → Condivisioni → Gruppi → Permessi → Applicazioni

Cambiare il sistema di autenticazione senza preservare questa catena può interrompere i processi di collaborazione.

Per questo motivo il progetto dovrebbe comprendere:

1. assessment;
2. progettazione;
3. identity mapping;
4. ambiente di test;
5. migrazione pilota;
6. verifica;
7. migrazione definitiva;
8. monitoraggio post-migrazione.

Migrare Nextcloud da LDAP, Active Directory o da un altro backend di autenticazione verso OpenID Connect, Microsoft Entra ID o Keycloak richiede molto più della semplice configurazione di un nuovo sistema di login.

La vera sfida consiste nel preservare l’identità degli utenti e le relazioni costruite nel tempo all’interno della piattaforma.

Le principali strategie sono due:

1. Creazione di nuovi utenti e trasferimento dei dati

Approccio più semplice e adatto soprattutto agli ambienti di dimensioni ridotte.

2. Identity mapping verso gli utenti Nextcloud esistenti

Approccio generalmente più indicato negli ambienti enterprise complessi.

La scelta deve essere effettuata dopo aver analizzato:

• utenti;
• identificativi;
• gruppi;
• condivisioni;
• Team Folder;
• applicazioni;
• architettura IAM.

Una corretta migrazione non dovrebbe quindi limitarsi a sostituire il sistema con cui l’utente effettua il login.

Dovrebbe garantire continuità tra:

identità, dati, autorizzazioni e processi di collaborazione.

Emilio Veronesi