Migrer d’Okta vers FoxIDs

Transférez les connexions d’Okta vers FoxIDs avec l’approche de migration adaptée au lieu d’authentification de chaque groupe. Importez les utilisateurs locaux et laissez-les choisir un nouveau mot de passe, ou activez la connexion sans mot de passe avec des codes à usage unique. Pour les connexions sociales et d’entreprise, configurez des méthodes d’authentification FoxIDs faisant confiance aux fournisseurs d’identité externes. Okta peut aussi rester fournisseur d’identité pendant le transfert des applications vers FoxIDs.

Ce guide technique couvre les utilisateurs d’Okta Universal Directory, la configuration des applications et le mapping des comptes pour Okta Identity Engine et Classic Engine.

Pour l’import des utilisateurs locaux, convertissez l’export Okta vérifié en fichier CSV et utilisez le FoxIDs Seed Tool pour charger les utilisateurs en masse dans FoxIDs. Les exemples CSV ci-dessous présentent les champs de création du mot de passe et de connexion sans mot de passe.

Choisissez une approche pour chaque groupe :

Méthode	Prérequis	Première connexion
Importer les utilisateurs pour la création du mot de passe	Des données utilisateur et une adresse e-mail pour créer le mot de passe.	L’utilisateur se connecte et définit un mot de passe avec un code reçu par e-mail.
Migrer les utilisateurs sans mot de passe	Des données utilisateur et un flux de connexion adapté par e-mail ou SMS.	L’utilisateur saisit un code à usage unique et conserve un compte sans mot de passe.
Migrer les connexions sociales et d’entreprise	Une méthode d’authentification FoxIDs configurée pour faire confiance à chaque fournisseur d’identité externe.	L’utilisateur se connecte auprès de son fournisseur existant.
Connecter directement Active Directory	Active Directory valide toujours les mots de passe des utilisateurs.	L’utilisateur se connecte avec son mot de passe AD via FoxIDs Login.
Conserver Okta pendant la transition	Une connexion OpenID Connect ou SAML de FoxIDs vers Okta.	L’utilisateur s’authentifie chez Okta avec les méthodes autorisées par ses politiques.

Préparer la destination et l’application

Un environnement de test dédié permet d’essayer la migration avec un petit groupe d’utilisateurs avant le passage en production. Les étapes de configuration sont les suivantes :

Si vous souhaitez un domaine personnalisé, configurez-le et vérifiez-le sur le locataire avant de configurer les applications et les fournisseurs d’identité externes. Utilisez les URL FoxIDs obtenues tout au long de la migration. Une modification ultérieure du domaine nécessite de mettre à jour les configurations externes, notamment les URL d’autorité ou de métadonnées des applications ainsi que les URL de rappel et de déconnexion des fournisseurs.
Chaque environnement possède une méthode d’authentification Login par défaut nommée login. Personnalisez son identité visuelle et son interface de connexion pour obtenir l’apparence souhaitée et ajustez ses options de connexion aux utilisateurs importés.
Créez les méthodes d’authentification qui relient les utilisateurs à leurs fournisseurs d’identité externes, y compris Okta s’il reste présent pendant la transition.
Configurez l’application, ses URL de redirection autorisées, son comportement de déconnexion et les API qui acceptent ses jetons d’accès.

FoxIDs Cloud assure l’envoi d’e-mails et de SMS pour la création de mots de passe, la connexion sans mot de passe et l’authentification multifacteur (MFA), selon l’offre FoxIDs Cloud choisie.

Configurez les paramètres MFA requis et les modalités d’inscription. Les imports CSV décrits ici transfèrent les données utilisateur, pas les inscriptions Okta Verify, les inscriptions d’appareils FastPass, les clés d’accès ni les autres inscriptions MFA. Les utilisateurs qui s’authentifient localement dans FoxIDs enregistrent les facteurs configurés. Ceux qui continuent à s’authentifier via Okta peuvent conserver leurs inscriptions Okta.

La configuration des applications constitue un chantier distinct de l’import des utilisateurs. Examinez l’émetteur, l’audience, les portées, les revendications et la validation des jetons, ainsi que les dépendances au SDK Okta ou au Sign-In Widget, les inline hooks, les règles de groupes et les attributions d’applications. Recréez le comportement nécessaire à l’application. Le guide général de migration couvre l’inventaire global des applications et les étapes de déploiement.

Exporter un groupe défini d’utilisateurs Okta

