Guide pratique pour migrer à partir du service De contrôle d’accès Azure

Microsoft Azure Access Control Service (ACS), un service d’Azure Active Directory (Azure AD), sera mis hors service le 7 novembre 2018. Les applications et services qui utilisent actuellement le contrôle d’accès doivent être entièrement migrés vers un autre mécanisme d’authentification. Cet article décrit les recommandations pour les clients actuels, alors que vous envisagez d'abandonner votre utilisation du système de contrôle d’accès. Si vous n’utilisez pas actuellement le contrôle d’accès, vous n’avez pas besoin d’effectuer d’action.

Aperçu

Access Control est un service d’authentification cloud qui offre un moyen simple d’authentifier et d’autoriser les utilisateurs à accéder à vos applications et services web. Il permet à de nombreuses fonctionnalités d'authentification et d'autorisation d'être externalisées de votre code. Access Control est principalement utilisé par les développeurs et les architectes des clients Microsoft .NET, des applications web ASP.NET et des services web Windows Communication Foundation (WCF).

Les cas d’usage pour le contrôle d’accès peuvent être divisés en trois catégories principales :

• Authentification auprès de certains services cloud Microsoft, notamment Azure Service Bus et Dynamics CRM. Les applications clientes obtiennent des jetons auprès du contrôle d’accès pour s’authentifier auprès de ces services pour effectuer différentes actions.
• Ajout de l’authentification aux applications web, personnalisées et prépackagenées (comme SharePoint). En utilisant l’authentification « passive » du contrôle d’accès, les applications web peuvent prendre en charge la connexion avec un compte Microsoft (anciennement Live ID) et avec des comptes à partir de Google, Facebook, Yahoo, Azure AD et Active Directory Federation Services (AD FS).
• Sécurisation des services web personnalisés avec des jetons émis par le contrôle d’accès. En utilisant l’authentification « active », les services web peuvent s’assurer qu’ils autorisent uniquement l’accès aux clients connus qui se sont authentifiés auprès du contrôle d’accès.

Chacun de ces cas d’usage et leurs stratégies de migration recommandées sont abordés dans les sections suivantes.

Le contrôle d’accès comporte les composants suivants :

• Un service de jeton sécurisé (STS), qui reçoit les demandes d’authentification et émet des jetons de sécurité en retour.
• Le portail Azure Classic, où vous créez, supprimez et activez et désactivez les espaces de noms Access Control.
• Portail de gestion de contrôle d’accès distinct, dans lequel vous personnalisez et configurez les espaces de noms Access Control.
• Un service de gestion, que vous pouvez utiliser pour automatiser les fonctions des portails.
• Un moteur de règles de transformation de jetons, que vous pouvez utiliser pour définir une logique complexe afin de manipuler le format de sortie des jetons émis par le contrôle d'accès.

Pour utiliser ces composants, vous devez créer un ou plusieurs espaces de noms Access Control. Un espace de noms est une instance dédiée du contrôle d’accès avec laquelle vos applications et services communiquent. Un espace de noms est isolé de tous les autres clients Access Control. D’autres clients Access Control utilisent leurs propres espaces de noms. Un espace de noms dans Access Control a une URL dédiée qui ressemble à ceci :

https://<mynamespace>.accesscontrol.windows.net

Toutes les communications avec le STS et les opérations de gestion sont effectuées à cette URL. Vous utilisez différents chemins à des fins différentes. Pour déterminer si vos applications ou services utilisent Access Control, surveillez tout trafic vers https://<espace de noms>.accesscontrol.windows.net. Tout trafic vers cette URL est géré par le contrôle d’accès et doit être supprimé.

L’exception à ceci est tout trafic vers https://accounts.accesscontrol.windows.net. Le trafic vers cette URL est déjà géré par un autre service et n’est pas affecté par l'abandon du contrôle d'accès.

Pour plus d’informations sur access Control, consultez Access Control Service 2.0 (archivé).

