La migrazione delle password non è una copia del database. Quando gli utenti vengono trasferiti tra identity provider, spesso l’origine non può fornire una password riutilizzabile dalla destinazione. Anche se un’esportazione contiene hash delle password, un hash prodotto per una piattaforma non è automaticamente valido su un’altra.
In alcuni casi gli utenti possono mantenere la password esistente senza una reimpostazione forzata. Il metodo sicuro dipende da ciò che l’origine può esportare, dalla sua capacità di convalidare le password online, dal tempo per cui può restare disponibile e dalla possibilità di associare ogni account a un identificatore stabile dell’origine.
Questo articolo offre un modello decisionale per scegliere tra import compatibile, convalida graduale delle password, convalida esterna continuata e reimpostazione controllata. Si concentra sul percorso delle password. I protocolli applicativi, i claims, la registrazione della multi-factor authentication (MFA) e il piano completo di cut-over devono comunque essere gestiti come flussi di migrazione collegati.
Parti dall’origine, non dall’esperienza utente desiderata
«Nessuna reimpostazione della password» è un risultato auspicabile, ma non è ancora un metodo di migrazione. Prima di scegliere un approccio, stabilisci cosa può effettivamente supportare l’origine:
- Può esportare password in chiaro o una rappresentazione della password supportata esplicitamente dalla destinazione?
- Può convalidare la password corrente dell’utente tramite un’API di convalida protetta?
- Questa API può restare disponibile, monitorata e supportata durante una migrazione graduale e la finestra di rollback?
- Esiste un identificatore utente stabile e immutabile dell’origine che associ lo stesso account nonostante le modifiche agli identificatori?
- Le modifiche e le reimpostazioni delle password possono restare coerenti mentre sono coinvolti due sistemi?
- La policy di sicurezza, i contratti e la valutazione del rischio consentono di importare o conservare materiale relativo alle password?
Non utilizzare indirizzo e-mail, numero di telefono o nome utente come unica chiave di migrazione. Questi identificatori possono cambiare. Un’associazione errata degli account è più grave di una reimpostazione perché può collegare credenziali e accessi all’identità sbagliata.
Scegli uno dei quattro percorsi per le password
Popolazioni di utenti diverse possono richiedere percorsi diversi. Ad esempio, i dipendenti attivi possono migrare gradualmente tramite convalida online, mentre gli account esterni inattivi ricevono una reimpostazione al ritorno dell’utente.
| Capacità e vincolo dell’origine | Percorso difendibile | Vantaggio principale | Costo o rischio principale |
|---|---|---|---|
| Sono disponibili password o una rappresentazione compatibile con la destinazione e possono essere gestite in sicurezza | Import batch controllato | Gli utenti possono autenticarsi immediatamente nella destinazione | Esportazione, trasporto e trattamento del materiale relativo alle password ampliano il confine di sicurezza |
| L’origine può convalidare online le password esistenti e restare autoritativa durante la transizione | Migrazione graduale con Directory Connector | Gli utenti attivi vengono trasferiti dopo un accesso riuscito senza una reimpostazione generale | Origine e connector restano nel percorso di authentication in produzione fino al cut-over |
| Gli utenti sono già presenti in FoxIDs e solo convalida delle password, controllo della policy o notifica delle modifiche restano esterni | External Password API | Mantiene un’integrazione più limitata con l’archivio password o la policy | Non offre lo stesso flusso di creazione utenti e sincronizzazione dei profili di Directory Connector |
| Non sono disponibili né un import compatibile sicuro né una convalida online affidabile | Reimpostazione verificata della password | Stabilisce una nuova password di destinazione con un confine di trust chiaro | Comunicazione agli utenti, canali di recupero e capacità del supporto diventano essenziali |
La risposta quindi non è sempre «conserva» o sempre «reimposta». Per ogni popolazione scegli il percorso meno invasivo che sia ancora difendibile dal punto di vista tecnico e operativo.
Migrazione graduale con Directory Connector
Directory Connector è il principale modello FoxIDs quando una directory esistente o un repository personalizzato deve restare autoritativo durante la transizione.
Quando un utente accede con una password, FoxIDs chiama l’API del connector. Dopo una convalida riuscita, FoxIDs crea o aggiorna l’utente interno usando gli identificatori, le proprietà e i claims restituiti. La risposta include un directoryUserId stabile che associa l’utente in FoxIDs all’account di origine anche se indirizzo e-mail, numero di telefono o nome utente cambiano in seguito.
Questo crea un pratico flusso just-in-time:
- L’utente accede a un’applicazione tramite FoxIDs con l’identificatore e la password esistenti.
- FoxIDs chiede alla directory di origine di convalidare la password.
- Il connector restituisce l’identificatore stabile dell’origine e i dati utente approvati.
- FoxIDs crea o aggiorna l’utente interno e completa l’authentication.
- L’utente può continuare a usare la password esistente finché l’origine resta autoritativa.
Per impostazione predefinita, FoxIDs salva anche una copia locale della password dopo una convalida riuscita del connector o un’operazione del ciclo di vita della password eseguita tramite il connector. Questa copia consente un passaggio pianificato successivo alla convalida delle password in FoxIDs senza reimpostare la password di ogni utente che ha completato il flusso graduale.
Il confine è importante: finché Directory Connector è abilitato, la directory esterna resta autoritativa. FoxIDs non usa l’hash locale salvato come fallback automatico se il connector non è disponibile. Un’interruzione del connector è quindi un errore nel percorso di authentication, non un’indicazione di aggirare l’origine.
L’interruttore della policy password mostrato di seguito è una terza decisione indipendente. Controlla se FoxIDs verifica una password proposta rispetto alla policy dell’ambiente FoxIDs prima di chiamare il connector. La directory esterna resta responsabile della password e può rifiutarla in base alla propria policy. Se vengono usati entrambi i controlli, requisiti e indicazioni per l’utente devono essere allineati.
Definisci i criteri di uscita prima di abilitare il connector
Una migrazione graduale richiede una condizione di fine. Prima del rollout, stabilisci:
- Quali popolazioni di utenti devono aver completato un accesso riuscito prima del cut-over?
- Come verranno gestiti gli account inattivi o quelli degli utenti che non tornano mai?
- Per quanto tempo origine e connector devono restare disponibili per il rollback?
- Quali latenze e tassi di errore del connector devono arrestare o invertire il rollout?
- Come verranno analizzati conflitti tra identificatori, claims mancanti e account di origine disabilitati o eliminati?
- Quando è possibile disabilitare il connector e rendere FoxIDs autoritativo per le password?
Il salvataggio di una copia locale è facoltativo. Disabilitalo quando una policy richiede che l’origine resti l’unico archivio password, ma considera che così viene rimossa la possibilità di un passaggio successivo senza reimpostazione.
Quando External Password API è l’opzione più limitata
FoxIDs può configurare un External Password API come controllo delle password per gli utenti interni. Può convalidare una password corrente, verificare una nuova password rispetto a una policy esterna, notificare a un altro sistema le modifiche delle password o combinare queste responsabilità.
Usa questa opzione quando gli utenti esistono già in FoxIDs e l’esigenza restante riguarda in modo specifico l’archivio o la policy delle password. Non considerarla un sostituto di Directory Connector quando la migrazione richiede anche la creazione just-in-time degli utenti, un’associazione stabile a una directory esterna, aggiornamenti del profilo o gestione del ciclo di vita degli account esterni.
Questa distinzione rende esplicito il confine di integrazione: Directory Connector rappresenta una directory esterna autoritativa. External Password API rappresenta una dipendenza esterna per convalida, policy o notifiche relative alle password degli utenti interni.
Quando l’import batch è giustificato
L’import batch può eliminare la dipendenza runtime dall’origine, ma solo quando l’input è adatto alla destinazione e può essere protetto per tutto il trasferimento.
FoxIDs supporta il caricamento di utenti interni con password note, con hash delle password precalcolati compatibili con FoxIDs o senza password. Un hash proveniente da una piattaforma di origine qualsiasi non può essere semplicemente definito hash FoxIDs. Verifica l’algoritmo esatto, il salt e il formato di destinazione prima di decidere che un hash esportato sia riutilizzabile.
Tratta l’esportazione di password in chiaro come una decisione di sicurezza, non come una comodità. Limita l’accesso, utilizza un percorso di trasferimento controllato, impedisci che le password finiscano nei log o nei normali file di progetto, verifica l’eliminazione del materiale temporaneo e documenta chi ha approvato l’operazione. Se questa gestione non è difendibile, scegli invece la convalida online o la reimpostazione.
Quando la reimpostazione della password è più sicura
Una reimpostazione non indica necessariamente una migrazione fallita. È il percorso corretto quando mantenere la password esistente indebolirebbe la destinazione o dipenderebbe da ipotesi che il team non può verificare.
Preferisci una reimpostazione controllata quando:
- l’origine non può esportare una rappresentazione compatibile né convalidare online la password corrente;
- lo spostamento del materiale relativo alle password creerebbe un’esposizione inaccettabile o un problema contrattuale;
- la password nell’origine è compromessa o si sospetta che lo sia;
- gli account non possono essere correlati con sufficiente certezza a identità di origine stabili;
- l’origine non può restare affidabile per il periodo necessario di migrazione graduale e rollback; oppure
- mantenere la vecchia password richiederebbe controlli più deboli nella destinazione.
Gli utenti in FoxIDs possono essere caricati senza password e invitati a impostarne una mediante un codice di verifica inviato via e-mail o SMS. È sicuro solo quando l’identificatore di recupero appartiene all’utente previsto e il canale di consegna soddisfa i requisiti di rischio dell’organizzazione. Prima di un rollout ampio, testa codici scaduti, caselle e-mail o numeri di telefono non raggiungibili, identificatori duplicati, account bloccati e l’escalation al supporto.
Comunica il motivo e la tempistica prima che gli utenti incontrino la reimpostazione. Separa la decisione di sicurezza dal piano di supporto: una progettazione corretta può comunque fallire operativamente se i canali di recupero sono obsoleti o il service desk non riesce a gestire il carico iniziale.
Richiedi evidenze prima del cut-over delle password
Testa il percorso scelto in un ambiente FoxIDs separato e trasferisci prima una popolazione controllata. Un accesso riuscito è necessario, ma non sufficiente.
| Area decisionale | Evidenza richiesta prima di un rollout più ampio |
|---|---|
| Associazione dell’identità | Identificatori di origine stabili, modifiche degli identificatori testate e gestione definita di duplicati o utenti mancanti |
| Comportamento delle password | Password accettate e rifiutate, flusso per password scaduta, modifica/reimpostazione ed errori di policy |
| Disponibilità | Monitoraggio del connector o dell’API di convalida, timeout, gestione degli errori e responsabile operativo nominato |
| Migrazione degli utenti | Risultati pilota per account rappresentativi attivi, inattivi, disabilitati e limitati |
| Sicurezza | Gestione approvata del materiale relativo alle password, secrets protetti, logging diagnostico senza password e conservazione dei dati verificata |
| Cut-over | Criteri di uscita per popolazione, gestione degli utenti senza password di destinazione salvata, trigger di rollback e responsabile del ritiro dell’origine |
Mantieni disponibile l’origine finché la popolazione richiesta non è stata migrata e la finestra di rollback non è chiusa. Non disabilitare il connector solo perché il pilota ha avuto successo. Verifica il percorso delle password di destinazione per la popolazione che deve funzionare dopo il cut-over e conserva un percorso di reimpostazione controllato per gli altri utenti.
Come FoxIDs supporta la decisione
Usa la documentazione sulla migrazione per pianificare insieme applicazioni, utenti, password, cut-over e rollback. La documentazione di Directory Connector, External Password API e caricamento degli utenti contiene i dettagli esatti di implementazione.
Se le capacità dell’origine, le popolazioni di utenti o i criteri di cut-over non sono ancora chiari, FoxIDs Identity Migration descrive come il team che sviluppa la piattaforma può aiutare a progettare e realizzare la migrazione.
Conclusione
Gli utenti possono mantenere una password esistente solo quando la migrazione conserva un percorso di convalida affidabile o stabilisce in modo sicuro una password di destinazione compatibile. Directory Connector offre spesso il percorso graduale meno invasivo, ma mantiene anche l’origine nel flusso di authentication in produzione fino a un cut-over deliberato.
Scegli la reimpostazione quando non è possibile dimostrare compatibilità, associazione dell’identità o gestione sicura. La strategia password corretta rende espliciti l’origine autoritativa, il comportamento in caso di errore, l’impatto sugli utenti e i criteri di uscita prima di spostare il traffico di produzione.