Utilisez l’API Users d’Okta pour récupérer les données utilisateur en JSON en vue de leur conversion. Sélectionnez l’organisation source et les utilisateurs ou groupes à migrer. Suivez l’URL rel="next" de l’en-tête de réponse Link jusqu’à avoir lu toutes les pages. L’opération de liste ordinaire omet les utilisateurs DEPROVISIONED ; un filtre ou une recherche peut les inclure. Les résultats de recherche présentent une cohérence à terme : les changements récents peuvent donc apparaître avec un délai.

Conservez l’organisation source et l’id utilisateur, le status du cycle de vie, les attributs profile requis et les informations credentials.provider. Gardez distincts les utilisateurs gérés par Okta, issus d’un annuaire et fédérés. La configuration des fournisseurs d’identité et les règles de routage aident à déterminer où les utilisateurs s’authentifient réellement.

Pour un export à partir d’un rapport, le rapport User Accounts propose l’option CSV Export. Ses colonnes doivent toujours être converties au format FoxIDs Seed Tool. L’API est utile lorsque l’import nécessite aussi des attributs personnalisés ou des informations de fournisseur absents du rapport.

Exportez séparément les appartenances aux groupes et les accès aux applications lorsqu’ils déterminent les autorisations. Les rapports Okta Group Membership et User App Access décrivent ces relations ; elles ne figurent pas toutes dans l’objet profile de l’utilisateur.

Disponibilité des mots de passe

Okta propose uniquement l’export de hachages de mots de passe pour une migration vers Auth0, sous réserve de critères spécifiques.

FoxIDs peut importer les hachages de mots de passe pris en charge lorsqu’ils sont disponibles.

Mapper les données utilisateur et préserver les comptes applicatifs

FoxIDs crée son propre identifiant utilisateur persistant pour les utilisateurs locaux importés. Importer l’id utilisateur Okta comme revendication personnalisée n’en fait pas l’identifiant FoxIDs et ne préserve pas automatiquement le sujet de l’application. Enregistrez le véritable sub OpenID Connect ou NameID SAML utilisé par chaque application avec l’organisation source et l’identifiant utilisateur.

Si l’application utilise l’identifiant utilisateur Okta comme sub, importez-le dans une revendication personnalisée telle que legacy_okta_user_id. Sur la méthode d’authentification Login, configurez une transformation de revendications Map avec l’action Replace claim, la revendication d’entrée legacy_okta_user_id et la revendication de sortie sub. L’application reçoit cette valeur comme sub, tandis que l’identifiant FoxIDs persistant reste inchangé. Si l’application utilise une autre valeur de sujet, préservez et mappez cette valeur.

Les applications qui identifient les comptes par l’émetteur et le sujet doivent aussi associer le nouvel émetteur FoxIDs aux comptes existants. Pour les applications SAML, configurez le NameID et le format requis sur l’enregistrement d’application SAML. Une connexion de test montre l’identité réellement reçue par l’application.

Maintenez une correspondance entre l’identité source, la nouvelle identité FoxIDs et le compte applicatif existant. Les identités utilisées pendant la transition doivent désigner le même dossier client ou employé. Pour les connexions sociales et d’entreprise, incluez l’identité reçue directement du fournisseur ; elle peut différer de l’identifiant utilisateur Okta.

Pour l’import des utilisateurs locaux, utilisez la correspondance suivante :

Information source	Destination et décision
`profile.email`	`Email`. Recherchez les doublons après suppression des espaces périphériques et conversion en minuscules, y compris les collisions avec les utilisateurs FoxIDs existants.
`profile.login`	`Username` si la connexion par nom d’utilisateur est requise. Un nom de connexion Okta peut différer de l’adresse e-mail de l’utilisateur.
`profile.mobilePhone`	`Phone` lorsque le numéro choisi sera utilisé pour la connexion par SMS. Utilisez le format international avec l’indicatif pays.
Éléments attestant la vérification de l’e-mail et du téléphone	`EmailVerified` et `PhoneVerified`. La présence d’une coordonnée dans le profil ne prouve pas sa vérification ; utilisez `false` lorsque l’état est inconnu.
`status`	`DisableAccount`. Laissez les utilisateurs suspendus désactivés ; omettez les utilisateurs déprovisionnés ou importez-les désactivés si leurs enregistrements sont nécessaires.
`id` utilisateur et organisation source	Conservez-les dans la correspondance de migration. Les exemples conservent aussi l’identifiant dans `legacy_okta_user_id`.
`profile.firstName`, `profile.lastName` et attributs personnalisés requis	Mappez vers les revendications utilisées par vos applications.
Appartenances aux groupes et attributions d’applications	Recréez les rôles et attributions d’accès requis dans FoxIDs ou l’application.

