Migrare da Okta a FoxIDs

Trasferisci gli accessi da Okta a FoxIDs scegliendo l’approccio adatto al luogo in cui ogni gruppo si autentica. Importa utenti locali e consenti loro di scegliere una nuova password oppure abilita l’accesso senza password con codici monouso. Per gli accessi social e aziendali, configura metodi FoxIDs che considerino attendibili i provider esterni. Okta può anche restare provider di identità mentre le applicazioni passano a FoxIDs.

Questa guida tecnica riguarda gli utenti di Okta Universal Directory, la configurazione delle applicazioni e la mappatura degli account per Okta Identity Engine e Classic Engine.

Per importare utenti locali, converti l’esportazione Okta verificata in un CSV e usa FoxIDs Seed Tool per caricarli in blocco in FoxIDs. Gli esempi seguenti mostrano i campi per impostazione della password e accesso senza password.

Scegli un approccio per ogni gruppo:

Preparare la destinazione e l’applicazione

Un ambiente di test dedicato permette di provare la migrazione con un piccolo gruppo di utenti prima del passaggio in produzione. I passaggi di configurazione sono:

1. Se desideri un dominio personalizzato, configuralo e verificalo nel tenant prima di configurare applicazioni e provider di identità esterni. Usa gli URL FoxIDs risultanti per tutta la migrazione. Modificare il dominio in seguito richiede l’aggiornamento delle configurazioni esterne, inclusi gli URL di autorità o metadati delle applicazioni e gli URL di callback e disconnessione dei provider.
2. Ogni ambiente dispone di un metodo di autenticazione Login predefinito chiamato login. Personalizza branding e interfaccia di accesso per ottenere l’aspetto desiderato e adatta le opzioni di accesso agli utenti importati.
3. Crea i metodi di autenticazione che collegano gli utenti ai provider esterni, incluso Okta se resta parte della transizione.
4. Configura l’applicazione, gli URL di reindirizzamento consentiti, il comportamento di disconnessione e le API che accettano i suoi token di accesso.

FoxIDs Cloud offre l’invio di e-mail e SMS per impostare password, accedere senza password e usare l’autenticazione a più fattori (MFA), in base al piano FoxIDs Cloud selezionato.

Configura le impostazioni MFA necessarie e le modalità di registrazione. Gli import CSV descritti trasferiscono dati utente, non registrazioni Okta Verify, registrazioni di dispositivi FastPass, passkey o altre registrazioni MFA. Gli utenti che si autenticano localmente in FoxIDs registrano i fattori configurati. Chi continua tramite Okta può mantenere le proprie registrazioni Okta.

La configurazione delle applicazioni è un’attività separata dall’importazione degli utenti. Verifica emittente, destinatari, ambiti, claim e convalida dei token, oltre a dipendenze da SDK Okta o Sign-In Widget, inline hook, regole dei gruppi e assegnazioni delle applicazioni. Ricrea il comportamento richiesto dall’applicazione. La guida generale alla migrazione descrive l’inventario complessivo e le fasi di distribuzione.

Esportare un gruppo definito di utenti Okta

Usa Okta Users API per recuperare dati utente in JSON da convertire. Seleziona l’organizzazione di origine e gli utenti o gruppi da migrare. Segui l’URL rel="next" nell’intestazione di risposta Link fino a leggere tutte le pagine. L’operazione di elenco ordinaria omette gli utenti DEPROVISIONED; un filtro o una ricerca può includerli. I risultati di ricerca sono a consistenza eventuale, quindi le modifiche recenti possono apparire in ritardo.

Conserva organizzazione di origine, id utente, status del ciclo di vita, attributi profile necessari e informazioni credentials.provider. Mantieni distinguibili utenti gestiti da Okta, basati su directory e federati. Configurazione dei provider e regole di instradamento aiutano a identificare dove gli utenti si autenticano realmente.

Per un’esportazione basata su report, il report User Accounts offre CSV Export. Le colonne richiedono comunque conversione nel formato FoxIDs Seed Tool. L’API è utile se servono attributi personalizzati o informazioni sui provider assenti dal report.

Esporta separatamente appartenenza ai gruppi e accesso alle applicazioni quando determinano le autorizzazioni. I report Okta Group Membership e User App Access descrivono queste relazioni; non sono tutte contenute nell’oggetto profile dell’utente.

Disponibilità delle password

Okta offre soltanto l’esportazione degli hash delle password per migrare ad Auth0, subordinata a criteri specifici.

FoxIDs può importare gli hash delle password supportati quando sono disponibili.