Déterminer les applications qui seront affectées

Suivez les étapes décrites dans cette section pour savoir quelles applications seront affectées par la mise hors service ACS.

Télécharger et installer ACS PowerShell

1. Accédez à PowerShell Gallery et téléchargez Acs.Namespaces.

2. Installer le module en exécutant

   Install-Module -Name Acs.Namespaces
   

3. Obtenir la liste de toutes les commandes possibles en exécutant

   Get-Command -Module Acs.Namespaces
   

   Pour obtenir de l’aide sur une commande spécifique, exécutez :

    Get-Help [Command-Name] -Full
   

   où [Command-Name] est le nom de la commande ACS.

Listez vos espaces de noms ACS

1. Connectez-vous à ACS à l’aide de l’applet de commande Connect-AcsAccount.

   Vous devrez peut-être exécuter Set-ExecutionPolicy -ExecutionPolicy Bypass avant de pouvoir exécuter des commandes et être l’administrateur de ces abonnements pour exécuter les commandes.

2. Répertoriez vos abonnements Azure disponibles à l’aide de l’applet de commande Get-AcsSubscription .

3. Répertoriez vos espaces de noms ACS à l’aide de l’applet de commande Get-AcsNamespace .

Vérifier les applications qui seront affectées

1. Utilisez l’espace de noms de l’étape précédente et accédez à https://<namespace>.accesscontrol.windows.net

   Par exemple, si l'un des espaces de noms est contoso-test, accédez à https://contoso-test.accesscontrol.windows.net

2. Sous Relations de confiance, sélectionnez applications de partie de confiance pour afficher la liste des applications qui seront affectées par le retrait de service ACS.

3. Répétez les étapes 1 à 2 pour tout autre espace de noms ACS dont vous disposez.

Calendrier de mise hors service

Depuis novembre 2017, tous les composants Access Control sont entièrement pris en charge et opérationnels. La seule restriction est que vous ne pouvez pas créer d’espaces de noms Access Control via le portail Azure Classic.

Voici le calendrier de la mise hors service des composants de contrôle d’accès :

• novembre 2017: l’expérience d’administration Azure AD dans le portail Azure Classic est supprimée. À ce stade, la gestion des espaces de noms pour Access Control est disponible sur une nouvelle URL dédiée : https://manage.windowsazure.com?restoreClassic=true. Utilisez cette URL pour afficher vos espaces de noms existants, activer et désactiver des espaces de noms, et pour supprimer des espaces de noms, si vous choisissez de le faire.
• le 2 avril 2018: le portail Azure Classic est complètement mis hors service, ce qui signifie que la gestion des espaces de noms Access Control n’est plus disponible via une URL quelconque. À ce stade, vous ne pouvez pas désactiver ou activer, supprimer ou énumérer vos espaces de noms Access Control. Toutefois, le portail de gestion du contrôle d’accès sera entièrement fonctionnel et situé à https://<namespace>.accesscontrol.windows.net. Tous les autres composants du contrôle d’accès continuent de fonctionner normalement.
• le 7 novembre 2018: Tous les composants Access Control sont arrêtés définitivement. Cela inclut le portail de gestion du contrôle d'accès, le service de gestion, STS et le moteur de règles de transformation de jetons. À ce stade, toutes les demandes envoyées au contrôle d’accès (situées à <namespace>.accesscontrol.windows.net) échouent. Vous devez avoir migré toutes les applications et services existants vers d’autres technologies avant cette période.

Stratégies de migration

Les sections suivantes décrivent les recommandations générales relatives à la migration de Access Control vers d’autres technologies Microsoft.

Clients des services cloud Microsoft

Chaque service cloud Microsoft qui accepte les jetons émis par Access Control prend désormais en charge au moins une autre forme d’authentification. Le mécanisme d’authentification approprié varie pour chaque service. Nous vous recommandons de consulter la documentation spécifique de chaque service pour obtenir des conseils officiels. Pour plus de commodité, chaque ensemble de documentation est fourni ici :