Les états du cycle de vie Okta sont plus détaillés que l’indicateur de désactivation de FoxIDs. Les exemples activent des utilisateurs sélectionnés parmi les comptes ACTIVE et laissent les comptes suspendus désactivés. Les états comme STAGED, PROVISIONED, RECOVERY, PASSWORD_EXPIRED et LOCKED_OUT nécessitent une correspondance explicite avec le comportement prévu d’activation, de création du mot de passe ou d’accès.

Créez une méthode d’authentification FoxIDs pour chaque fournisseur d’identité social ou d’entreprise actuellement connecté via Okta, avec une relation de confiance directe envers ce fournisseur. Les utilisateurs conservent leurs comptes et identifiants chez lui.

Identifiez le fournisseur derrière chaque connexion. Utilisez le guide d’intégration du fournisseur approprié, par exemple Google ou Microsoft Entra ID, et sélectionnez la méthode d’authentification OpenID Connect, SAML 2.0 ou WS-Federation prise en charge.
Enregistrez ou configurez FoxIDs chez le fournisseur. Échangez les paramètres client ou les métadonnées de fédération et configurez les URL de rappel et de déconnexion indiquées dans le guide d’intégration. Conservez la connexion Okta pendant la transition.
Autorisez la nouvelle méthode d’authentification sur l’application FoxIDs. Configurez Home Realm Discovery pour que les utilisateurs puissent sélectionner leur fournisseur ou y être dirigés par les règles configurées.
Mappez l’identité du fournisseur vers le compte applicatif existant. Si vous devez stocker dans FoxIDs des revendications ou des attributions d’accès par utilisateur, configurez et provisionnez des utilisateurs externes.
Recréez les restrictions d’accès auparavant appliquées par Okta, notamment les attributions d’applications, les utilisateurs suspendus et la MFA requise.

Le flux attendu est application → FoxIDs → fournisseur d’identité externe → FoxIDs → application. FoxIDs émet les jetons de l’application après l’authentification de l’utilisateur par le fournisseur.

Vous pouvez essayer chaque connexion en démarrant la connexion depuis l’application, en sélectionnant le fournisseur et en terminant son parcours de connexion. Vous pouvez ainsi observer la MFA, le compte et les autorisations dans l’application, ainsi que la déconnexion.

Migrer les utilisateurs depuis Active Directory

Si Okta délègue l’authentification par mot de passe à Active Directory et qu’AD reste la source, FoxIDs peut se connecter directement via Directory Connector pour Active Directory. Configurez le connecteur et la méthode d’authentification Login comme décrit dans ce guide. FoxIDs synchronise les utilisateurs depuis AD et valide les mots de passe auprès d’AD ; ces utilisateurs n’ont donc pas besoin d’un import CSV de mots de passe.

Par défaut, FoxIDs conserve une copie locale du mot de passe après une validation réussie par Directory Connector. Cela permet de passer ultérieurement à l’authentification locale FoxIDs en désactivant le connecteur. Les utilisateurs dont le mot de passe n’a pas été recueilli peuvent utiliser la création du mot de passe. Consultez le comportement des mots de passe de Directory Connector pour les options de configuration.

Un utilisateur Okta provenant d’AD ne s’authentifie pas nécessairement encore auprès d’AD : Okta peut migrer l’authentification par mot de passe d’AD vers Okta. La connexion directe s’applique lorsque AD détient et valide toujours le mot de passe utilisé.

Migrer les utilisateurs sans mot de passe

Importez les utilisateurs comme utilisateurs internes FoxIDs sans mot de passe et configurez la connexion sans mot de passe avec un code par e-mail ou SMS. L’utilisateur saisit le code sur la page de connexion déjà ouverte.

Il s’agit d’un changement de méthode d’authentification pour les utilisateurs d’Okta FastPass ou de passkeys. Les codes par e-mail et SMS n’offrent pas la même résistance au phishing que FastPass.

Activez l’e-mail ou le téléphone comme identifiant de connexion sur la méthode d’authentification FoxIDs Login, et activez Passwordless with email (one-time password) ou Passwordless with SMS (one-time password) selon le cas.
Pour une méthode de connexion dédiée aux utilisateurs sans mot de passe, sélectionnez Disable password authentication et désactivez la création/réinitialisation du mot de passe par e-mail et SMS.
Importez les utilisateurs en omettant Password et tous les champs de hachage. Laissez SetPasswordEmail, SetPasswordSms et ChangePassword à false. Préservez l’état de vérification mappé, l’état de désactivation et les revendications requises.

