Migration

La migration vers les FoxIDs combine normalement la migration des applications, la migration des utilisateurs et une transition contrôlée entre la plateforme d'identité existante et les FoxIDs. Planifiez ces flux de travail ensemble afin que les identifiants, les revendications, le comportement d'authentification et les options de restauration restent cohérents tout au long de la transition.

Les locataires FoxIDs prennent en charge des environnements distincts. Utilisez des environnements dédiés de développement, de test, de préparation et de production pour configurer et valider les flux de migration en parallèle sans modifier prématurément l’environnement de production.

Évaluer la plateforme d'identité existante

Commencez par enregistrer :

Applications, API et environnements connectés à la plateforme existante.
Configurations OpenID Connect, OAuth 2.0, SAML 2.0 et WS-Federation.
Fournisseurs d'identité, méthodes d'authentification et exigences d'authentification multifacteur.
Identifiants d'utilisateur, profils, revendications, groupes, rôles et attributions d'accès.
Options de stockage, de validation et de réinitialisation des mots de passe disponibles dans la plateforme source.
Certificats, métadonnées, URL de redirection, comportement de déconnexion et durée de vie des jetons.
Exigences de surveillance, d’audit et de restauration pour le basculement.

La source peut être AD FS, Active Directory, Keycloak, Auth0, Okta, Microsoft Entra ID ou un autre fournisseur d'identité ou référentiel d'utilisateurs personnalisé. Le chemin de migration disponible dépend des protocoles, des capacités d'exportation et des options de validation de mot de passe fournis par cette source.

Migration d'applications

Migrez les applications par protocole et environnement plutôt que de traiter le domaine comme un simple basculement.

Enregistrez l'application dans un environnement FoxIDs hors production.
Reproduisez les revendications, les portées, les identifiants, les certificats et le comportement de déconnexion requis.
Connectez le fournisseur d'identité existant comme méthode d'authentification lorsqu'une authentification parallèle est requise.
Testez le flux complet de connexion, de jeton et de déconnexion avec des utilisateurs et des intégrations représentatifs.
Déplacez un groupe contrôlé ou une application à la fois avant un déploiement plus large.

FoxIDs pontage de protocole permet à une application de conserver son protocole actuel pendant que le côté du fournisseur d'identité change. Ceci est utile lorsque les applications OpenID Connect modernes et les applications SAML 2.0 ou WS-Federation existantes doivent fonctionner pendant la même période de migration.

Profils d'utilisateurs et identifiants

Décidez quel identifiant reste stable avant d’importer ou de créer des utilisateurs. Les adresses e-mail, les numéros de téléphone et les noms d'utilisateur peuvent changer, utilisez donc un identifiant source stable lorsque l'intégration en prend un en charge.

Mappez les informations utilisateur requises après la migration :

Propriétés du profil utilisateur et identifiants de connexion.
Revendications utilisées par les applications et les API.
Groupes, rôles et attributions d'accès.
Exigences d’authentification multifacteur et approche d’inscription ou de récupération après la migration.
Comptes désactivés, supprimés ou autrement restreints.

Utilisez Téléchargez de nombreux utilisateurs lorsque les utilisateurs peuvent être exportés et importés par lots. Utilisez Directory Connector lorsqu'un répertoire existant ou un référentiel personnalisé doit rester faisant autorité pendant la transition. Pour Active Directory, utilisez Directory Connector for Active Directory.

Stratégie de mot de passe

Choisissez le chemin du mot de passe en fonction de ce que la plateforme source peut exposer ou valider en toute sécurité :

Importez des mots de passe ou des hachages de mots de passe pris en charge uniquement lorsqu'ils sont disponibles sous une forme compatible et peuvent être traités en toute sécurité.
Validez le mot de passe existant via Directory Connector pendant que le répertoire source reste faisant autorité.
Par défaut, FoxIDs enregistre une copie du mot de passe local après une validation réussie du connecteur d'annuaire. Cela permet de désactiver le connecteur ultérieurement et de déplacer la validation du mot de passe vers FoxIDs sans forcer chaque utilisateur à effectuer une réinitialisation.
Désactivez la copie locale du mot de passe lorsque la stratégie exige que le répertoire externe reste le seul magasin de mots de passe.
Exiger la réinitialisation du mot de passe lorsque l’importation ou la conservation du mot de passe existant n’est pas techniquement possible ou lorsque la réinitialisation est l’option la plus sûre.

Ne présumez jamais que les mots de passe peuvent être déplacés directement à partir d’un fournisseur d’identité. Confirmez le format d'exportation de la plateforme source, l'algorithme de hachage, l'API de validation et les contraintes de sécurité avant de sélectionner la méthode de migration.

Migration progressive

Lorsque l'annuaire source prend en charge la validation en ligne, les utilisateurs peuvent être créés ou mis à jour dans FoxIDs lors de leur première connexion réussie via Directory Connector. Cela prend en charge une transition progressive sans obliger tous les utilisateurs à migrer en même temps.

Gardez la source disponible jusqu'à ce que la population d'utilisateurs requise ait migré et que la fenêtre de restauration se soit fermée. Surveillez les échecs de connexion, les conflits d’identifiants, les revendications manquantes et la disponibilité des connecteurs tout au long de la transition.

Basculement et restauration

Avant la reprise de la production :

Effectuer les tests d’application représentative et d’acceptation des utilisateurs.
Confirmez les certificats, les métadonnées, le DNS, les URL de redirection et les chemins de pare-feu.
Définissez l'ordre dans lequel les applications, les API et les groupes d'utilisateurs se déplacent.
Enregistrez la configuration précédente et les conditions qui déclenchent la restauration.
Assurez-vous que la surveillance et la journalisation couvrent à la fois les FoxIDs et les flux restants de la plate-forme source.
Communiquez la réinitialisation du mot de passe ou la modification du comportement de connexion avant que cela n’affecte les utilisateurs.

Un déploiement par étapes limite le nombre d'applications et d'utilisateurs concernés par chaque changement. Gardez la restauration techniquement possible jusqu'à ce que le comportement de production, les revendications et l'accès aient été vérifiés.