Clients de SharePoint

Les clients SharePoint 2013, 2016 et SharePoint Online ont depuis longtemps utilisé ACS à des fins d’authentification dans les scénarios cloud, locaux et hybrides. Certaines fonctionnalités sharePoint et certains cas d’usage seront affectés par la mise hors service ACS, tandis que d’autres ne le seront pas. Le tableau ci-dessous récapitule les instructions de migration pour certaines des fonctionnalités SharePoint les plus populaires qui tirent parti des services ACS :

Applications web qui utilisent l’authentification passive

Pour les applications web qui utilisent Access Control pour l’authentification utilisateur, Access Control fournit les fonctionnalités et fonctionnalités suivantes aux développeurs et architectes d’applications web :

• Intégration approfondie à Windows Identity Foundation (WIF).
• Fédération avec les comptes Google, Facebook, Yahoo, Azure Active Directory, AD FS et Microsoft.
• Prise en charge des protocoles d’authentification suivants : OAuth 2.0 Draft 13, WS-Trust et Web Services Federation (WS-Federation).
• Prise en charge des formats de jeton suivants : JSON Web Token (JWT), SAML 1.1, SAML 2.0 et Simple Web Token (SWT).
• Expérience de découverte du domaine d’accueil, intégrée à WIF, qui permet aux utilisateurs de choisir le type de compte qu’ils utilisent pour se connecter. Cette expérience est hébergée par l’application web et est entièrement personnalisable.
• Transformation de jeton qui permet une personnalisation avancée des revendications reçues par l’application web provenant du contrôle d’accès, notamment :
  • Transmettez les revendications des fournisseurs d’identité.
  • Ajout de revendications personnalisées supplémentaires.
  • Logique conditionnelle simple "si-alors" pour émettre des déclarations sous certaines conditions.

Malheureusement, il n’existe pas un service qui offre toutes ces fonctionnalités équivalentes. Vous devez évaluer les fonctionnalités du contrôle d’accès dont vous avez besoin, puis choisir entre utiliser 'ID Microsoft Entra, Azure Active Directory B2C (Azure AD B2C) ou un autre service d’authentification cloud.

Migrer vers l’ID Microsoft Entra

Un chemin à prendre en compte consiste à intégrer vos applications et services directement à l’ID Microsoft Entra. L’ID Microsoft Entra est le fournisseur d’identité basé sur le cloud pour les comptes professionnels ou scolaires Microsoft. Microsoft Entra ID est le fournisseur d’identité pour Microsoft 365, Azure et bien plus encore. Il fournit des fonctionnalités d’authentification fédérées similaires à Access Control, mais ne prend pas en charge toutes les fonctionnalités de contrôle d’accès.

L’exemple principal est la fédération avec les fournisseurs d’identité sociale, tels que Facebook, Google et Yahoo. Si vos utilisateurs se connectent avec ces types d’informations d’identification, l’ID Microsoft Entra n’est pas la solution pour vous.

Microsoft Entra ID ne prend pas nécessairement en charge les mêmes protocoles d’authentification que Access Control. Par exemple, bien que Access Control et Microsoft Entra ID prennent en charge OAuth, il existe des différences subtiles entre chaque implémentation. Différentes implémentations vous obligent à modifier le code dans le cadre d’une migration.

Toutefois, Microsoft Entra ID offre plusieurs avantages potentiels aux clients Access Control. Il prend en charge en mode natif les comptes professionnels ou scolaires Microsoft hébergés dans le cloud, qui sont couramment utilisés par les clients Access Control.

Un locataire Microsoft Entra peut également être fédéré à une ou plusieurs instances d’Active Directory local via AD FS. De cette façon, votre application peut authentifier les utilisateurs et utilisateurs basés sur le cloud hébergés localement. Il prend également en charge le protocole WS-Federation, ce qui facilite l’intégration à une application web à l’aide de WIF.