Par exemple, ce CSV du Seed Tool importe un utilisateur fictif sans mot de passe par e-mail dont l’état antérieur de vérification de l’e-mail est inconnu :

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

Pour les utilisateurs SMS, remplacez Email et EmailVerified par Phone et PhoneVerified, avec le numéro choisi et son état de vérification connu. La même procédure de chargement s’applique.

Vous pouvez essayer le flux avec un utilisateur de test importé en saisissant son adresse e-mail ou son numéro de téléphone et le code reçu. Un code valide permet à un utilisateur activé de poursuivre vers l’application après la MFA requise. L’utilisateur reste sans mot de passe après une connexion sans mot de passe réussie.

Importer les utilisateurs pour la création du mot de passe

Activez la connexion par e-mail, l’authentification par mot de passe et la création du mot de passe par e-mail sur la méthode d’authentification FoxIDs Login. Les utilisateurs importés choisissent un mot de passe lors de leur première connexion.

Migration avec création du mot de passe : exporter et examiner les données des utilisateurs Okta, importer les utilisateurs sans mot de passe, puis se connecter et définir un mot de passe avec un code reçu par e-mail.

L’import des utilisateurs prépare les comptes. La création du mot de passe intervient lorsque chaque utilisateur démarre une connexion, pas pendant l’import.

Convertissez les enregistrements vérifiés en fichier UTF-8 pour le FoxIDs Seed Tool. Les en-têtes sont sensibles à la casse et le séparateur est un point-virgule. Cet exemple contient des utilisateurs fictifs dont l’état antérieur de vérification de l’e-mail est inconnu ; le second compte reste désactivé :

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 sélectionne la création du mot de passe avec confirmation par e-mail. Omettez Password et toutes les colonnes de hachage. RequireMultiFactor=true est la politique choisie dans l’exemple et nécessite de configurer les méthodes MFA correspondantes.

Ne transmettez la revendication d’exemple legacy_okta_user_id qu’aux applications qui en ont besoin, via leur traitement configuré des revendications.

Charger les utilisateurs et examiner le résultat

Utilisez cette procédure pour les utilisateurs sans mot de passe et ceux qui choisiront un mot de passe à la première connexion, avec les champs adaptés à la méthode choisie.

Le Seed Tool sépare les champs par des points-virgules ; les champs entre guillemets ne peuvent pas contenir de points-virgules ou de sauts de ligne. Utilisez les opérations utilisateur de la Control API si vos valeurs nécessitent une représentation d’import plus riche.

Téléchargez et configurez le Seed Tool pour l’environnement prévu. Définissez SeedSettings.UsersSvcPath sur le fichier CSV converti.
Exécutez le Seed Tool et sélectionnez U pour charger les utilisateurs en masse.
Enregistrez les nouveaux identifiants utilisateur dans votre correspondance de migration.

Vous pouvez essayer le chargement avec un CSV de quelques utilisateurs dans un environnement de test. Le Seed Tool indique le nombre de réussites et d’échecs. Vous pouvez examiner les utilisateurs importés dans FoxIDs Control pour consulter leurs identifiants, leur état de désactivation, leurs revendications et leurs indicateurs de création de mot de passe.

Le Seed Tool utilise le provisionnement en masse, qui peut remplacer les utilisateurs existants au lieu de les fusionner. Un chargement répété peut supprimer les identifiants et l’état et créer de nouveaux identifiants utilisateur. Pour un import partiel, rapprochez le résultat avant de réessayer ; utilisez des mises à jour utilisateur ciblées pour les modifications ultérieures.

Pour un utilisateur importé activé avec SetPasswordEmail=true, le flux attendu est le suivant :

L’utilisateur ouvre l’application et démarre une connexion via FoxIDs Login.
FoxIDs identifie l’utilisateur par son adresse e-mail et envoie un code de confirmation.
L’utilisateur soumet le code et un nouveau mot de passe conforme à la politique de FoxIDs.
FoxIDs vérifie l’adresse e-mail, enregistre le mot de passe et efface les indicateurs de création du mot de passe. La connexion passe par les étapes MFA requises avant le retour à l’application.

L’import d’un utilisateur n’envoie pas l’e-mail de création du mot de passe. Les connexions suivantes utilisent le nouveau mot de passe FoxIDs. Si un utilisateur ne peut pas recevoir le code, le processus de récupération doit vérifier son identité autrement.

Vous pouvez explorer le flux avec un utilisateur de test en suivant les étapes de connexion ci-dessus. Ces scénarios présentent les résultats attendus :