Mappare i dati utente e preservare gli account applicativi

FoxIDs crea un proprio ID persistente per gli utenti locali importati. Importare l’id utente Okta come claim personalizzato non lo rende l’ID FoxIDs né preserva automaticamente il soggetto dell’applicazione. Registra il vero sub OpenID Connect o NameID SAML usato da ogni applicazione insieme a organizzazione di origine e ID utente.

Se l’applicazione usa l’ID utente Okta come sub, importalo come claim personalizzato, ad esempio legacy_okta_user_id. Nel metodo Login configura una trasformazione di claim Map con azione Replace claim, claim di input legacy_okta_user_id e di output sub. L’applicazione riceve questo valore come sub, mentre l’ID persistente FoxIDs resta invariato. Se usa un altro valore di soggetto, conserva e mappa quel valore.

Le applicazioni che identificano gli account tramite emittente e soggetto devono anche associare il nuovo emittente FoxIDs agli account esistenti. Per applicazioni SAML, configura NameID e formato necessari nella registrazione dell’applicazione SAML. Un accesso di test mostra l’identità realmente ricevuta dall’applicazione.

Mantieni un’associazione tra identità di origine, nuova identità FoxIDs e account applicativo esistente. Le identità usate durante la transizione devono riferirsi allo stesso record cliente o dipendente. Per gli accessi social e aziendali, includi l’identità ricevuta direttamente dal provider; può differire dall’ID utente Okta.

Per importare utenti locali, usa la seguente mappatura:

Gli stati del ciclo di vita Okta sono più dettagliati del flag di disabilitazione FoxIDs. Gli esempi abilitano utenti selezionati da account ACTIVE e mantengono disabilitati quelli sospesi. Stati come STAGED, PROVISIONED, RECOVERY, PASSWORD_EXPIRED e LOCKED_OUT richiedono una mappatura esplicita al comportamento previsto di attivazione, impostazione password o accesso.

Migrare gli accessi social e aziendali

Crea un metodo FoxIDs per ogni provider social o aziendale attualmente collegato tramite Okta, stabilendo una relazione di fiducia diretta. Gli utenti mantengono account e credenziali presso il provider.

1. Identifica il provider di ogni connessione. Usa la guida di integrazione pertinente, ad esempio Google o Microsoft Entra ID, e seleziona il metodo supportato OpenID Connect, SAML 2.0 o WS-Federation.
2. Registra o configura FoxIDs presso il provider. Scambia impostazioni client o metadati di federazione e configura gli URL di callback e disconnessione indicati nella guida. Mantieni la connessione Okta durante la transizione.
3. Consenti il nuovo metodo di autenticazione nell’applicazione FoxIDs. Configura Home Realm Discovery affinché gli utenti possano selezionare il provider o esservi indirizzati dalle regole configurate.
4. Associa l’identità del provider all’account applicativo esistente. Se devi conservare claim o assegnazioni di accesso per utente in FoxIDs, configura e provisiona utenti esterni.
5. Ricrea le restrizioni di accesso applicate in precedenza da Okta, incluse assegnazioni delle applicazioni, utenti sospesi e MFA richiesta.

Il flusso previsto è applicazione → FoxIDs → provider di identità esterno → FoxIDs → applicazione. FoxIDs emette i token dell’applicazione dopo che il provider ha autenticato l’utente.

Puoi provare ogni connessione avviando l’accesso dall’applicazione, selezionando il provider e completando il suo flusso. Puoi così osservare MFA, account e autorizzazioni nell’applicazione e comportamento di disconnessione.

Migrare utenti da Active Directory

Se Okta delega l’autenticazione con password ad Active Directory e AD resta l’origine, FoxIDs può collegarsi direttamente tramite Directory Connector per Active Directory. Configura connettore e metodo Login secondo quella guida. FoxIDs sincronizza utenti da AD e verifica le password in AD, quindi questi utenti non richiedono import CSV delle password.

Per impostazione predefinita, FoxIDs salva una copia locale della password dopo la convalida riuscita di Directory Connector. Ciò consente un successivo passaggio all’autenticazione locale FoxIDs disabilitando il connettore. Gli utenti le cui password non sono state acquisite possono usare l’impostazione della password. Consulta il comportamento delle password di Directory Connector per le opzioni.

Un utente Okta proveniente da AD non si autentica necessariamente ancora in AD: Okta può migrare l’autenticazione con password da AD a Okta. Il connettore diretto si applica quando AD conserva e convalida ancora la password usata.

Migrare gli utenti senza password