Le tableau suivant compare les fonctionnalités du contrôle d’accès qui sont pertinentes pour les applications web avec celles disponibles dans l’ID Microsoft Entra.

De manière générale, Microsoft Entra ID est probablement le meilleur choix pour votre migration si vous laissez les utilisateurs se connecter uniquement à l'aide de leurs comptes professionnels ou scolaires Microsoft.

Si vous décidez que Microsoft Entra ID est le meilleur chemin de migration pour vos applications et services, vous devez connaître deux façons d’intégrer votre application à l’ID Microsoft Entra.

Pour utiliser WS-Federation ou WIF pour l’intégrer à Microsoft Entra ID, nous vous recommandons de suivre l’approche décrite dans Configurer l’authentification unique fédérée pour une application non-galerie. L’article fait référence à la configuration de l’ID Microsoft Entra pour l’authentification unique basée sur SAML, mais fonctionne également pour la configuration de WS-Federation. Pour suivre cette approche, vous devez disposer d’une licence Microsoft Entra ID P1 ou P2. Cette approche présente deux avantages :

• Vous bénéficiez de la flexibilité totale de la personnalisation des jetons Microsoft Entra. Vous pouvez personnaliser les revendications émises par l’ID Microsoft Entra pour qu’elles correspondent aux revendications émises par le contrôle d’accès. Cela inclut en particulier l'identifiant utilisateur ou la revendication d'identifiant de nom. Pour continuer à recevoir des ID utilisateur cohérents pour vos utilisateurs après avoir modifié les technologies, assurez-vous que les ID utilisateur émis par Microsoft Entra ID correspondent à ceux émis par Access Control.
• Vous pouvez configurer un certificat de signature de jeton spécifique à votre application et avec une durée de vie que vous contrôlez.

Une autre approche consiste à suivre cet exemple de code, ce qui donne des instructions légèrement différentes pour configurer WS-Federation. Cet exemple de code n’utilise pas WIF, mais plutôt le middleware OWIN ASP.NET 4.5. Toutefois, les instructions relatives à l’inscription d’application sont valides pour les applications utilisant WIF et ne nécessitent pas de licence Microsoft Entra ID P1 ou P2.

Si vous choisissez cette approche, vous devez comprendre la rotation de clé de signature dans Microsoft Entra ID. Cette approche utilise la clé de signature globale Microsoft Entra pour émettre des jetons. Par défaut, WIF n’actualise pas automatiquement les clés de signature. Lorsque Microsoft Entra ID fait pivoter ses clés de signature globales, votre implémentation WIF doit être prête à accepter les modifications. Pour plus d’informations, consultez Informations importantes sur la substitution de clé de signature dans Microsoft Entra ID.

Si vous pouvez l’intégrer à Microsoft Entra ID via les protocoles OpenID Connect ou OAuth, nous vous recommandons de le faire. Nous avons une documentation complète et des conseils sur la façon d’intégrer Microsoft Entra ID à votre application web disponible dans notre guide de développement Microsoft Entra.

Migrer vers Azure Active Directory B2C

L’autre chemin de migration à prendre en compte est Azure AD B2C. Azure AD B2C est un service d’authentification cloud qui, comme Access Control, permet aux développeurs d’externaliser leur logique d’authentification et de gestion des identités vers un service cloud. Il s’agit d’un service payant (avec des niveaux gratuit et Premium) conçu pour les applications destinées aux consommateurs qui peuvent avoir jusqu’à des millions d’utilisateurs actifs.