Scénario	Résultat attendu
Première connexion et connexions suivantes	L’e-mail arrive ; la création réussit avec un code valide et un mot de passe conforme à la politique ; elle n’est pas répétée à la connexion suivante.
Code invalide ou expiré	La création du mot de passe échoue sans donner accès à l’application.
Compte désactivé	Ni la création du mot de passe ni la connexion n’active le compte.
Compte et autorisations	L’utilisateur retrouve le même compte applicatif et les mêmes données avec l’accès prévu.
MFA, accès API et déconnexion	La MFA requise est appliquée ; les API acceptent les jetons prévus et rejettent les jetons invalides ; la déconnexion suit le flux configuré.

Conserver Okta pendant la transition

FoxIDs peut faire confiance à Okta comme fournisseur d’identité externe pendant le transfert des applications vers FoxIDs. Les utilisateurs s’authentifient chez Okta et FoxIDs émet les jetons pour l’application. Les mots de passe et authentificateurs Okta restent ainsi chez Okta ; ils ne sont pas copiés dans FoxIDs.

Pour une connexion OpenID Connect :

Créez dans Okta une intégration d’application web OIDC pour FoxIDs utilisant Authorization Code Flow. Affectez les utilisateurs ou groupes qui se connecteront par cette intégration et configurez sa politique de connexion.
Créez une méthode d’authentification OpenID Connect dans FoxIDs. Définissez Authority sur l’émetteur Okta choisi et configurez l’identifiant client Okta dans Optional custom SP client ID, son secret client et la méthode d’authentification client correspondante pour le point de terminaison de jetons.
Demandez les portées profile et email selon les besoins ; FoxIDs inclut openid. Sélectionnez Read claims from the UserInfo Endpoint instead of the access token or ID token dans Show advanced pour obtenir les revendications utilisateur via UserInfo.
Enregistrez la Redirect URL affichée par FoxIDs comme URI de redirection de connexion dans Okta et configurez l’URI de redirection de déconnexion correspondante si la déconnexion est utilisée.
Autorisez la méthode d’authentification sur l’application FoxIDs et configurez Home Realm Discovery pour les utilisateurs qui continuent via Okta.

Le serveur d’autorisation d’organisation d’Okta prend en charge la connexion OpenID Connect avec un émetteur tel que https://example.okta.com. Un serveur d’autorisation personnalisé utilise un émetteur tel que https://example.okta.com/oauth2/default. Utilisez l’émetteur et la configuration de revendications choisis pour l’intégration.

Une méthode d’authentification SAML constitue une autre option : créez une application SAML dans Okta pour FoxIDs et échangez les métadonnées et paramètres des fournisseurs de services et d’identité.

Une connexion de test via l’application montre la politique d’authentification Okta, les revendications, la correspondance des comptes et la déconnexion pour la nouvelle connexion. À mesure que les utilisateurs passent à la connexion locale FoxIDs ou à des fournisseurs directement connectés, dirigez-les vers ces méthodes. Une correspondance des comptes cohérente entre les méthodes permet à l’application de continuer à utiliser les mêmes comptes.

Déployer et conserver une possibilité de retour arrière

La migration peut être déployée par application ou groupe d’utilisateurs. Les utilisateurs peuvent continuer via leur URL d’application habituelle avec le flux configuré : création du mot de passe, code à usage unique, mot de passe d’annuaire ou fournisseur d’identité externe.

Rapprochez les utilisateurs créés, modifiés, suspendus ou supprimés depuis l’export, y compris les changements de groupes et d’attributions d’applications. Un bref gel des modifications ou un rapprochement contrôlé peut maintenir la cohérence entre source et destination pendant le basculement. Les mises à jour ultérieures doivent préserver les identifiants et l’état déjà établis dans FoxIDs.

Surveillez la livraison des e-mails et SMS, les échecs de création du mot de passe, les échecs de connexion et les problèmes de correspondance des comptes. Le retour arrière dépend de la disponibilité de l’ancienne configuration Okta. Vous pouvez essayer de la restaurer pour une application de test afin d’observer le retour au flux de connexion Okta.

Un mot de passe défini localement dans FoxIDs n’est pas resynchronisé vers Okta. Un retour arrière utilise donc les identifiants encore détenus par Okta ou son fournisseur connecté. Les utilisateurs créés uniquement dans FoxIDs ont besoin d’une voie d’accès si un retour arrière est nécessaire. Lorsque les utilisateurs et applications concernés utilisent leurs méthodes d’authentification de destination, l’intégration Okta peut être retirée.