Importa gli utenti come interni FoxIDs senza password e configura l’accesso senza password con codice e-mail o SMS. L’utente inserisce il codice nella pagina di accesso già aperta.

Questo comporta un cambio di metodo di autenticazione per gli utenti di Okta FastPass o passkey. I codici e-mail e SMS non offrono la stessa resistenza al phishing di FastPass.

1. Abilita e-mail o telefono come identificatore di accesso nel metodo FoxIDs Login e abilita Passwordless with email (one-time password) o Passwordless with SMS (one-time password) secondo necessità.
2. Per un metodo dedicato agli utenti senza password, seleziona Disable password authentication e disabilita impostazione/reimpostazione della password tramite e-mail e SMS.
3. Importa gli utenti omettendo Password e tutti i campi di hash. Mantieni SetPasswordEmail, SetPasswordSms e ChangePassword su false. Preserva stato di verifica mappato, stato di disabilitazione e claim necessari.

Ad esempio, questo CSV di Seed Tool importa un utente fittizio senza password via e-mail il cui precedente stato di verifica dell’e-mail è sconosciuto:

Email;EmailVerified;SetPasswordEmail;SetPasswordSms;ChangePassword;DisableAccount;Claims
alice@example.com;false;false;false;false;false;"[{""Claim"":""legacy_okta_user_id"",""Values"":[""00u000000000DEMO001""]}]"

Per utenti SMS, sostituisci Email ed EmailVerified con Phone e PhoneVerified, usando numero scelto e stato di verifica noto. Si applica la stessa procedura di caricamento.

Puoi provare il flusso con un utente importato di test inserendo e-mail o telefono e codice ricevuto. Un codice valido consente a un utente abilitato di proseguire attraverso la MFA richiesta fino all’applicazione. L’utente resta senza password dopo un accesso senza password riuscito.

Importare utenti per l’impostazione della password

Abilita accesso via e-mail, autenticazione con password e impostazione della password via e-mail nel metodo FoxIDs Login. Gli utenti importati scelgono una password durante il primo accesso.

L’importazione prepara gli account. L’impostazione della password avviene quando ogni utente avvia un accesso, non durante l’importazione.

Converti i record verificati in un file UTF-8 per FoxIDs Seed Tool. Le intestazioni distinguono maiuscole e minuscole e il separatore è il punto e virgola. L’esempio contiene utenti fittizi con precedente stato di verifica dell’e-mail sconosciuto; il secondo account resta disabilitato:

Email;EmailVerified;SetPasswordEmail;DisableAccount;RequireMultiFactor;Claims
alice@example.com;false;true;false;true;"[{""Claim"":""legacy_okta_user_id"",""Values"":[""00u000000000DEMO001""]}]"
suspended@example.com;false;true;true;true;"[{""Claim"":""legacy_okta_user_id"",""Values"":[""00u000000000DEMO002""]}]"

SetPasswordEmail=true seleziona l’impostazione della password con conferma via e-mail. Ometti Password e tutte le colonne di hash. RequireMultiFactor=true è il criterio scelto nell’esempio e richiede la configurazione dei metodi MFA corrispondenti.

Trasmetti il claim di esempio legacy_okta_user_id solo alle applicazioni che ne hanno bisogno tramite la loro gestione configurata dei claim.

Caricare gli utenti ed esaminare il risultato

Usa questa procedura per utenti senza password e utenti che sceglieranno una password al primo accesso, con i campi adatti al metodo scelto.

Seed Tool divide i campi sui punti e virgola; i campi tra virgolette non possono contenere punti e virgola o interruzioni di riga. Usa le operazioni utente della Control API se i valori richiedono una rappresentazione d’importazione più ricca.

1. Scarica e configura Seed Tool per l’ambiente previsto. Imposta SeedSettings.UsersSvcPath sul file CSV convertito.
2. Esegui Seed Tool e seleziona U per caricare gli utenti in blocco.
3. Registra i nuovi ID utente nella mappatura di migrazione.

Puoi provare il caricamento con un CSV di pochi utenti in un ambiente di test. Seed Tool riporta il numero di operazioni riuscite e fallite. Puoi esaminare gli utenti importati in FoxIDs Control per vedere identificatori, stato di disabilitazione, claim e flag di impostazione della password.

Seed Tool usa il provisioning in blocco, che può sostituire utenti esistenti anziché unirli. Ripetere il caricamento può rimuovere credenziali e stato e creare nuovi ID. Per un’importazione parziale, riconcilia il risultato prima di riprovare; usa aggiornamenti mirati per le modifiche successive.

Impostazione della password al primo accesso