Comme Access Control, l’une des fonctionnalités les plus attrayantes d’Azure AD B2C est qu’elle prend en charge de nombreux types de comptes différents. Avec Azure AD B2C, vous pouvez connecter des utilisateurs en utilisant leur compte Microsoft ou Facebook, Google, LinkedIn, GitHub ou Yahoo, etc. Azure AD B2C prend également en charge les « comptes locaux », ou le nom d’utilisateur et les mots de passe que les utilisateurs créent spécifiquement pour votre application. Azure AD B2C fournit également une extensibilité riche que vous pouvez utiliser pour personnaliser vos flux de connexion.

Toutefois, Azure AD B2C ne prend pas en charge l’étendue des protocoles d’authentification et des formats de jeton dont les clients Access Control peuvent avoir besoin. Vous ne pouvez pas également utiliser Azure AD B2C pour obtenir des jetons et demander des informations supplémentaires sur l’utilisateur à partir du fournisseur d’identité, Microsoft ou autrement.

Le tableau suivant compare les fonctionnalités du contrôle d’accès qui sont pertinentes pour les applications web avec celles disponibles dans Azure AD B2C. À un niveau élevé, Azure AD B2C est probablement le bon choix pour votre migration si votre application est orientée consommateur, ou si elle prend en charge de nombreux types de comptes différents.

Si vous décidez qu’Azure AD B2C est le meilleur chemin de migration pour vos applications et services, commencez par les ressources suivantes :

• Documentation d'Azure AD B2C
• stratégies personnalisées Azure AD B2C
• Tarification d’Azure AD B2C

Migrer vers Ping Identity ou Auth0

Dans certains cas, vous pouvez constater que Microsoft Entra ID et Azure AD B2C ne sont pas suffisants pour remplacer le contrôle d’accès dans vos applications web sans apporter de modifications de code majeures. Voici quelques exemples courants :

• Applications web qui utilisent WIF ou WS-Federation pour la connexion avec des fournisseurs d’identité sociale tels que Google ou Facebook.
• Applications web qui effectuent une fédération directe vers un fournisseur d’identité d’entreprise via le protocole WS-Federation.
• Applications web qui nécessitent le jeton d’accès émis par un fournisseur d’identité sociale (tel que Google ou Facebook) en tant que revendication dans les jetons émis par le contrôle d’accès.
• Applications web avec des règles de transformation de jeton complexes que Microsoft Entra ID ou Azure AD B2C ne peuvent pas reproduire.
• Applications web mutualisées qui utilisent ACS pour gérer de manière centralisée la fédération à de nombreux fournisseurs d’identité différents

Dans ces cas, vous pouvez envisager de migrer votre application web vers un autre service d’authentification cloud. Nous vous recommandons d’explorer les options suivantes. Chacune des options suivantes offre des fonctionnalités similaires au contrôle d’accès :

Auth0 est un service d'identité cloud flexible qui a créé des orientations de migration de haut niveau pour les clients du contrôle d’accès, et prend en charge presque toutes les fonctionnalités d'ACS.

Ping Identity offre deux solutions similaires à ACS. PingOne est un service d’identité cloud qui prend en charge de nombreuses fonctionnalités identiques à ACS, et PingFederate est un produit d’identité local similaire qui offre plus de flexibilité. Pour plus d’informations sur l’utilisation de ces produits, reportez-vous aux conseils de mise hors service ACS de Ping.

Notre objectif de travailler avec Ping Identity et Auth0 est de s’assurer que tous les clients Access Control disposent d’un chemin de migration pour leurs applications et services, ce qui réduit la quantité de travail requise pour passer du contrôle d’accès.

Services web qui utilisent l’authentification active

Pour les services web sécurisés avec des jetons émis par le contrôle d’accès, Access Control offre les fonctionnalités et fonctionnalités suivantes :

• Possibilité d’inscrire une ou plusieurs identités de service dans votre espace de noms Access Control. Les identités de service peuvent être utilisées pour demander des jetons.
• Prise en charge des protocoles OAuth WRAP et OAuth 2.0 Draft 13 pour la demande de jetons, à l’aide des types d’informations d’identification suivants :
  • Mot de passe simple créé pour l’identité de service
  • Un swT signé à l’aide d’une clé symétrique ou d’un certificat X509
  • Jeton SAML émis par un fournisseur d’identité approuvé (généralement, une instance AD FS)
