Une migration de mots de passe n’est pas une copie de base de données. Lorsque des utilisateurs passent d’un identity provider à un autre, la source ne peut souvent pas fournir un mot de passe réutilisable par la cible. Même si un export contient des hachages de mots de passe, un hachage produit pour une plateforme n’est pas automatiquement valide sur une autre.
Les utilisateurs peuvent parfois conserver leur mot de passe existant sans réinitialisation forcée. La méthode sûre dépend de ce que la source peut exporter, de sa capacité à valider les mots de passe en ligne, de la durée pendant laquelle elle peut rester disponible et de la possibilité de lier chaque compte à un identifiant source stable.
Cet article propose un cadre de décision pour choisir entre un import compatible, une validation progressive des mots de passe, une validation externe maintenue et une réinitialisation contrôlée. Il se concentre sur le parcours du mot de passe. Les protocoles d’application, les claims, l’inscription à la multi-factor authentication (MFA) et le plan complet de cut-over doivent toujours être traités comme des chantiers de migration liés.
Commencez par la source, pas par l’expérience utilisateur souhaitée
« Pas de réinitialisation du mot de passe » est un résultat souhaitable, mais pas encore une méthode de migration. Avant de choisir une approche, établissez ce que la source peut réellement prendre en charge :
- Peut-elle exporter des mots de passe en clair ou une représentation de mot de passe explicitement prise en charge par la cible ?
- Peut-elle valider le mot de passe actuel d’un utilisateur via une API de validation protégée ?
- Cette API peut-elle rester disponible, surveillée et prise en charge pendant une migration progressive et la fenêtre de rollback ?
- Existe-t-il un identifiant source stable et immuable qui permette de lier le même compte malgré les changements d’identifiants de connexion ?
- Les modifications et réinitialisations de mots de passe peuvent-elles rester cohérentes tant que deux systèmes sont impliqués ?
- La politique de sécurité, les contrats et l’évaluation des risques autorisent-ils l’importation ou la conservation de données de mot de passe ?
N’utilisez pas l’adresse e-mail, le numéro de téléphone ou le nom d’utilisateur comme unique clé de migration. Ces identifiants peuvent changer. Une association de comptes erronée est plus grave qu’une réinitialisation, car elle peut lier des identifiants d’authentification et des accès à la mauvaise identité.
Choisissez l’un des quatre parcours de mot de passe
Des populations d’utilisateurs différentes peuvent nécessiter des parcours différents. Par exemple, les employés actifs peuvent migrer progressivement par validation en ligne, tandis que les comptes externes inactifs reçoivent une réinitialisation au retour de l’utilisateur.
| Capacité et contrainte de la source | Parcours défendable | Avantage principal | Coût ou risque principal |
|---|---|---|---|
| Des mots de passe ou une représentation compatible avec la cible sont disponibles et peuvent être traités en toute sécurité | Import par lots contrôlé | Les utilisateurs peuvent s’authentifier immédiatement auprès de la cible | L’export, le transport et le traitement des données de mot de passe élargissent la frontière de sécurité |
| La source peut valider les mots de passe existants en ligne et rester autoritative pendant la transition | Migration progressive avec Directory Connector | Les utilisateurs actifs migrent après une connexion réussie sans réinitialisation générale | La source et le connecteur restent dans le parcours d’authentication en production jusqu’au cut-over |
| Les utilisateurs sont déjà provisionnés dans FoxIDs et seuls la validation des mots de passe, le contrôle de politique ou la notification de changement restent externes | External Password API | Conserve une intégration plus étroite avec le stockage de mots de passe ou la politique | Ne fournit pas le même flux de création d’utilisateurs et de synchronisation de profils que Directory Connector |
| Aucun import compatible sécurisé ni aucune validation en ligne fiable n’est disponible | Réinitialisation vérifiée du mot de passe | Établit un nouveau mot de passe cible avec une frontière de trust claire | La communication utilisateur, les canaux de récupération et la capacité du support deviennent essentiels |
La réponse n’est donc pas toujours « conserver » ni toujours « réinitialiser ». Pour chaque population, choisissez le parcours le moins perturbateur qui reste défendable techniquement et opérationnellement.
Migration progressive avec Directory Connector
Directory Connector est le principal modèle FoxIDs lorsqu’un annuaire existant ou un repository personnalisé doit rester autoritatif pendant la transition.
Lorsqu’un utilisateur se connecte avec un mot de passe, FoxIDs appelle l’API du connecteur. Après une validation réussie, FoxIDs crée ou met à jour l’utilisateur interne à partir des identifiants, propriétés et claims retournés. La réponse contient un directoryUserId stable qui lie l’utilisateur dans FoxIDs au compte source, même si son adresse e-mail, son numéro de téléphone ou son nom d’utilisateur change ultérieurement.
Cela crée un parcours just-in-time concret :
- L’utilisateur se connecte à une application via FoxIDs avec son identifiant et son mot de passe existants.
- FoxIDs demande à l’annuaire source de valider le mot de passe.
- Le connecteur retourne l’identifiant source stable et les données utilisateur approuvées.
- FoxIDs crée ou met à jour l’utilisateur interne et termine l’authentication.
- L’utilisateur peut continuer à utiliser son mot de passe existant tant que la source reste autoritative.
Par défaut, FoxIDs enregistre également une copie locale du mot de passe après une validation réussie du connecteur ou une opération du cycle de vie du mot de passe via celui-ci. Cette copie permet un basculement ultérieur planifié vers la validation des mots de passe dans FoxIDs sans réinitialiser le mot de passe de chaque utilisateur ayant terminé le parcours progressif.
La frontière est importante : tant que Directory Connector est activé, l’annuaire externe reste autoritatif. FoxIDs n’utilise pas le hachage local enregistré comme fallback automatique si le connecteur est indisponible. Une panne du connecteur est donc une défaillance du parcours d’authentication, pas une instruction pour contourner la source.
Le commutateur de politique de mot de passe affiché ci-dessous constitue une troisième décision indépendante. Il détermine si FoxIDs vérifie un mot de passe proposé par rapport à la politique de l’environnement FoxIDs avant d’appeler le connecteur. L’annuaire externe reste responsable du mot de passe et peut le refuser selon sa propre politique. Si les deux contrôles sont utilisés, leurs exigences et les indications données aux utilisateurs doivent être alignées.
Définissez les critères de sortie avant d’activer le connecteur
Une migration progressive nécessite une condition de fin. Avant le déploiement, déterminez :
- Quelles populations d’utilisateurs doivent avoir réussi une connexion avant le cut-over ?
- Comment les comptes inactifs ou les comptes d’utilisateurs qui ne reviennent jamais seront-ils traités ?
- Combien de temps la source et le connecteur doivent-ils rester disponibles pour un rollback ?
- Quels temps de réponse et taux d’erreur du connecteur doivent arrêter ou inverser le déploiement ?
- Comment les conflits d’identifiants, les claims manquants et les comptes sources désactivés ou supprimés seront-ils examinés ?
- Quand le connecteur peut-il être désactivé et FoxIDs devenir autoritatif pour les mots de passe ?
L’enregistrement d’une copie locale est facultatif. Désactivez-le lorsqu’une politique exige que la source reste l’unique stockage de mots de passe, mais sachez que cela supprime le chemin vers un basculement ultérieur sans réinitialisation.
Quand External Password API est la solution la plus ciblée
FoxIDs peut configurer un External Password API comme contrôle de mot de passe pour les utilisateurs internes. Il peut valider un mot de passe actuel, vérifier un nouveau mot de passe par rapport à une politique externe, notifier un autre système des modifications de mot de passe ou combiner ces responsabilités.
Utilisez cette option lorsque les utilisateurs existent déjà dans FoxIDs et que le besoin restant concerne spécifiquement le stockage ou la politique de mot de passe. Ne la considérez pas comme un substitut à Directory Connector lorsque la migration nécessite également la création d’utilisateurs just-in-time, une liaison stable avec un annuaire externe, des mises à jour de profil ou la gestion du cycle de vie des comptes externes.
Cette distinction rend la frontière d’intégration explicite : Directory Connector représente un annuaire externe autoritatif. External Password API représente une dépendance externe pour la validation, la politique ou la notification des mots de passe des utilisateurs internes.
Quand l’import par lots est justifié
L’import par lots peut supprimer la dépendance d’exécution à la source, mais uniquement lorsque les données d’entrée conviennent à la cible et peuvent être protégées pendant tout le transfert.
FoxIDs permet de charger des utilisateurs internes avec des mots de passe connus, avec des hachages précalculés compatibles avec FoxIDs ou sans mot de passe. Un hachage provenant d’une plateforme source quelconque ne peut pas simplement être qualifié de hachage FoxIDs. Confirmez l’algorithme exact, le salt et le format cible avant de conclure qu’un hachage exporté est réutilisable.
Traitez l’export de mots de passe en clair comme une décision de sécurité, pas comme une facilité. Limitez l’accès, utilisez un chemin de transfert contrôlé, empêchez les mots de passe d’entrer dans les logs ou les fichiers de projet ordinaires, vérifiez la suppression des données temporaires et documentez la personne ayant approuvé l’opération. Si ce traitement n’est pas défendable, choisissez plutôt la validation en ligne ou la réinitialisation.
Quand la réinitialisation du mot de passe est plus sûre
Une réinitialisation ne prouve pas nécessairement que la migration a échoué. C’est le parcours honnête lorsque la conservation du mot de passe existant affaiblirait la cible ou dépendrait d’hypothèses que l’équipe ne peut pas vérifier.
Préférez une réinitialisation contrôlée lorsque :
- la source ne peut ni exporter une représentation compatible ni valider le mot de passe actuel en ligne ;
- le transfert de données de mot de passe créerait une exposition inacceptable ou un problème contractuel ;
- le mot de passe dans la source est compromis ou suspecté de l’être ;
- les comptes ne peuvent pas être corrélés à des identités sources stables avec une confiance suffisante ;
- la source ne peut pas rester fiable pendant la période nécessaire de migration progressive et de rollback ; ou
- la conservation de l’ancien mot de passe nécessiterait des contrôles plus faibles dans la cible.
Les utilisateurs FoxIDs peuvent être chargés sans mot de passe et invités à en définir un à l’aide d’un code de vérification envoyé par e-mail ou SMS. Cette méthode n’est sûre que si l’identifiant de récupération appartient à l’utilisateur concerné et si le canal de distribution répond aux exigences de risque de l’organisation. Testez les codes expirés, les boîtes de réception ou numéros de téléphone inaccessibles, les identifiants en double, les comptes verrouillés et l’escalade vers le support avant un déploiement large.
Communiquez la raison et le calendrier avant que les utilisateurs ne rencontrent la réinitialisation. Séparez la décision de sécurité du plan de support : une conception solide peut toujours échouer opérationnellement si les canaux de récupération sont obsolètes ou si le centre de services ne peut pas absorber la charge initiale.
Exigez des preuves avant le cut-over des mots de passe
Testez le parcours choisi dans un environnement FoxIDs distinct et commencez par une population contrôlée. Une connexion réussie est nécessaire, mais pas suffisante.
| Domaine de décision | Preuve requise avant un déploiement plus large |
|---|---|
| Liaison d’identité | Identifiants sources stables, changements d’identifiants testés et traitement défini des doublons ou utilisateurs manquants |
| Comportement des mots de passe | Mots de passe acceptés et refusés, parcours de mot de passe expiré, modification/réinitialisation et erreurs de politique |
| Disponibilité | Surveillance du connecteur ou de l’API de validation, timeouts, gestion des erreurs et responsable opérationnel nommé |
| Migration des utilisateurs | Résultats pilotes pour des comptes représentatifs actifs, inactifs, désactivés et restreints |
| Sécurité | Traitement approuvé des données de mot de passe, secrets protégés, journalisation de diagnostic sans mots de passe et conservation des données revue |
| Cut-over | Critères de sortie par population, traitement des utilisateurs sans mot de passe cible enregistré, déclencheur de rollback et responsable du retrait de la source |
Conservez la source jusqu’à ce que la population requise ait migré et que la fenêtre de rollback soit fermée. Ne désactivez pas le connecteur uniquement parce que le pilote a réussi. Vérifiez le parcours de mot de passe cible pour la population qui doit fonctionner après le cut-over et conservez un parcours de réinitialisation contrôlé pour les autres utilisateurs.
Comment FoxIDs accompagne la décision
Utilisez la documentation sur la migration pour planifier ensemble applications, utilisateurs, mots de passe, cut-over et rollback. La documentation sur Directory Connector, External Password API et le chargement d’utilisateurs contient les détails exacts de mise en œuvre.
Si les capacités de la source, les populations d’utilisateurs ou les critères de cut-over ne sont pas encore clairs, FoxIDs Identity Migration décrit comment l’équipe derrière la plateforme peut aider à concevoir et réaliser la migration.
Conclusion
Les utilisateurs ne peuvent conserver un mot de passe existant que si la migration maintient un parcours de validation fiable ou établit de manière sûre un mot de passe cible compatible. Directory Connector offre souvent le parcours progressif le moins perturbant, mais maintient également la source dans le flux d’authentication en production jusqu’à un cut-over délibéré.
Choisissez la réinitialisation lorsque la compatibilité, la liaison d’identité ou le traitement sécurisé ne peuvent pas être démontrés. La bonne stratégie rend explicites la source autoritative, le comportement en cas d’échec, l’impact utilisateur et les critères de sortie avant le déplacement du trafic de production.