Per un utente importato abilitato con SetPasswordEmail=true, il flusso previsto è:

1. L’utente apre l’applicazione e avvia l’accesso tramite FoxIDs Login.
2. FoxIDs identifica l’utente dall’indirizzo e-mail e invia un codice di conferma.
3. L’utente invia il codice e una nuova password conforme ai criteri FoxIDs.
4. FoxIDs verifica l’e-mail, salva la password e azzera i flag di impostazione. L’accesso prosegue attraverso gli eventuali passaggi MFA richiesti prima di tornare all’applicazione.

Importare un utente non invia l’e-mail di impostazione. Gli accessi successivi con password usano la nuova password FoxIDs. Se l’utente non può ricevere il codice, la procedura di recupero deve verificare l’identità in altro modo.

Puoi esplorare il flusso con un utente di test seguendo i passaggi precedenti. Questi scenari mostrano i risultati previsti:

Mantenere Okta durante la transizione

FoxIDs può considerare Okta un provider esterno attendibile mentre le applicazioni passano a FoxIDs. Gli utenti si autenticano in Okta e FoxIDs emette token per l’applicazione. Password e autenticatori Okta restano in Okta; non vengono copiati in FoxIDs.

Per una connessione OpenID Connect:

1. Crea in Okta un’integrazione di applicazione web OIDC per FoxIDs con Authorization Code Flow. Assegna utenti o gruppi che accederanno tramite l’integrazione e configura i criteri di accesso.
2. Crea un metodo di autenticazione OpenID Connect in FoxIDs. Imposta Authority sull’emittente Okta scelto e configura l’ID client Okta in Optional custom SP client ID, il relativo segreto e il metodo corrispondente di autenticazione client dell’endpoint token.
3. Richiedi gli ambiti profile ed email secondo necessità; FoxIDs include openid. Seleziona Read claims from the UserInfo Endpoint instead of the access token or ID token in Show advanced per ottenere i claim dell’utente tramite UserInfo.
4. Registra il Redirect URL mostrato da FoxIDs come URI di reindirizzamento di accesso in Okta e configura il corrispondente URI di disconnessione dove usato.
5. Consenti il metodo nell’applicazione FoxIDs e configura Home Realm Discovery per gli utenti che continuano tramite Okta.

Il server di autorizzazione dell’organizzazione Okta supporta l’accesso OpenID Connect con un emittente come https://example.okta.com. Un server personalizzato usa un emittente come https://example.okta.com/oauth2/default. Usa emittente e configurazione dei claim scelti per l’integrazione.

Un’altra opzione è un metodo di autenticazione SAML: crea un’applicazione SAML in Okta per FoxIDs e scambia metadati e impostazioni di service provider e identity provider.

Un accesso di test dall’applicazione mostra criteri di autenticazione Okta, claim, associazione degli account e disconnessione per la nuova connessione. Quando gli utenti passano all’accesso locale FoxIDs o a provider diretti, indirizzali a quei metodi. Mantenere allineata l’associazione degli account tra i metodi permette di continuare a usare gli stessi record.

Distribuire e mantenere un percorso di rollback

La migrazione può essere distribuita per applicazione o gruppo. Gli utenti possono continuare tramite l’URL abituale con il flusso configurato: impostazione della password, codice monouso, password della directory o provider esterno.

Riconcilia gli utenti creati, modificati, sospesi o eliminati dopo l’esportazione, incluse modifiche a gruppi e assegnazioni delle applicazioni. Un breve blocco delle modifiche o una riconciliazione controllata può mantenere allineati origine e destinazione durante il passaggio. Gli aggiornamenti successivi devono preservare credenziali e stato già stabiliti in FoxIDs.

Monitora consegna di e-mail e SMS, errori di impostazione della password, accessi falliti e problemi di associazione degli account. Il rollback richiede che la precedente configurazione Okta resti disponibile. Puoi provare a ripristinarla per un’applicazione di test e osservare il ritorno al flusso Okta.

Una password impostata localmente in FoxIDs non viene sincronizzata nuovamente in Okta. Il rollback usa quindi le credenziali ancora conservate in Okta o nel provider collegato. Gli utenti creati solo in FoxIDs necessitano di un percorso di accesso in caso di rollback. Quando utenti e applicazioni necessari usano i metodi di destinazione, l’integrazione Okta può essere ritirata.

Documentazione correlata

• Panoramica della migrazione
• Caricare molti utenti
• Operazioni utente della Control API
• Accesso e Home Realm Discovery
• Directory Connector for Active Directory
• Metodo di autenticazione OpenID Connect