• Prise en charge des formats de jeton suivants : JWT, SAML 1.1, SAML 2.0 et SWT.
• Règles de transformation de jetons simples.

Les identités de service dans le contrôle d’accès sont généralement utilisées pour implémenter l’authentification serveur à serveur.

Migrer vers l’ID Microsoft Entra

Notre recommandation pour ce type de flux d’authentification consiste à migrer vers Microsoft Entra ID. L’ID Microsoft Entra est le fournisseur d’identité basé sur le cloud pour les comptes professionnels ou scolaires Microsoft. Microsoft Entra ID est le fournisseur d’identité pour Microsoft 365, Azure et bien plus encore.

Vous pouvez également utiliser l’ID Microsoft Entra pour l’authentification serveur à serveur à serveur à l’aide de l’implémentation Microsoft Entra de l’octroi des informations d’identification du client OAuth. Le tableau suivant compare les fonctionnalités du contrôle d’accès dans l’authentification serveur à serveur avec celles disponibles dans l’ID Microsoft Entra.

Pour obtenir des conseils sur l’implémentation de scénarios serveur à serveur, consultez les ressources suivantes :

• Section de service à service du guide du développeur Microsoft Entra
• Exemple de code de démon utilisant des identifiants client avec un mot de passe simple
• exemple de code démon à l’aide des informations d’identification du client de certificat

Migrer vers Ping Identity ou Auth0

Dans certains cas, vous pouvez constater que les informations d’identification du client Microsoft Entra et l’implémentation d’octroi OAuth ne sont pas suffisantes pour remplacer le contrôle d’accès dans votre architecture sans modifications majeures du code. Voici quelques exemples courants :

• Authentification de serveur à serveur à l’aide de formats de jeton autres que les JWT.
• Authentification serveur à serveur à serveur à l’aide d’un jeton d’entrée fourni par un fournisseur d’identité externe.
• Authentification serveur à serveur avec des règles de transformation de jetons que Microsoft Entra ID ne peut pas reproduire.

Dans ce cas, vous pouvez envisager de migrer votre application web vers un autre service d’authentification cloud. Nous vous recommandons d’explorer les options suivantes. Chacune des options suivantes offre des fonctionnalités similaires au contrôle d’accès :

Auth0 est un service d'identité cloud flexible qui a créé des orientations de migration de haut niveau pour les clients du contrôle d’accès, et prend en charge presque toutes les fonctionnalités d'ACS.

Ping Identity offre deux solutions similaires à ACS. PingOne est un service d’identité cloud qui prend en charge de nombreuses fonctionnalités identiques à ACS, et PingFederate est un produit d’identité local similaire qui offre plus de flexibilité. Pour plus d’informations sur l’utilisation de ces produits, reportez-vous aux conseils de mise hors service ACS de Ping.

Notre objectif de travailler avec Ping Identity et Auth0 est de s’assurer que tous les clients Access Control disposent d’un chemin de migration pour leurs applications et services, ce qui réduit la quantité de travail requise pour passer du contrôle d’accès.

Authentification par transit

Pour l’authentification directe avec une transformation de jeton arbitraire, il n’existe aucune technologie Microsoft équivalente à ACS. Si c’est ce dont vos clients ont besoin, Auth0 peut être celui qui fournit la solution d’approximation la plus proche.

Questions, préoccupations et commentaires

Nous comprenons que de nombreux clients Access Control ne trouveront pas de chemin de migration clair après avoir lu cet article. Vous devrez peut-être obtenir de l’aide ou des conseils pour déterminer le bon plan. Si vous souhaitez discuter de vos scénarios et questions de migration, laissez un commentaire sur cette page.