Migrazione

La migrazione ai FoxIDs normalmente combina la migrazione delle applicazioni, la migrazione degli utenti e una transizione controllata tra la piattaforma di identità esistente e i FoxIDs. Pianifica insieme questi flussi di lavoro in modo che identificatori, claim, comportamento di autenticazione e opzioni di rollback rimangano coerenti durante tutta la transizione.

I tenant FoxIDs supportano ambienti separati. Utilizza ambienti di sviluppo, test, gestione temporanea e produzione dedicati per configurare e convalidare i flussi di migrazione in parallelo senza modificare prematuramente l'ambiente di produzione.

Valutare la piattaforma di identità esistente

Inizia registrando:

Applicazioni, API e ambienti collegati alla piattaforma esistente.
Configurazioni OpenID Connect, OAuth 2.0, SAML 2.0 e WS-Federation.
Provider di identità, metodi di autenticazione e requisiti di autenticazione a più fattori.
Identificatori utente, profili, claim, gruppi, ruoli e assegnazioni di accesso.
Opzioni di archiviazione, convalida e reimpostazione della password disponibili nella piattaforma di origine.
Certificati, metadati, URL di reindirizzamento, comportamento di disconnessione e durata dei token.
Requisiti di monitoraggio, audit e rollback per il cut-over.

L'origine può essere AD FS, Active Directory, Keycloak, Auth0, Okta, Microsoft Entra ID o un altro provider di identità o repository utente personalizzato. Il percorso di migrazione disponibile dipende dai protocolli, dalle funzionalità di esportazione e dalle opzioni di convalida della password forniti da tale origine.

Migrazione dell'applicazione

Migrare le applicazioni in base al protocollo e all'ambiente anziché trattare il patrimonio come un unico passaggio.

Registrare l'applicazione in un ambiente FoxIDs non di produzione.
Riprodurre le claim, gli ambiti, gli identificatori, i certificati e il comportamento di disconnessione richiesti.
Connetti il provider di identità esistente come metodo di autenticazione quando è richiesta l'autenticazione parallela.
Testa il flusso completo di accesso, token e disconnessione con utenti e integrazioni rappresentativi.
Sposta un gruppo controllato o un'applicazione alla volta prima di un'implementazione più ampia.

FoxIDs ponte tra protocolli consente a un'applicazione di mantenere il protocollo corrente mentre il lato del provider di identità cambia. Ciò è utile quando le moderne applicazioni OpenID Connect e le applicazioni SAML 2.0 o WS-Federation esistenti devono funzionare durante lo stesso periodo di migrazione.

Profili utente e identificatori

Decidi quale identificatore rimane stabile prima di importare o creare utenti. Gli indirizzi email, i numeri di telefono e i nomi utente possono cambiare, quindi utilizza un identificatore di origine stabile laddove l'integrazione ne supporta uno.

Mappare le informazioni utente richieste dopo la migrazione:

Proprietà del profilo utente e identificatori di accesso.
Claim utilizzate da applicazioni e API.
Gruppi, ruoli e assegnazioni di accesso.
Requisiti di autenticazione a più fattori e approccio di registrazione o ripristino dopo la migrazione.
Account disabilitati, cancellati o altrimenti limitati.

Utilizza Carica molti utenti quando gli utenti possono essere esportati e importati in batch. Utilizza Directory Connector quando una directory esistente o un repository personalizzato deve rimanere autorevole durante la transizione. Per Active Directory, utilizzare Directory Connector for Active Directory.

Strategia per la password

Scegli il percorso della password in base a ciò che la piattaforma di origine può esporre o convalidare in modo sicuro:

Importa le password o gli hash delle password supportati solo quando sono disponibili in un formato compatibile e possono essere gestiti in modo sicuro.
Convalidare la password esistente tramite Directory Connector mentre la directory di origine rimane autorevole.
Per impostazione predefinita, FoxIDs salva una copia della password locale dopo la corretta convalida del connettore di directory. Ciò rende possibile disabilitare il connettore in un secondo momento e spostare la convalida della password sui FoxIDs senza forzare la reimpostazione di ogni utente.
Disabilitare la copia della password locale quando i criteri richiedono che la directory esterna rimanga l'unico archivio di password.
Richiedere la reimpostazione della password quando l'importazione o la conservazione della password esistente non è tecnicamente possibile o quando la reimpostazione è l'opzione più sicura.

Non dare mai per scontato che le password possano essere spostate direttamente da un provider di identità. Conferma il formato di esportazione della piattaforma di origine, l'algoritmo di hashing, l'API di convalida e i vincoli di sicurezza prima di selezionare il metodo di migrazione.

Migrazione graduale

Laddove la directory di origine supporta la convalida in linea, gli utenti possono essere creati o aggiornati nei FoxIDs al primo accesso riuscito tramite Directory Connector. Ciò supporta una transizione graduale senza richiedere la migrazione di tutti gli utenti contemporaneamente.

Mantieni l'origine disponibile fino alla migrazione della popolazione di utenti richiesta e alla chiusura della finestra di rollback. Monitora gli accessi non riusciti, i conflitti di identificatori, le claim mancanti e la disponibilità dei connettori durante tutta la transizione.

Cut-over e rollback

Prima del taglio della produzione:

Completare test applicativi rappresentativi e di accettazione da parte degli utenti.
Conferma certificati, metadati, DNS, URL di reindirizzamento e percorsi firewall.
Definisci l'ordine in cui si spostano applicazioni, API e gruppi di utenti.
Registra la configurazione precedente e le condizioni che attivano il rollback.
Garantire che il monitoraggio e la registrazione coprano sia i FoxIDs che i rimanenti flussi della piattaforma di origine.
Comunica la reimpostazione della password o la modifica del comportamento di accesso prima che ciò influisca sugli utenti.

Un'implementazione graduale limita il numero di applicazioni e utenti interessati da ciascuna modifica. Mantenere il rollback tecnicamente possibile fino a quando il comportamento di produzione, le rivendicazioni e l'accesso non saranno stati verificati.