Remplacer AD FS et changer le protocole d’authentification d’une application sont deux décisions distinctes. Une application qui utilise déjà WS-Federation peut éventuellement conserver ce protocole tout en adoptant FoxIDs comme identity provider de confiance.
Le premier jalon utile est une application qui reconnaît les mêmes utilisateurs, accorde les accès prévus et dispose d’une procédure de retour arrière testée. Une connexion réussie ne démontre, à elle seule, aucun de ces résultats.
Ce guide s’adresse aux architectes IAM et aux architectes de solutions qui préparent cette première migration. Il traite d’une application accessible par navigateur utilisant WS-Federation passif, souvent abrégé en WS-Fed. La fédération de domaines Microsoft 365, l’ouverture de session Windows et les clients WS-Trust actifs nécessitent leur propre évaluation et ne sont pas couverts par cet exemple.
Séparez la migration de l’application de celle de l’annuaire
AD FS est un service de fédération ; Active Directory est l’annuaire auprès duquel de nombreuses installations AD FS authentifient les utilisateurs. Déplacer la relation de confiance fédérée d’une application ne déplace pas, en soi, les comptes de l’annuaire ni les mots de passe.
Un modèle de transition consiste à conserver AD FS comme source d’authentification dans un premier temps :
| Étape | Ce à quoi l’application fait confiance | Où l’utilisateur s’authentifie |
|---|---|---|
| Avant | AD FS émet le token WS-Federation de l’application | AD FS utilise sa configuration d’authentification existante |
| Premier pilote | FoxIDs émet un nouveau token WS-Federation pour l’application | FoxIDs dirige le navigateur vers AD FS au moyen d’une méthode d’authentification configurée |
| Modification ultérieure distincte | L’application continue de faire confiance à FoxIDs | Un autre identity provider externe, ou FoxIDs Login avec Directory Connector pour AD, remplace AD FS après une validation distincte |
FoxIDs prend en charge à la fois un enregistrement d’application WS-Federation côté application et une méthode d’authentification WS-Federation côté AD FS. Les deux côtés ont des rôles différents : l’un émet des tokens, l’autre valide la réponse du fournisseur en amont.
Dans le pilote, AD FS émet un token destiné à FoxIDs. FoxIDs le valide et émet un token distinct destiné à l’application. Il ne s’agit pas d’une simple transmission transparente de l’ancien token : l’application doit faire confiance à l’émetteur et au certificat de signature de FoxIDs.
Le pilote dépend toujours d’AD FS. Il crée un point contrôlé où les exigences de confiance et de claims de l’application peuvent être vérifiées, mais il ne met pas encore le service de fédération hors service.
Deux voies pour aller au-delà d’AD FS
Après le pilote, les deux voies suivantes sont possibles :
- Conserver un identity provider externe. Remplacez AD FS par un autre IdP connecté à FoxIDs via une méthode d’authentification prise en charge. FoxIDs reste l’émetteur WS-Federation de confiance de l’application, qui n’a donc pas à adopter le protocole du nouveau fournisseur.
- Utiliser FoxIDs Login avec Active Directory. Le Directory Connector pour Active Directory valide les mots de passe auprès d’AD. Cela retire AD FS du parcours de connexion de l’application tout en conservant AD comme annuaire faisant autorité. Le guide de modernisation de la connexion avec Active Directory explique cette architecture.
Un passage ultérieur à la validation des mots de passe dans FoxIDs est facultatif. Les connexions réussies via le connecteur créent ou mettent à jour des utilisateurs internes FoxIDs et, lorsque l’enregistrement local des mots de passe est activé, stockent un hachage du mot de passe afin de préparer ces utilisateurs à une bascule ultérieure. Il s’agit d’une migration progressive, pas d’un export de tous les comptes d’AD ; AD reste la source faisant autorité tant que le connecteur est activé.
Quelle que soit la voie choisie, retestez les associations de comptes, les claims, le MFA et la déconnexion. Le pilote de la première application décrit ci-dessous établit ce qui doit être préservé.
Recensez ce que la première application utilise réellement
Choisissez une application ayant un responsable, un environnement de test représentatif et une configuration que vous pouvez restaurer. Vérifiez que son middleware ou son éditeur permet de changer le STS de confiance, abréviation de Security Token Service. Une URL de métadonnées configurable est utile, mais les contrôles d’émetteur personnalisés, le code de recherche des comptes et les règles d’autorisation comptent aussi.
Prenons une application fictive de notes de frais. Le tableau ci-dessous illustre un contrat cible ; ce n’est ni une configuration exportée ni le compte rendu d’une migration achevée.
| Élément du contrat | Comportement existant | Résultat requis pour le pilote |
|---|---|---|
| Realm / audience | urn:example:expenses identifie l’application |
Le wtrealm de l’application correspond à son enregistrement dans FoxIDs et le token est destiné à cette application |
| Reply URL | L’instance de test reçoit les réponses sur https://expenses-test.example.org/signin-wsfed |
Seule l’URL de callback de test prévue est acceptée et utilisée |
| Émetteur et clés de signature de confiance | L’application fait confiance aux métadonnées et aux clés de signature d’AD FS | L’instance de test fait confiance aux métadonnées, à l’émetteur et aux clés de signature de FoxIDs sélectionnés pour ce pilote |
| Format du token | Le middleware accepte SAML 1.1 transporté dans WS-Federation | Conservez ce format, sauf si une modification testée séparément est nécessaire |
| Recherche de l’utilisateur | Le claim NameIdentifier de l’application identifie l’employé E1042 |
Le même compte existant et son historique sont sélectionnés ; aucun second compte n’est créé |
| Autorisation | Le rôle ExpenseApprover permet d’approuver les frais |
Les utilisateurs autorisés conservent cette permission ; les utilisateurs sans ce rôle ne peuvent toujours pas approuver |
| Comportement des sessions | L’application possède un cookie local et une politique de déconnexion définie | La connexion, l’expiration, la nouvelle authentification et la déconnexion respectent la politique convenue via le nouveau parcours |
Utilisez les valeurs et types de claims réels de l’application pour remplir ce tableau. Vérifiez si la recherche de compte inclut aussi l’émetteur du token ou le nom du fournisseur de connexion externe : préserver le seul identifiant utilisateur visible ne suffit pas nécessairement à conserver l’association au compte.
FoxIDs peut émettre des tokens SAML 1.1 ou SAML 2.0 via WS-Federation ; SAML 1.1 est le format par défaut. Un token SAML 2.0 dans une réponse WS-Federation ne constitue pas un passage au protocole SAML 2.0 Web SSO. Séparez les décisions relatives au protocole de celles portant sur le format du token.
Consignez les exigences de chiffrement et les dates d’expiration des certificats avec les paramètres de confiance pour la signature. Le chiffrement et la validation de signature résolvent des problèmes différents, et leur prise en charge doit correspondre à l’application destinataire. Pour ASP.NET Core, le guide Microsoft du middleware WS-Federation cite MetadataAddress, Wtrealm et la configuration du callback parmi les paramètres d’intégration pertinents. Vérifiez votre middleware et sa version avant d’appliquer un exemple de configuration.
Configurez les deux côtés dans un environnement de test
Créez le pilote dans un environnement FoxIDs distinct et utilisez une instance de test de l’application. Configurez la connexion à AD FS comme méthode d’authentification, puis enregistrez l’application existante dans FoxIDs avec son realm, sa reply URL, son type de token et les claims requis.
Côté AD FS, FoxIDs est une relying party à part entière. Établissez cette relation de confiance à l’aide des métadonnées de la méthode d’authentification FoxIDs et définissez les claims ainsi que la politique d’accès qu’AD FS doit lui appliquer. Conservez la relation de confiance AD FS de l’application d’origine pendant la fenêtre de retour arrière convenue.
Ne supposez pas que les règles de claims, les restrictions d’accès ou la politique MFA de la relying party d’origine s’appliquent automatiquement à cette nouvelle relation. Les règles de claims d’AD FS sont associées à chaque relation de confiance, comme l’explique la documentation Microsoft sur les règles de claims. Reproduisez le comportement requis au bon endroit et testez-le.
Configurez ensuite l’instance de test de l’application pour utiliser les métadonnées STS de FoxIDs et l’émetteur attendu. Laissez activée la validation de l’émetteur, de l’audience et de la signature. Utilisez les endpoints générés pour l’environnement réel plutôt que d’adapter manuellement une URL AD FS.
Le pilote passif dans le navigateur n’a pas besoin de l’option distincte Microsoft Entra ID Windows sign-in. Cette fonctionnalité prend en charge un autre scénario de fédération de domaines et de clients actifs.
Suivez les claims jusqu’à l’application
Les métadonnées définissent les endpoints et les informations de confiance, mais pas la manière dont l’application identifie les comptes et accorde les permissions.
Avec une méthode WS-Federation en amont, FoxIDs reçoit des claims SAML, les représente en interne sous forme de claims JWT et les reconvertit en claims SAML pour le token de l’application. Par exemple, le mapping par défaut convertit http://schemas.microsoft.com/ws/2008/06/identity/claims/role en role en interne, puis le reconvertit en type de claim SAML pour WS-Federation. Incluez le type de claim SAML requis pour le rôle dans les listes Forward claims côté méthode d’authentification et Issue claims côté application ; les rôles ne font pas partie de l’ensemble de claims par défaut.
Les identifiants nécessitent une vérification distincte. Pour une méthode d’authentification WS-Federation nommée adfs, FoxIDs préfixe l’identifiant entrant E1042 pour obtenir adfs|E1042 avant les transformations de claims suivantes. Si l’application de notes de frais attend E1042, définissez un mapping explicite qui préserve l’association au compte existant. Ne supprimez pas les préfixes sans distinction : des identifiants identiques provenant de sources différentes pourraient alors sélectionner le même compte.
Comparez un approbateur existant avec un employé qui ne doit pas pouvoir approuver les frais. Examinez les claims réellement utilisés par l’application, y compris tout mapping du middleware, et testez les permissions qui en résultent. Les transformations de claims peuvent modifier les noms et les valeurs : vérifiez donc le résultat final, pas seulement la configuration.
Consultez la documentation sur les transformations et le mapping de claims pour les détails d’implémentation. Transmettez et émettez les claims nécessaires à l’application ; un caractère générique ne remplace pas la décision sur les données qu’elle doit recevoir.
Testez les accès autorisés et refusés avant la bascule
Convenez des résultats attendus avec le responsable de l’application avant les tests. Consignez à la fois les tokens/claims observés et le comportement de l’application, en utilisant des comptes de test et en excluant les données d’authentification des rapports partagés.
| Test | Preuve requise avant de poursuivre |
|---|---|
| Un utilisateur existant se connecte | Le compte existant de l’application, ses données et son historique sont sélectionnés |
| Un approbateur et un employé ordinaire effectuent la même action | L’approbateur réussit ; l’employé ordinaire reçoit un refus |
| La politique d’accès de l’ancienne application exclut un utilisateur | Le nouveau parcours refuse toujours l’accès à cet utilisateur |
| Le MFA est requis, y compris avec une session de navigateur AD FS existante | Le flux configuré satisfait le niveau d’assurance requis ; une connexion réussie en amont ne constitue pas, à elle seule, une preuve suffisante |
| L’utilisateur se déconnecte puis revient sur une page protégée | Le cookie de l’application, la session AD FS et le flux de déconnexion/cleanup configuré respectent la politique de déconnexion convenue |
| Une nouvelle tentative d’authentification nécessite AD FS alors qu’AD FS est indisponible | La tentative échoue sans contourner la source d’authentification requise ; l’échec est visible pour le responsable de l’exploitation |
| Les réponses de test contiennent un émetteur, une audience ou une signature non valide | Chaque réponse non valide est rejetée ; la validation reste activée |
| La configuration précédente de l’application est restaurée | Une nouvelle connexion par le parcours AD FS d’origine sélectionne le bon compte et les bonnes permissions |
Testez l’expiration des sessions et la nouvelle authentification séparément d’une connexion ordinaire réussie. Un compte désactivé ou un utilisateur dont un rôle a été retiré peut encore disposer d’une session d’application existante. Définissez quand l’accès doit cesser et vérifiez ce délai plutôt que de supposer qu’une nouvelle configuration de fédération révoque tous les cookies.
FoxIDs prend en charge la déconnexion WS-Federation et les notifications de cleanup lorsqu’elles sont configurées. La suppression de la session locale par chaque application participante dépend de son implémentation et du parcours réel dans le navigateur. Vérifiez le comportement de déconnexion avec les clients et navigateurs utilisés en production.
Faites de la bascule une décision limitée et réversible
Avant le passage en production, consignez qui peut restaurer la configuration précédente de l’application, où elle est conservée et quels constats déclenchent un retour arrière. Une mauvaise association de compte, des permissions imprévues ou des exigences MFA non satisfaites doivent immédiatement arrêter le déploiement. Fixez des seuils pour les échecs de connexion et les incidents d’exploitation au lieu de les improviser pendant le changement.
Migrez le périmètre applicatif convenu pendant une fenêtre surveillée. Un pilote utilisateur par utilisateur n’est possible que si l’application et la conception du routage le permettent ; sinon, utilisez d’abord l’instance de test et considérez l’application de production comme l’unité de changement.
Le retour arrière doit couvrir davantage que l’URL des métadonnées. Restaurez la confiance précédente dans l’émetteur et les clés, la configuration des claims et toutes les associations de comptes modifiées pendant le pilote. Décidez comment terminer ou remplacer les sessions établies par le nouveau parcours. Restaurer l’ancien endpoint n’annule pas les modifications des données de l’application et ne supprime pas automatiquement ces sessions.
Une fois cette application stabilisée, décidez quelle dépendance supprimer ensuite. Remplacer AD FS en amont, passer le protocole de l’application à OpenID Connect et migrer les utilisateurs de l’annuaire sont des changements ultérieurs distincts, chacun avec ses propres tests. Si le stockage des utilisateurs ou des mots de passe doit changer, utilisez le guide de décision pour la migration des mots de passe plutôt que d’intégrer ces travaux à ce pilote.
Les résultats mesurés de la première application donnent à la migration suivante un point de départ concret : une configuration de confiance comprise, un comportement utilisateur et des accès vérifiés, ainsi qu’une procédure de restauration que l’équipe a mise à l’épreuve. Utilisez le guide de migration pour transformer ces preuves en un plan plus large.