Exporter (0) Imprimer
Développer tout

Ajout d'une procédure d'authentification à une application web avec Azure AD

Mis à jour: mai 2014

noteRemarque
Cet exemple est obsolète, car la technologie, les méthodes et/ou les instructions sur l'interface utilisateur auxquelles il fait appel ont été remplacées par des fonctionnalités plus récentes. Pour obtenir un exemple actualisé permettant de créer une application similaire, consultez WebApp-OpenIDConnect-DotNet.

.

Cette procédure pas à pas montre comment utiliser Azure AD pour implémenter l'authentification unique via le web dans une application ASP.NET. Les instructions vous aideront à tirer parti du locataire d'annuaire associé à votre abonnement Azure, celui-ci constituant le choix logique des fournisseurs d'identité pour les applications métiers dans votre organisation.

Une solution d'authentification unique via le web implique généralement la configuration d'une application web qui sous-traite ses fonctions d'authentification à une entité externe (communément appelée « fournisseur d'identité »). Concrètement, cela signifie que l'application est configurée pour rediriger les demandes non authentifiées vers un fournisseur d'identité selon un protocole d'authentification tel que SAML-P, WS-Federation ou OpenID Connect.

L'autorité (ou fournisseur d'identité) gère l'expérience d'authentification et exige habituellement que l'application web soit déjà connue par l'intermédiaire d'un processus de déploiement. Après une authentification réussie, le navigateur est redirigé vers l'application web et présente un jeton de sécurité contenant des informations sur l'utilisateur entrant ; l'application valide le jeton, généralement par l'intermédiaire d'un intergiciel (middleware) prenant en charge l'identité. Si la vérification aboutit, l'utilisateur est considéré comme authentifié et est connecté.

Cette description d'ordre général s'applique aussi à Azure AD. Ce document montre comment utiliser Visual Studio 2012 et les classes Windows Identity Foundation (WIF) dans le .NET Framework 4.5 pour configurer une application MVC 4 de sorte qu'elle utilise un protocole d'authentification web. Vous allez apprendre à déployer la même application dans un locataire Azure AD et à configurer les paramètres d'authentification de l'application pour établir une connexion à ce locataire. À la fin de la procédure pas à pas, vous disposerez d'une application web opérationnelle et entièrement configurée pour l'authentification unique au sein de votre organisation.

Le but de cette procédure pas à pas est de vous aider à comprendre le fonctionnement d'Azure AD ; vous devrez pour cela dépasser le cadre de la procédure d'implémentation d'une solution simplifiée donnée ici. Outre des instructions concrètes vous permettant de générer un exemple fonctionnel, le document présente des artefacts et des concepts qui vous seront utiles pour vous familiariser avec Azure AD et savoir comment tirer parti de ses fonctionnalités au-delà du scénario spécifique décrit ici. Ces sections supplémentaires, qui se présentent sous la forme de remarques, ne sont pas strictement nécessaires pour exécuter la procédure pas à pas. Toutefois, si vous êtes intéressé par l'utilisation d'Azure AD dans vos propres solutions, nous vous recommandons de prendre connaissance de ces sections.

La partie didacticiel de ce document comprend les sections suivantes :

  • Configuration requise : cette section répertorie l'ensemble des conditions requises qui doivent être satisfaites pour effectuer la procédure pas à pas.

  • Architecture de la solution : cette section montre, dans les grandes lignes, à quoi ressemble une solution d'authentification unique via le web pour les applications métiers. Elle examine les composants fonctionnels de l'authentification unique et met en place une structure de base que vous étofferez par la suite en appliquant les instructions du document.

  • Utilisation de votre locataire d'annuaire Azure AD : cette section présente les locataires Azure AD et les fonctionnalités qui entrent en jeu dans le scénario. Elle décrit aussi brièvement les principaux éléments de la section Active Directory du portail de gestion Azure.

  • Connexion de l'application à Azure AD : cette section montre comment utiliser l'outil Identity and Access Tool pour Visual Studio 2012 afin d'activer l'authentification unique via le web dans l'application MVC et comment lier les paramètres d'authentification au locataire Azure AD de votre choix.

  • Rubriques avancées : cette section va au-delà des concepts de base et décrit plus en détail certains points clés. Elle couvre aussi d'autres tâches que vous devrez accomplir pour faire passer votre application au niveau supérieur.

Ce didacticiel ne peut être effectué que si les conditions préalables suivantes sont remplies :

Si vous avez des questions ou besoin d'aide, consultez Preparing for Azure AD Solutions and Scenarios.

Architecture d'une application à locataire unique

Cette procédure pas à pas couvre le scénario suivant : un développeur a écrit une application web qu'il prévoit de déployer dans le cloud, mais il souhaite en réserver l'accès aux utilisateurs d'un locataire Azure Active Directory. Pour ce faire, il doit :

  1. Inscrire l'application web dans le locataire Azure AD. Une fois l'application connue, Azure AD accepte les demandes d'authentification des utilisateurs.

  2. Ajouter quelque chose devant l'application, de telle sorte que :

    1. les demandes non authentifiées puissent être bloquées et redirigées vers le locataire Azure AD approprié pour authentifier l'utilisateur ;

    2. les utilisateurs authentifiés par Azure AD puissent être reconnus et se voir octroyer l'accès à l'application.

Nous allons effectuer la première étape en utilisant le portail de gestion Azure. Vous allez découvrir comment déployer un nouveau locataire Azure AD dans le cadre de votre abonnement Azure et comment utiliser les fonctionnalités du portail de gestion Azure AD pour inscrire une application.

La deuxième étape peut être implémentée au moyen de différents protocoles de haut niveau visant à autoriser les opérations d'authentification au-delà des limites organisationnelles et même sur Internet.

Dans la plateforme .NET, la deuxième étape se résume à configurer des classes .NET prêtes à l'emploi pour mettre en place l'identité basée sur des demandes et l'authentification fédérée. Ces classes, appelées collectivement « Windows Identity Foundation » (WIF), comprennent des modules HTTP et des paramètres de configuration que vous pouvez utiliser pour ajouter la couche d'interception en charge des tâches de redirection et d'authentification introduites à la deuxième étape. Visual Studio 2012 offre des outils pour vous aider à configurer automatiquement les applications web de manière à ce qu'elles utilisent WIF pour sous-traiter l'authentification à des autorités externes prenant en charge des protocoles d'authentification unique via le web spécifiques tels que WS-Federation. Cette procédure pas à pas explique comment utiliser ces outils avec Azure AD.

Azure Active Directory est le service d'identification principal des services Microsoft tels qu'Office 365 et Windows Intune. Si vous êtes abonné à ces services et que vous souhaitez réutiliser le locataire d'annuaire qui y est associé, créez un abonnement Azure et utilisez la fonctionnalité Ajouter un utilisateur pour ajouter un administrateur à partir de ce locataire. Cette procédure pas à pas ne fournit pas d'instructions détaillées sur ce processus.

Chaque abonnement possède un locataire Azure AD et un annuaire associé. Si le locataire a été généré automatiquement, l'annuaire a pour nom Annuaire par défaut. Toutefois, vous pouvez modifier son nom si vous le souhaitez. Dans cette partie de la procédure pas à pas, nous allons ajouter un utilisateur à l'annuaire, puis ajouter une application.

Lorsqu'un locataire d'annuaire est créé, il est configuré pour stocker les données des utilisateurs et les informations d'identification dans le cloud. Pour obtenir des instructions détaillées sur la façon d'intégrer votre locataire d'annuaire à votre déploiement local de Windows Server Active Directory, consultez Intégration d'annuaire.

Si vous avez des questions ou besoin d'aide, consultez Preparing for Azure AD Solutions and Scenarios.

Les scénarios et les solutions Azure AD (et nos exemples de code et exemples d'applications) nécessitent un compte d'utilisateur dans le domaine de votre annuaire Azure Active Directory. Si vous essayez de vous connecter aux applications à l'aide d'un compte Microsoft, comme un compte Hotmail.com, Live.com ou Outlook.com, la connexion échoue. Si votre domaine Active Directory comprend déjà un utilisateur avec un compte, par exemple User@Contoso.onmicrosoft.com, vous pouvez vous en servir pour vous connecter à ce scénario. Sinon, vous devez créer un utilisateur.

  1. Accédez au Portail de gestion Microsoft Azure (https://manage.WindowsAzure.com), ouvrez une session, puis cliquez sur Active Directory. (Conseil de dépannage : « Active Directory » est manquant ou non disponible)

  2. Si votre annuaire a pour nom « Annuaire par défaut », ajoutez un annuaire tel que « ContosoEngineering ». Pour ajouter un annuaire, en bas de la page Active Directory, cliquez sur Ajouter, puis suivez les instructions pour ajouter un nouvel annuaire.

  3. Double-cliquez sur l'annuaire, puis cliquez sur Domaines. Lorsque vous créez des comptes d'utilisateurs, utilisez le nom de domaine qui apparaît dans la page. Par exemple, si votre domaine est ContosoEngineering@onmicrosoft.com, créez des noms d'utilisateurs dans ce domaine, comme Test@ContosoEngineering@onmicrosoft.com.

  4. Pour créer un compte d'utilisateur dans le domaine, cliquez sur Utilisateurs. (Si l'onglet Utilisateurs n'est pas visible, double-cliquez sur le nom de l'annuaire. Un onglet Utilisateurs apparaît dans chaque page spécifique à l'annuaire.) En bas de la page, cliquez sur Ajouter un utilisateur.

  5. Sélectionnez Nouvel utilisateur dans votre organisation. Ajoutez un utilisateur dans votre nouveau domaine, comme Test@ContosoEngineering.onmicrosoft.com, puis cliquez sur la coche en bas de la page.

    Entrez le nom d'utilisateur et de domaine
  6. Dans la page Profil utilisateur, affectez un rôle organisationnel à l'utilisateur. Pour les besoins de test, il est préférable d'avoir au moins un utilisateur avec le rôle Administrateur général et un utilisateur avec le rôle Utilisateur.

    Entrez le rôle d'utilisateur

Lors de la dernière étape, le portail de gestion Azure génère un mot de passe temporaire dont l'utilisateur se sert la première fois qu'il se connecte. Une fois connecté pour la première fois, l'utilisateur doit changer le mot de passe temporaire. Veillez à enregistrer le mot de passe temporaire, car nous en aurons besoin pour tester le scénario.

À ce stade, nous disposons d'un locataire d'annuaire avec un utilisateur valide qui pourra servir d'autorité d'authentification dans notre scénario d'authentification unique via le web.

Mot de passe temporaire

  1. Commençons par configurer les détails de l'application. Ouvrez Visual Studio, cliquez sur Nouveau projet, puis sélectionnez Application Web ASP.NET MVC 4. Dans la fenêtre Nouveau projet ASP.NET MVC 4, sélectionnez Application Intranet, veillez à choisir le moteur de vue Razor, puis cliquez sur OK. Dans cette procédure pas à pas, nous allons utiliser ExpenseReport comme nom de projet.

    noteRemarque
    Cette procédure pas à pas suppose que votre installation Visual Studio est configurée avec les paramètres par défaut. Si vous avez modifié certaines configurations de base (comme l'endroit où les applications web sont hébergées au moment du développement), vous devrez adapter les instructions en conséquence.



    Nouveau projet dans Visual Studio

    Vous pouvez appliquer les instructions de cette procédure pas à pas à toute application web VS 2012 existante, MVC ou Web Forms, à condition qu'aucune logique ne modifie sensiblement le pipeline de traitement des demandes ASP.NET. Toutefois, pour plus de simplicité, nous allons créer ici un projet de toutes pièces.

    noteRemarque
    Cette procédure pas à pas fournit des instructions détaillées sur la configuration d'une solution .NET. Notez qu'il est possible d'obtenir les mêmes résultats si vous ciblez d'autres plateformes et piles de programmation. Azure AD utilise des protocoles ouverts dans ses fonctionnalités d'authentification web, et toutes les principales plateformes proposent des bibliothèques et des outils prenant en charge de tels protocoles. Vous devrez ajuster les étapes pour tenir compte de la syntaxe et des pratiques de chaque pile ; cependant, la subdivision des tâches de haut niveau s'applique à l'ensemble.

    Visual Studio crée un projet MVC pour vous. Celui-ci est configuré pour s'exécuter sur IIS Express. Aucune fonctionnalité supplémentaire n'est ajoutée à ce projet, les options par défaut étant suffisantes pour démontrer l'ajout de l'authentification web. La seule exception est le point de terminaison utilisé par l'application. Par défaut, Visual Studio configure votre application de telle sorte qu'elle diffuse du contenu via le protocole HTTP. Étant donné que ce protocole ne protège pas les communications et qu'il permet à des personnes malveillantes de voler des cookies et des jetons, il ne convient pas à l'établissement de sessions sécurisées. Le protocole HTTPS n'est pas obligatoire au cours de la phase de développement, et Azure n'impose pas son utilisation. Toutefois, il est toujours conseillé d'employer ce protocole.

  2. IIS Express vous permet très facilement d'activer HTTPS directement depuis Visual Studio. Sélectionnez votre projet dans l'Explorateur de solutions puis, dans le volet Propriétés, affectez à SSL activé la valeur True.

    Notez que l'URL SSL, précédemment vide, contient désormais une nouvelle adresse. Sélectionnez-la et copiez-la dans le Presse-papiers.



    Copier l'URL SSL

  3. Nous devons à présent indiquer à Visual Studio que nous souhaitons toujours utiliser le point de terminaison HTTPS au cours du débogage. Revenez à l'Explorateur de solutions, cliquez avec le bouton droit sur le projet, puis sélectionnez Propriétés. Sélectionnez l'onglet Web situé à gauche, faites défiler la page jusqu'à l'option Utiliser le serveur Web IIS local, puis collez l'URL HTTPS dans le champ URL du projet. Enregistrez (CTRL+S) les paramètres et fermez l'onglet Propriétés.



    Modifier l'URL du projet

    À ce stade, nous disposons d'une application qui peut être configurée pour utiliser Azure AD à des fins d'authentification. La prochaine étape consiste à informer votre locataire Azure AD de cette application spécifique.

  1. Réduisez Visual Studio et revenez à l'onglet Active Directory dans le portail de gestion Azure. Plus haut dans la procédure pas à pas, nous avons travaillé dans la zone Utilisateurs ; nous allons à présent nous concentrer sur la zone Applications. En haut de la page, cliquez sur Applications.



    Applications intégrées

    Cette zone répertorie les applications qui sont inscrites dans votre locataire d'annuaire. Une application est inscrite dans un locataire lorsque :

    • L'application possède une entrée dans l'annuaire qui décrit ses coordonnées principales (nom, points de terminaison associés, etc.). Nous verrons ceci plus en détail par la suite.

    • L'application a reçu l'autorisation d'effectuer une opération donnée sur le locataire d'annuaire actuel. Cela peut aller de la demande d'un jeton d'authentification jusqu'à l'interrogation de l'annuaire. Là encore, nous examinerons ceci plus en détail par la suite.

    ImportantImportant
    Aucune application ne peut utiliser Azure AD sans avoir été inscrite au préalable. Cela s'explique pour des raisons de sécurité (seules les applications approuvées par l'administrateur sont autorisées) et des considérations pratiques (l'interaction avec Azure AD implique l'utilisation de protocoles ouverts spécifiques qui nécessitent la connaissance de paramètres clés décrivant l'application).

  2. Comme nous avons créé ce locataire d'annuaire de toutes pièces, la liste d'applications inscrites est pour le moment vide. En fait, l'application que nous venons de créer dans Visual Studio constitue la première entrée, et cette section est entièrement consacrée à son inscription en tant qu'application.

    Puisqu'il s'agit de la toute première application, lancez le processus en cliquant sur le bouton Ajouter dans la barre de commandes du portail de gestion Azure en bas de l'écran. L'écran ci-dessous vous invite ensuite à fournir des informations :



    Parlez-nous de votre application

    Le processus d'inscription d'une application via le portail de gestion Azure se présente sous la forme d'un Assistant classique, à savoir une succession d'écrans qui collectent les différentes informations requises en fonction de vos choix.

    La figure ci-dessus illustre le premier de ces écrans. Les options présentées sont simples :

    • Nom d'affichage : le texte entré ici est un moniker explicite qui permet de désigner l'application chaque fois qu'un utilisateur (qu'il s'agisse d'un administrateur gérant la liste des applications inscrites ou d'un client décidant d'octroyer l'accès à l'annuaire à l'application) doit s'en servir. Pour plus d'informations à ce sujet, consultez le document Développement d'applications web multi-locataires avec Azure AD.

    • Type d'accès : ces cases d'option vous permettent de spécifier les opérations que l'application est autorisée à effectuer sur le locataire d'annuaire. Pour les besoins de ce didacticiel, dont l'objectif est simplement de configurer l'authentification unique dans l'application, choisissez Authentification unique.

      noteRemarque
      D'autres documents examinent plus en détail les autorisations des applications. Ici, nous allons simplement évoquer les principes de base au cas où vous souhaiteriez savoir ce qui se passe en arrière-plan.

      Azure AD représente les applications à l'aide d'une entité intitulée ServicePrincipal. Même si, comme son nom l'indique, cette entité est similaire aux principaux d'utilisateur plus fréquents, elle est destinée à la description d'applications.

      Dans la pratique, l'acte d'inscription d'une application passe par la création d'un ServicePrincipal pour l'application dans le locataire de l'instance d'annuaire à laquelle l'application est censée avoir accès.

      Le niveau d'accès accordé à une application donnée est déterminé par les rôles détenus par l'entité ServicePrincipal correspondante. Bien que ce ne soit pas nécessaire dans cette procédure pas à pas, vous avez la possibilité de choisir des niveaux d'accès en lecture et en écriture. Dans ce cas, des étapes supplémentaires sont ajoutées au flux d'inscription pour collecter davantage informations, notamment les clés à utiliser pour l'authentification lorsque vous effectuez de telles requêtes. Les clés sont alors stockées dans l'entité ServicePrincipal décrivant l'application. Pour plus d'informations sur ce point, consultez Utilisation de l'API Graph pour interroger Azure AD.

      Les autorisations accordées par le processus d'inscription d'application s'appliquent uniquement lors de l'accès à l'annuaire proprement dit ; elles ne déterminent pas les stratégies d'accès pour d'autres ressources Azure telles que les bases de données SQL Azure, les sections du portail de gestion et d'autres éléments similaires.

  3. Après avoir entré le nom de l'application et choisi le type d'accès Authentification unique, cliquez sur la flèche dans le coin inférieur droit pour passer à l'écran suivant.

    Propriétés de l'application Dans cet écran, le portail de gestion Azure collecte des coordonnées importantes dont le service a besoin pour mener à bien le flux du protocole de connexion. Voici ce que vous devez entrer :

    • URL DE L'APPLICATION : ce paramètre représente l'address de votre application web. Dans cet exemple, il a pour valeur https://localhost:44341/, c'est-à-dire l'adresse affectée par IIS Express à votre application. Si vous avez suivi à la lettre les instructions fournies jusqu'à présent, cette adresse doit toujours se trouver dans le Presse-papiers, prête à être collée. La valeur entrée est valide pendant toute la durée de la phase de développement ; après avoir déployé votre application dans son environnement intermédiaire ou de production cible, vous devrez revenir au portail de gestion et modifier l'adresse pour qu'elle reflète le nouvel emplacement de l'application. Nous aborderons la marche à suivre plus loin dans cette procédure pas à pas.

      WarningAvertissement
      Azure AD doit connaître l'adresse de votre application pour pouvoir rediriger le flux vers votre application après l'authentification d'un utilisateur dans les pages d'Azure AD.

      Vous devez impérativement fournir cette adresse à l'avance ; en effet, si Azure AD redirige les flux d'authentification vers n'importe quelle adresse, des personnes malveillantes peuvent facilement accéder sans autorisation aux flux d'authentification et voler les jetons. Le fait d'inscrire l'URL de votre application à l'avance permet de garantir que les jetons d'authentification destinés à votre application sont uniquement envoyés à celle-ci.

    • URI ID D'APPLICATION : ce paramètre représente l'identifier de votre application web. Azure AD utilise cette valeur au moment de l'authentification pour déterminer que la demande d'authentification est bien censée octroyer à un utilisateur l'accès à cette application particulière (parmi toutes celles inscrites), et ce afin d'appliquer les paramètres appropriés.

    noteRemarque
    L'URI ID D'APPLICATION doit être unique au sein du locataire d'annuaire. Il peut s'avérer judicieux de choisir la valeur de l'URL DE L'APPLICATION comme URI ; toutefois, si vous optez pour cette stratégie, il n'est pas toujours évident de respecter la contrainte d'unicité. En effet, le développement d'applications dans des environnements d'hébergement locaux, comme IIS Express et l'émulateur de structure Azure, a tendance à produire une gamme restreinte d'adresses qui sont réutilisées par plusieurs développeurs voire plusieurs projets du même développeur. Pour résoudre ce problème, une technique consiste à ajouter un élément à la valeur de l'URI ID D'APPLICATION pour le différencier.

    Notez également que l'URI ID D'APPLICATION est un URI. À ce titre, il ne doit pas forcément correspondre à un point de terminaison réseau adressable. Cela signifie que vous pouvez choisir quelque chose qui n'a rien à voir avec l'URL DE L'APPLICATION. En fait, bien que nous utilisions une toute nouvelle application dans ce didacticiel, vous devrez occasionnellement inscrire des applications existantes qui possèdent peut-être déjà leur propre URI ID D'APPLICATION (dans le protocole d'authentification utilisé ici, à savoir WS-Federation, l'URI ID D'APPLICATION est appelé realm). Dans ce cas, vous souhaiterez probablement l'utiliser ici. Dans la rubrique Développement d'applications web multi-locataires avec Azure AD, nous passerons en revue quelques-unes des contraintes supplémentaires introduites par l'architecture mutualisée.

  4. Après avoir entré l'URL DE L'APPLICATION et l'URI ID D'APPLICATION, cliquez sur le bouton marqué d'une coche dans le coin inférieur droit.

    Démarrage rapide Ainsi se conclut le processus d'inscription. Votre application possède désormais sa propre entrée dans le locataire d'annuaire, et Azure AD est prêt à gérer l'authentification web en son nom.

    L'écran qui vous informe de la fin de l'inscription vous fournit les informations nécessaires pour configurer votre application web de façon à ce qu'elle utilise Azure AD pour l'authentification. Plus particulièrement, la section Activer l'authentification unique avec Azure AD contient certains paramètres que vous devrez coller dans Visual Studio.

    Gardez cette page ouverte dans votre navigateur, puis revenez à Visual Studio pour effectuer la tâche suivante de la procédure pas à pas.

Azure AD est désormais en mesure d'émettre des jetons d'authentification pour votre application. La dernière étape à effectuer pour activer l'authentification web consiste à configurer l'application de manière à ce qu'elle traite les demandes avec le protocole d'authentification approprié. La mise en œuvre du protocole permet à l'application d'appeler Azure AD, et plus précisément votre locataire d'annuaire, pour authentifier l'utilisateur lorsque ce dernier démarre une session de travail avec l'application.

Il est important d'avoir quelques notions de base sur les mécanismes d'authentification lors de l'utilisation de protocoles d'authentification web. Vous trouverez plus de détails dans la section Rubriques avancées.

Le modèle de projet que nous avons choisi est l'application intranet MVC 4. Ce modèle repose normalement sur l'authentification Windows intégrée pour authentifier l'utilisateur de l'application. Ce mécanisme fonctionne au niveau du réseau : il est appliqué à tous les services publiés sur l'intranet, sans qu'il soit nécessaire d'ajouter une logique d'authentification à l'application en question.

Lorsque vous déployez une application en dehors de votre intranet, comme c'est le cas des applications cloud, vous ne pouvez plus compter sur l'authentification au niveau du réseau. Dans ce cas, une stratégie couramment employée consiste à ajouter un intergiciel (middleware) devant votre application pour recréer la vérification d'authentification nécessaire à un niveau supérieur. La couche supplémentaire peut intercepter les demandes non authentifiées, mettre en œuvre des protocoles d'authentification, rediriger les utilisateurs vers une procédure d'authentification en dehors de l'application, transmettre à l'application des informations sur l'utilisateur authentifié, gérer les sessions et, de manière générale, effectuer toutes les tâches nécessaires au contrôle de l'accès.

Cette stratégie est appliquée uniformément dans l'industrie sur l'ensemble des plateformes, piles de développement et protocoles d'authentification ; ce qui se passe sur le réseau et le modèle de programmation varie, mais la structure générale est dans l'ensemble la même.

Dans cette procédure pas à pas, nous allons connecter l'application à Azure AD via le protocole WS-Federation. D'autres protocoles sont disponibles pour implémenter l'authentification unique via le web, SAML-P étant l'autre option la plus couramment utilisée.

Le .NET Framework 4.5 prend en charge WS-Federation en mode natif : toutes les classes nécessaires à la mise en œuvre du flux du protocole, au traitement de l'authentification et à la gestion des sessions dans le contexte des applications ASP.NET sont prêtes à l'emploi.

En résumé : .NET 4.5 propose un ensemble de modules HttpModule qui sont destinés à être instanciés dans le pipeline HTTP de l'application. Ces modules sont conçus pour faire référence à des sections de configuration connues qui contiennent les coordonnées de protocole de l'application et de l'autorité d'authentification (dans ce cas, votre locataire Azure AD). Lorsqu'une demande arrive, les modules l'examinent et mettent en œuvre le protocole d'authentification approprié. Par exemple, lorsqu'ils reçoivent une demande non authentifiée, les modules lisent les coordonnées du locataire Azure AD dans la configuration, puis s'en servent pour composer un message de connexion WS-Federation et rediriger automatiquement l'utilisateur afin qu'il s'authentifie auprès d'Azure AD.

noteRemarque
« Windows Identity Foundation » (WIF) est le nom du sous-ensemble de classes dédiées aux tâches relatives à l'identité basée sur des demandes dans le .NET Framework 4.5. Les applications ciblant les versions antérieures du .NET Framework (3.5 et 4.0) peuvent également implémenter les étapes décrites dans cette procédure pas à pas en tirant parti d'une version antérieure de WIF publiée hors bande sous forme d'une bibliothèque autonome (téléchargeable ici). Toutefois, du fait que les deux versions ne sont pas entièrement compatibles (les classes résident dans des espaces de noms différents) et que vous devez utiliser des outils pour différentes versions de Visual Studio (2008 et 2010, téléchargeable ici), les instructions étape par étape ne sont pas identiques.

Visual Studio 2012 propose des outils de type pointer-cliquer qui peuvent vous aider à configurer les applications de manière à utiliser WS-Federation pour l'authentification web. Vous pouvez utiliser l'interface utilisateur de l'outil pour fournir des informations clés sur l'autorité que vous souhaitez approuver pour l'authentification, et l'outil émettra les entrées de configuration correspondantes. Dans cette procédure pas à pas, vous ne devrez écrire que très peu de code, les outils générant automatiquement la majeure partie de celui-ci.

  1. À présent que vous savez comment nous allons implémenter l'authentification web, lançons l'outil Identity and Access Tool pour configurer l'application. Dans l'Explorateur de solutions, cliquez avec le bouton droit sur le projet de votre application, puis cliquez sur Identité et accès dans le menu contextuel.

    Identité et accès Visual Studio affiche la boîte de dialogue suivante.

    Fournisseurs d'identité et d'accès Tout le travail à fournir s'effectue sous l'onglet Fournisseurs qui apparaît ici. Dans cette procédure pas à pas, nous allons ignorer toutes les options dont nous n'avons pas besoin.

  2. L'outil répertorie les différents types d'autorités que vous pouvez utiliser pour sous-traiter l'authentification. Dans notre cas précis, nous allons recourir à un fournisseur d'identités d'entreprise. Par conséquent, cliquez sur l'entrée correspondante, à savoir la deuxième option en partant du haut.

    Configuration des identités et de l'accès Lorsque vous sélectionnez cette option, les éléments d'interface utilisateur correspondants apparaissent en dessous. Les informations qui vous demandées correspondent exactement aux entrées affichées à la fin du processus d'inscription de l'application décrit dans la section précédente. Voici donc ce que vous devez entrer, en commençant par le bas :

    • Entrez l'URI ID D'APPLICATION (domaine) de votre application : il s'agit de l'identificateur de votre application, tel que vous l'avez défini lors de l'inscription. Revenez à la fenêtre du navigateur affichant le portail de gestion, copiez la valeur correspondante contenue dans le champ Mettre à jour votre code avec votre URI ID d'application, puis collez-le ici.

    • Entrez le chemin d'accès au document de métadonnées STS : le « document de métadonnées STS » est un fichier contenant une description lisible par machine de l'autorité à laquelle vous souhaitez vous connecter. L'outil se sert de cette description pour déterminer la valeur des paramètres qui sont essentiels pour le flux d'authentification (plus de détails ci-dessous). Chaque locataire Azure AD expose un document de ce type (son emplacement est fourni à la fin du processus d'inscription). Passez au portail de gestion, copiez la valeur correspondante contenue dans la page d'inscription de l'application, revenez à l'outil, puis collez le chemin d'accès dans ce champ.

      noteRemarque
      Lorsque vous collez le chemin d'accès du document de métadonnées dans la zone de texte, l'outil affiche un avertissement indiquant qu'un certificat n'est pas valide. Cela est dû au fait que le document de métadonnées est signé avec un certificat auto-signé. Donc, ne vous inquiétez pas.

    Appuyez sur OK. L'outil accède au document de métadonnées spécifié, lit les coordonnées de l'autorité (adresse des points de terminaison à utiliser pour l'authentification, certificat X.509 à utiliser pour vérifier la signature des jetons d'authentification, format et version des jetons d'authentification émis, etc.), puis utilise ces informations pour générer les entrées nécessaires pour connecter l'application à Azure AD et les ajouter au fichier web.config.

La liste suivante décrit les entrées principales ajoutées au fichier web.config par l'outil. Pour obtenir une description plus détaillée, consultez la section Rubriques avancées du document.

  • Entrées <section> pour system.identityModel et system.identityModel.services : celles-ci sont nécessaires pour que la configuration comprenne les paramètres de configuration spécifiques à l'identité.

  • Paramètres <authorization> dans <system.web> : l'outil modifie automatiquement les paramètres d'authentification ASP.NET existants afin d'exiger que chaque demande à l'application soit authentifiée. Il en résulte la mise en œuvre du soi-disant comportement « blanket redirect » (redirection globale), selon lequel chaque demande non authentifiée est redirigée vers l'autorité d'authentification. Cela permet d'empêcher les utilisateurs non authentifiés d'accéder à certaines parties de l'application. Ce comportement est défini par défaut dans les applications métiers dans lesquelles l'authentification est souvent silencieuse, ce qui se produit lorsque l'utilisateur est déjà connecté à l'autorité. Si le développeur souhaite modifier ce comportement afin de fournir des conditions d'authentification au cas par cas, il lui suffit de modifier les paramètres <authorization> en conséquence.

  • WSFederationAuthenticationModule (FAM) et SessionAuthenticationModule (SAM) dans <system.webServer/modules> : ces entrées ajoutent au pipeline HTTP de l'application les modules HttpModule chargés de mettre en œuvre l'utilisation du protocole WS-Federation pour l'authentification. Le module FAM est responsable de la mise en œuvre du protocole, principalement les flux de demande d'authentification, de validation des jetons et de gestion des déconnexions. Le module SAM gère quant à lui les sessions ; plus précisément, il génère des cookies de session, les valide et met en œuvre leur présence à chaque demande, gère la longueur de la session, etc. Leur comportement dépend de l'élément config décrit ci-dessous.

  • Section <system.identitymodel/identityConfiguration> : cet élément détermine le comportement de l'application pendant la phase d'authentification. Par exemple : dans le sous-élément ValidatingIssuerNameRegistry, il stocke la liste des autorités qui sont autorisées à fournir des services d'authentification en enregistrant leurs noms et les certificats qu'ils utilisent pour la signature.

  • Section <system.identitymodel.services/federationConfiguration> : cette section fournit les coordonnées nécessaires à l'acheminement des flux WS-Federation (adresse de l'autorité à utiliser pour les demandes d'authentification, identificateur de l'application devant figurer dans les demandes, etc.).

Seul l'élément config généré automatiquement est nécessaire pour utiliser Azure AD à des fins d'authentification web ; vous n'êtes donc pas contraint d'écrire du code spécifique à l'authentification dans l'application. Pour accéder aux informations d'identité de l'utilisateur, il vous suffit d'interroger les revendications dans le principal actuel. Supposons que vous souhaitiez accéder au prénom et au nom de l'utilisateur actuel. Vous pouvez pour cela utiliser le code suivant, sans pour autant savoir comment l'authentification s'est déroulée :

//...
using System.Security.Claims;

namespace ExpenseReport.Controllers
{
  public class HomeController : Controller
  {
    public ActionResult Index()
    {            
      ClaimsPrincipal cp = ClaimsPrincipal.Current;
      string fullname = 
             string.Format("{0} {1}", cp.FindFirst(ClaimTypes.GivenName).Value,
             cp.FindFirst(ClaimTypes.Surname).Value);
      ViewBag.Message = string.Format("Dear {0}, welcome to the Expense Note App", 
                        fullname);
      return View();
     }
//...

À compter du .NET 4.5, chaque identité dans le .NET est représentée avec un ClaimsPrincipal. Ici, le ClaimsPrincipal actuel a été construit lors de la validation d'un jeton d'authentification généré par Azure AD et présenté par l'utilisateur au moment de l'authentification.

Chaque ClaimsPrincipal contient une collection de revendications, c'est-à-dire des attributs décrivant l'utilisateur actuel tel qu'il est déclaré par l'autorité l'ayant authentifié. Dans notre procédure pas à pas, les revendications dans le principal sont celles émises dans le jeton par Azure Active Directory. Pour obtenir la liste complète des revendications disponibles, consultez la documentation en ligne.

Azure AD émet un ensemble fixe de revendications pour les utilisateurs authentifiés. Vous trouverez ci-dessous un aide-mémoire regroupant toutes les revendications d'Azure AD. Pour obtenir une description complète, consultez la documentation.

 

Type Valeur dans l'exemple Description

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier

S40rgb3XjhFTv6EQTETkEzcgVmToHKRkZUIsJlmLdVc

Identificateur unique, non modifiable, non réutilisable, dirigé de l'utilisateur authentifié pour l'application actuelle

http://schemas.microsoft.com/identity/claims/objectidentifier

528b2ac2-aa9c-45e1-88d4-959b53bc7dd0

Identificateur de l'utilisateur dans l'annuaire. Utile pour les requêtes d'annuaire sur l'utilisateur.

http://schemas.microsoft.com/identity/claims/tenantid

cab1a5ac-f33b-45fa-9bf5-f37db0fed422

Identificateur du locataire d'annuaire

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

John

Prénom de l'utilisateur

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

user@test04-realm2

UPN de l'utilisateur

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname

Doe

Nom de l'utilisateur

http://schemas.microsoft.org/identity/claims/identityprovider

https://sts.windows.net/cab1a5ac-f33b-45fa-9bf5-f37db0fed422/

Identificateur de l'autorité ayant authentifié l'utilisateur, tel qu'il est exprimé dans le protocole d'authentification web (dans ce cas, WS_Federation)

À ce stade, votre application dispose de toutes les informations nécessaires pour vous permettre de démontrer l'authentification web avec Azure AD. Toutefois, votre travail n'est pas terminé. Vous pouvez ajouter au moins deux autres fonctionnalités importantes : la prise en charge de la déconnexion et l'actualisation automatique des coordonnées de protocole de l'autorité.

Les deux prochaines sections examinent en détail comment ajouter ces deux fonctionnalités. Nous vous recommandons de les consulter avant de passer à la section « Exécution de votre Application ».

Les protocoles d'authentification web utilisés aujourd'hui incluent souvent des dispositions permettant d'effectuer des opérations de déconnexion distribuées. Dans ces flux, l'application actuelle annule non seulement la session de l'utilisateur actuel, mais contacte aussi l'autorité pour lui signaler qu'une commande de déconnexion doit être propagée à toutes les sessions des autres applications susceptibles d'avoir été établies par la même autorité. WS-Federation n'échappe pas à cette règle et offre un flux de déconnexion complet qui est entièrement implémenté dans le modèle objet WIF. Dans cette sous-section, nous allons voir comment ajouter des fonctionnalités de déconnexion distribuées à l'exemple d'application. Pour cela, nous devrons inclure dans l'expérience de l'utilisateur des éléments permettant de déclencher le flux de déconnexion et générer un message de déconnexion approprié à afficher dans votre locataire Azure AD.

  1. Commencez par ajouter un contrôleur SignOut à l'application. Pour cela, accédez au dossier Contrôleurs sous le projet dans l'Explorateur de solutions, cliquez dessus avec le bouton droit et sélectionnez Ajouter, puis cliquez sur Contrôleur. Nommez le contrôleur SignOutController, sélectionnez Contrôleur MVC vide (il s'agit généralement du paramètre par défaut), puis cliquez sur Ajouter.

  2. Comme nous devons utiliser les classes de nouveaux assemblys, nous allons ajouter des références à ceux-ci. Là encore, dans l'Explorateur de solutions, cliquez avec le bouton droit sur le nœud Références, sélectionnez Ajouter une référence, tapez system.identitymodel.services dans le champ Rechercher tous les assemblys et sélectionnez l'assembly correspondant dans la liste principale. Appuyez sur OK.

  3. Revenez au nouveau fichier SignOutController.cs. Ajoutez aux directives using les entrées suivantes :

    using System.IdentityModel.Services;
    using System.IdentityModel.Services.Configuration;
    
    Modifiez à présent l'implémentation de la classe SignOutController comme suit :

    public ActionResult Index()
    {
        return View("SignOut");
    }
    
    public void SignOut()
    {
         WsFederationConfiguration fc = 
                FederatedAuthentication.FederationConfiguration.WsFederationConfiguration;
    
         string request = System.Web.HttpContext.Current.Request.Url.ToString();
         string wreply = request.Substring(0, request.Length - 7);
    
         SignOutRequestMessage soMessage = 
                         new SignOutRequestMessage(new Uri(fc.Issuer), wreply);
         soMessage.SetParameter("wtrealm", fc.Realm);
    
         FederatedAuthentication.SessionAuthenticationModule.SignOut();
         Response.Redirect(soMessage.WriteQueryString());
    } 
    
    
    Voici une brève explication du code.

    • La première méthode, Index(), sert la demande du formulaire https://localhost:44341/SignOut. Il s'agit de l'adresse d'une vue que vous ajouterez par la suite dans la procédure pas à pas. Elle a pour but de signaler une déconnexion réussie, et nous l'utiliserons comme telle dans la méthode suivante.

    • La méthode SignOut() sert la demande du formulaire https://localhost:44341/SignOut/SignOut et contient la logique de déconnexion principale.

    • La première ligne récupère l'objet utilisé par WIF pour faire le suivi des paramètres WS-Federation dans le fichier web.config. Nous en aurons besoin pour élaborer un message de déconnexion adapté à l'application actuelle.

      noteRemarque
      Il est généralement conseillé de faire référence aux valeurs config plutôt que de recourir à des valeurs codées en dur ou de collecter ces valeurs à partir de référentiels personnalisés. De cette façon, votre code est évolutif et en adéquation avec le reste des paramètres de protocole. Par ailleurs, la logique continue de fonctionner, et ce quel que soit le nombre de fois que les paramètres sont modifiés dans le fichier config, avant et après le déploiement.

    • Les deuxième et troisième lignes créent l'adresse de retour qui sera utilisée par l'autorité à la fin du flux de déconnexion. Nous souhaitons que cette adresse pointe vers la vue mentionnée précédemment. Le code obtient donc l'URL de la demande actuelle et élimine la partie « SignOut » de fin. Le fait de dériver l'adresse à partir de la demande permet de garantir qu'elle sera résolue pour le client, alors que l'obtention de l'adresse à partir de la couche d'hébergement peut entraîner des problèmes de ports internes lors de l'utilisation d'un programme d'équilibrage de charge.

    • La quatrième ligne utilise WIF pour concevoir un message de déconnexion WS-Federation qui passe l'URL de l'autorité et l'adresse de retour définie dans la ligne précédente. Vous pouvez facilement créer le message directement sous sa forme de maquette ; toutefois, avec le modèle objet WIF, vous pourrez écrire du code plus concis et ignorer la plupart des détails de la syntaxe. Si vous souhaitez voir à quoi ressemble un message de déconnexion, assurez-vous de capturer une trace HTTP lorsque vous exécutez l'application dans une section ultérieure ou consultez la spécification ici.

    • La quatrième ligne ajoute l'identificateur de l'application actuelle au message, tel qu'enregistré dans l'attribut realm de l'élément de configuration <wsFederation>.

    • La cinquième ligne utilise le module SAM (décrit plus haut dans la description de l'élément config généré automatiquement) pour nettoyer la session locale. Il supprime notamment le cookie de session généré au moment de l'authentification et nettoie les ressources locales qui en ont besoin.

      noteRemarque
      L'exemple d'application présenté ici est limité, mais vos applications réelles peuvent allouer des ressources au cours d'une session utilisateur. Si tel est le cas, vous pouvez tirer parti des événements SigningOut et SignedOut du module SAM en ajoutant les gestionnaires d'événements correspondants dans le fichier Global.asax pour nettoyer les ressources appropriées après la fermeture d'une session.

La vue utilisée ici est très simple. Comme nous l'avons vu précédemment, elle vise essentiellement à créer un point de retour significatif pour le flux de déconnexion.

  1. Dans l'Explorateur de solutions, cliquez avec le bouton droit sur le nœud Vues et ajoutez un dossier SignOut.

  2. Dans ce dossier, ajoutez une vue en cliquant avec le bouton droit sur le dossier et en cliquant sur Ajouter, puis cliquez sur Vue. Appelez la nouvelle vue SignOut. Placez un code de présentation réservé dans le fichier View (SignOut.cshtml) pour signaler que la déconnexion a eu lieu. Par exemple :

    @{
        ViewBag.Title = "SignOut";
    }
    
    <h2>You have successfully signed out</h2>
    
  3. Comme vous vous en souvenez peut-être, nous avons, dans l'ancienne section, configuré l'application pour gérer l'authentification via des redirections globales (« blanket redirects »). Cela signifie que si nous essayons d'accéder à cette vue après une déconnexion réussie (comme nous sommes censés le faire), nous sommes immédiatement redirigés vers Azure AD pour nous reconnecter. Pour éviter ce comportement, vous pouvez utiliser l'élément <location> situé dans le fichier web.config pour créer une exception à la stratégie d'authentification.

    Recherchez la première occurrence de l'élément <system.web> puis, juste au-dessus de celui-ci, collez l'extrait de code suivant :

      <location path="SignOut">
        <system.web>
          <authorization>
            <allow users="*" />
          </authorization>
        </system.web>
      </location>
    
    
    Ce code indique à ASP.NET que le chemin d'accès SignOut est accessible à tous, y compris aux utilisateurs non authentifiés. Cette disposition vous permet d'afficher cette de vue dans le navigateur même si la déconnexion aboutit.

  1. À présent que la fonctionnalité de déconnexion est implémentée dans l'application, il nous reste à la rendre accessible à l'utilisateur. Pour cela, il existe un moyen très simple : Ouvrez _layout.cshtml dans le chemin Views\Shared de l'Explorateur de solutions. Recherchez la chaîne « Hello » pour localiser le code qui affiche les informations de connexion en haut de la disposition MVC 4 traditionnelle, puis modifiez la section de connexion comme suit :

    <section id="login">
      @if (Request.IsAuthenticated)
      {  
        <text> Hello, <span class="username">@User.Identity.Name</span>! 
      @Html.ActionLink("Signout","SignOut", "SignOut")</text>
      }
      else {
        <text>  You are not authenticated </text>
      }
    </section> 
    
    

Ce code ajoute une commande de déconnexion à droite du message de l'utilisateur connecté, ce qui lui permet de déclencher une action de déconnexion à partir de n'importe quelle vue.

L'outil Identity and Access Tool configure votre application de sorte qu'elle accepte les jetons en provenance du locataire Azure AD de votre choix. Pour ce faire, il met en cache, dans le fichier web.config, les coordonnées de protocole nécessaires pour établir une connexion aux points de terminaison Azure AD visés. Il enregistre par ailleurs les informations sur les clés utilisées au moment de l'authentification pour valider le fait que le jeton entrant provient bien de votre locataire Azure AD ; il se sert pour cela du nom de l'émetteur qui représente votre locataire et de la clé publique (sous forme d'un certificat X.509) pour vérifier la signature du jeton.

Pour des raisons de sécurité, il est pratique courante de renouveler régulièrement les clés de chiffrement, y compris les clés de signature Azure AD. À intervalles réguliers, les anciennes clés sont supprimées, et les nouvelles prennent leur place dans la logique de signature de l'émetteur et dans le document de métadonnées de votre locataire. En cas d'urgence, les clés peuvent être renouvelées hors cycle, avec ou sans avertissement.

À chaque substitution de clé, vos paramètres d'application doivent être modifiés en conséquence. Si vous avez suivi jusqu'à présent l'approche présentée dans cette procédure pas à pas, vous devez réexécuter l'outil pour lire le nouveau document de métadonnées et actualiser les entrées du fichier web.config.

Pour minimiser les temps d'arrêt, il est conseillé d'ajouter une logique d'auto-adaptation directement dans l'application afin que vous puissiez consommer le document de métadonnées par programme et réagir à la substitution de clé sans nécessiter l'intervention de l'opérateur. L'exemple ci-dessous illustre l'implémentation de cette fonctionnalité.

  1. Utilisez l'Explorateur de solutions, comme décrit précédemment dans le document, pour ajouter une référence à l'assembly System.IdentityModel.

  2. Ajoutez les directives using suivantes au fichier Global.asax :

    using System.Configuration;
    using System.IdentityModel.Tokens;
    
    
  3. Ensuite, ajoutez la méthode suivante au fichier Global.asax :

    //...
    protected void RefreshValidationSettings()
    {
        string configPath = AppDomain.CurrentDomain.BaseDirectory + "\\" + "Web.config";
        string metadataAddress = 
                      ConfigurationManager.AppSettings["ida:FederationMetadataLocation"];
        ValidatingIssuerNameRegistry.WriteToConfig(metadataAddress, configPath);
    }
    
    
    La logique employée ici est très simple. ValidatingIssuerNameRegistry est la classe utilisée par l'outil Identity and Access Tool pour enregistrer les informations sur les autorités approuvées et sur les clés à utiliser pour vérifier les jetons qu'elles émettent. WriteToConfig est une méthode statique qui lit les paramètres de l'émetteur dans un document de métadonnées (qui, dans ce cas, provient de config où il a été stocké lors de la première exécution de l'outil, par la deuxième ligne de la méthode). Elle s'en sert pour créer ou mettre à jour la section config correspondante du fichier dans le chemin d'accès spécifié (construit à partir du AppDomain actuel dans la première ligne de la méthode).

  4. Pour insérer RefreshValidationSettings() dans le cycle de vie de l'application, appelez-le à partir d'Application_Start() comme indiqué ci-dessous.

    protected void Application_Start()
    {
        AreaRegistration.RegisterAllAreas();
    
        WebApiConfig.Register(GlobalConfiguration.Configuration);
        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);
        RefreshValidationSettings();
    }
    
    Le fait d'appeler RefreshValidationSettings depuis Application_Start garantit que le fichier web.config est modifié au moment opportun. En effet, si l'opération a lieu plus tard dans le cycle de vie de l'application, vous risquez de déclencher une actualisation.

ImportantImportant
Vous devez aussi prendre quelques précautions supplémentaires au moment de l'actualisation automatique des clés de validation à partir de l'application. La principale menace qu'il vous appartient d'atténuer est l'accès non autorisé au système DNS. Cela se produit lorsqu'une personne malintentionnée utilise un programme malveillant pour vous diriger vers un document de métadonnées compromis et forcer votre application à approuver les mauvaises clés.

Si vous ne remplacez pas les valeurs .NET par défaut en matière de gestion des requêtes HTTP, le scénario ci-dessus est déjà atténué dans la mesure où les documents de métadonnées sont hébergés sur des points de terminaison HTTPS. Une tentative d'accès non autorisé au système DNS peut rediriger les demandes vers un point de terminaison malveillant, mais ce dernier ne sera pas validé par le serveur HTTPS. Comme elle n'est pas réellement propriétaire du domaine sur lequel les documents de métadonnées sont hébergés, la personne malintentionnée ne peut pas obtenir un certificat émis pour celui-ci. Le client peut donc détecter un problème avec le serveur et bloquer tout acheminement incorrect.

Parfois, certains scénarios de développement nécessitent la désactivation de la validation HTTPS (généralement via la classe ServicePoint). Si vous utilisez la logique d'actualisation automatique des métadonnées indiquée dans cette section, il est essentiel que vous restauriez les paramètres de validation HTTPS avant de déployer votre application en phase de production.

  1. Nous sommes enfin prêts à observer l'application en action. Appuyez sur F5. Le navigateur s'ouvre et tente d'accéder à l'URL spécifiée dans les paramètres du projet dans la section « Créer une application MVC ».

    Vous obtenez tout d'abord une erreur de certificat ; ce comportement est attendu. Cliquez sur Poursuivre sur ce site Web (non recommandé). S'il est acceptable d'ignorer cette erreur dans le cadre de cette procédure pas à pas, ne la négligez pas dans une application de production.

    CertificateError Si vous observez la barre d'adresses, vous pouvez apercevoir brièvement l'URL de l'application. Cependant, le module FAM devant l'application reconnaît immédiatement l'appel comme n'étant pas authentifié, détermine la procédure à suivre dans config et déclenche la redirection de la connexion vers Azure AD. L'URL dans la barre d'adresses est remplacée par celle de l'autorité, et l'utilisateur est invité à s'authentifier via l'interface utilisateur d'Azure AD.

    noteRemarque
    Le nouveau compte d'utilisateur créé précédemment ne peut pas être utilisé pour gérer votre abonnement Azure si vous vous êtes initialement connecté au portail de gestion à l'aide d'un compte Microsoft. Si vous tentez de revenir au portail de gestion après vous être connecté à l'application en tant que nouvel utilisateur, un message d'erreur s'affiche. Pour remédier à ce problème, vous devez vous connecter au portail de gestion à l'aide du compte que vous avez utilisé pour créer votre locataire d'annuaire. Si vous vous êtes initialement connecté au portail de gestion à l'aide d'un compte Azure AD et que le rôle Administrateur général a été affecté au nouvel utilisateur, ce dernier peut gérer votre abonnement Azure.

    Se connecter à AAD
  2. Entrez les informations d'identification de l'utilisateur que vous avez créé dans votre locataire Azure dans la première section de la procédure pas à pas. Appuyez sur le bouton Se connecter.

    Lorsque vous avez créé l'utilisateur dans votre locataire Azure AD, vous vous souvenez peut-être que le portail de gestion lui a affecté à un mot de passe temporaire. Vous devez vous authentifier à l'aide de ce mot de passe. Toutefois, comme ce mot de passe est temporaire, vous êtes invité lors de votre première opération de connexion à choisir un mot de passe utilisateur approprié avant de poursuivre le flux de l'authentification. Après cela, le flux standard de connexion à l'application est rétabli.

    Page d'accueil de l'application Au cours de la procédure d'authentification, WIF traite les revendications du jeton d'authentification entrant, lesquelles sont ensuite utilisées par le code d'affichage simple que nous avons ajouté dans le contrôleur de la page d'accueil. Vous pouvez à présent naviguer dans le site sans devoir vous authentifier à nouveau, chaque publication (postback) contient le cookie de session géré par le module SAM.

  3. Pour voir ce qui se passe au terme de la session, cliquez sur le lien de déconnexion dans le coin supérieur droit. Vous pouvez observer les redirections que nous avons codées précédemment et qui doivent aboutir à la vue ci-dessous.

    Se déconnecter Pour vérifier que vous êtes bien déconnecté, cliquez sur n'importe quel autre élément de l'interface utilisateur. Le cycle d'authentification doit redémarrer.

La partie « procédure pas à pas » du document vous a montré les étapes essentielles à effectuer pour ajouter une procédure d'authentification web à votre application web. Le reste du document va au-delà des concepts de base et décrit plus en détail certains points clés. Il couvre aussi d'autres tâches que vous devrez accomplir pour faire passer votre application au niveau supérieur.

Dans cette section, vous allez apprendre à modifier les paramètres de votre application pour la déployer et l'exécuter dans les sites web Azure. L'application est en grande partie inchangée ; vous devez simplement veiller à tenir compte de la nouvelle adresse et de la gestion des sessions de votre application.

Cette partie du document implique que vous disposiez d'un site web Azure à cibler pour effectuer le déploiement de votre application. Si vous possédez déjà un site web, vous pouvez l'utiliser ; sinon, consultez ce document pour découvrir comment créer et publier un site web Azure. Si vous suivez le didacticiel contenu dans ce document, arrêtez-vous juste après le téléchargement du profil de publication, car nous devons procéder à quelques ajustements avant de déployer l'application.

Ajuster les paramètres de l'application dans le portail de gestion Azure

Comme nous l'avons vu dans la section portant sur l'inscription de l'application, le paramètre de clé définissant votre application dans l'interface utilisateur Azure AD correspond à l'URL de l'application. Jusqu'à présent, la procédure pas à pas partait du principe que l'application était hébergée dans l'environnement local IIS Express. Toutefois, en raison du déploiement vers les sites web Azure, l'URL de l'application va être modifiée et les paramètres dans Azure AD devront refléter ce changement.

  1. Revenez au portail de gestion, puis sélectionnez l'onglet Active Directory à gauche. Cliquez sur votre locataire d'annuaire, sélectionnez l'en-tête Applications, puis cliquez sur l'entrée correspondant à l'application. Cliquez sur l'en-tête Configurer pour accéder à un écran vous permettant de modifier les paramètres de l'application que vous avez entrés au moment de la création. Pour les besoins de ce didacticiel, ignorez les zones supérieures de l'écran et faites défiler ce dernier jusqu'à la section consacrée à l'authentification unique.

    Authentification unique
  2. Dans la zone de texte URL DE RÉPONSE, entrez l'adresse de votre site web Azure cible (par exemple, https://aadga.windowsazure.net/). Cela permet à Azure AD de retourner les jetons à l'emplacement de votre site web Azure au terme d'une authentification réussie (et non pas à l'emplacement utilisé plus tôt au moment du développement). Après avoir mis à jour la valeur, appuyez sur ENREGISTRER dans la barre de commandes située en bas de l'écran.

noteRemarque
Vous avez peut-être remarqué que l'URI ID D'APPLICATION utilise toujours la valeur basée sur localhost que vous avez créée précédemment dans le document.

Techniquement, tant que l'identificateur est au format URI et qu'il est unique dans toutes les applications du locataire d'annuaire actuel, la valeur affectée au type d'application dont il est question ici n'a pas d'importance. C'est pourquoi les instructions ne mentionnent pas la mise à jour de cette valeur.

Toutefois, dans le but d'améliorer la gestion, vous pouvez modifier l'URI ID D'APPLICATION afin de transporter une valeur qui est plus représentative de votre application. Un exemple type est une dérivée de la valeur de l'URL de réponse.

Notez que si vous modifiez la valeur de l'URI ID D'APPLICATION, vous devrez apporter des changements plus importants à l'application avant de la déployer. Nous verrons ceci plus en détail par la suite.

Préparer l'application en vue de son exécution dans les sites web Azure

Dans l'essentiel, la configuration de l'authentification web est prête pour le cloud. Il n'y a qu'une seule modification à apporter, celle-ci étant due en grande partie aux fonctionnalités des sites web Azure.

Le processus d'authentification web entraîne la création d'un cookie de session qui est envoyé à chaque demande d'authentification. Le cookie de session, créé par l'intergiciel (middleware) WIF, est signé et chiffré par défaut via DPAPI (pour plus d'informations, consultez ce document). Cela permet d'éviter les abus du client, comme la modification de la liste des revendications dans le but d'élever les privilèges. Cependant, comme les paramètres IIS dans les sites web Azure empêchent l'utilisation de DPAPI pour protéger les sessions, vous devez changer la manière dont WIF sécurise le cookie associé. Le .NET Framework 4.5 offre une solution de remplacement prête à l'emploi, qui s'appuie sur la méthode MachineKey (consultez la documentation ici) et qui fonctionne sans problème dans les sites web Azure.

L'outil Identity and Access Tool facilite grandement cette modification.

  1. Cliquez avec le bouton droit sur le projet dans l'Explorateur de solutions, choisissez Identité et accès, puis sélectionnez l'onglet Configuration. Vous devriez voir une boîte de dialogue qui s'apparente à la capture d'écran suivante :

    Identité et accès dans les sites web Azure
  2. Activez simplement la case à cocher Activer les cookies compatibles avec les batteries de serveurs Web, puis appuyez sur OK. L'outil se charge d'ajouter les éléments nécessaires au fichier web.config (dans la pratique, remplacez la classe par défaut SessionSecurityTokenHandler par MachineKeySessionSecurityTokenHandler) pour sélectionner MachineKey comme méthode de protection des cookies.

    noteRemarque
    Si, lors de l'étape précédente, vous avez modifié l'URI ID D'APPLICATION dans le portail de gestion Azure, vous pouvez utiliser cette interface utilisateur pour appliquer rapidement ces modifications à votre projet. Collez simplement la valeur de l'URI ID D'APPLICATION dans les deux champs de texte dans la partie supérieure, puis cliquez sur OK. L'outil appliquera les modifications nécessaires aux bons endroits dans le fichier config.

    Vous pouvez éventuellement songer à désactiver temporairement les messages d'erreur personnalisés ASP.NET. Pour cela, ajoutez l'entrée <customErrors mode="Off" /> dans la section <system.web> du fichier web.config. Cela peut vous aider à résoudre certains problèmes susceptibles de se produire au moment du déploiement. Veillez toutefois à activer de nouveau ces messages avant de passer en phase de production ; en effet, des personnes malintentionnées pourraient exploiter les messages d'erreur détaillés pour tenter d'identifier d'éventuelles ouvertures dans votre application. customError empêche que cela ne se produise.

La préparation de votre application est terminée. Vous pouvez désormais l'exécuter en tant que site web Azure. Utilisez vos paramètres de publication pour déployer l'application, ouvrez un navigateur, puis accédez à l'adresse azurewebsite.net de votre application. Suivez ensuite le même flux que celui abordé dans la section portant sur le test de l'application de la procédure pas à pas. Toute la logique personnalisée étant conçue indépendamment de l'emplacement, vous pouvez effectuer les mêmes opérations que celles réalisées au niveau local.

L'outil Identity and Access Tool génère automatiquement les paramètres de configuration nécessaires à l'intégration de votre application au locataire Azure AD via WS-Federation. Dans l'idéal, vous ne verrez jamais ces paramètres. Toutefois, dans certains cas, vous pourrez en avoir besoin pour modifier le comportement par défaut ou résoudre un problème. Il peut donc être utile de savoir se repérer au milieu des paramètres de configuration WIF.

Les classes WIF et la méthode utilisée dans le flux de connexion web sont entièrement documentées dans MSDN. Ici, nous allons examiner une version annotée du fichier web.config une fois celui-ci modifié par l'outil Identity and Access Tool. Pour vous faciliter la tâche, nous avons également inclus les modifications provenant de la section sur la publication vers les sites web Azure.

noteRemarque
Par souci de clarté, le document comprend la source Web.config dans son intégralité ; toutefois, seules les sections pertinentes à WIF sont annotées.

<?xml version="1.0" encoding="utf-8"?>
<!--
  For more information on how to configure your ASP.NET application, please visit
  http://go.microsoft.com/fwlink/?LinkId=169433
  -->
<configuration>
  <configSections>
    <!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468 -->
    <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />

Aucun commentaire sur la configuration ci-dessus.

<section name="system.identityModel" type="System.IdentityModel.Configuration.SystemIdentityModelSection, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
    <section name="system.identityModel.services" type="System.IdentityModel.Services.Configuration.SystemIdentityModelServicesSection, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />

Dans la configuration ci-dessus, cette zone charge les classes dont ASP.NET a besoin pour lire et interpréter les sections de configuration utilisées par WIF afin de modéliser les paramètres de flux et d'authentification WS-Federation.

  </configSections>
  <appSettings>
    <add key="webpages:Version" value="2.0.0.0" />
    <add key="webpages:Enabled" value="false" />
    <add key="PreserveLoginUrl" value="true" />
    <add key="ClientValidationEnabled" value="true" />
    <add key="UnobtrusiveJavaScriptEnabled" value="true" />

Aucun commentaire sur la configuration ci-dessus.

    <add key="ida:FederationMetadataLocation" value="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/federationmetadata/2007-06/federationmetadata.xml" />
    <add key="ida:Issuer" value="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/wsfed" />
    <add key="ida:ProviderSelection" value="productionSTS" />
  </appSettings>

Dans la configuration ci-dessus, les entrées appSettings sont capturées par l'outil Identity and Access Tool pour faire le suivi des paramètres importants (comme l'adresse du document de métadonnées que nous avons utilisée dans la section de substitution de clé) qui ne sont enregistrés nulle part ailleurs.

  <location path="FederationMetadata">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>
  <location path="SignOut">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>

Dans la configuration ci-dessus, ces deux éléments <location> définissent deux zones dans l'application web qui sont accessibles sans conditions d'authentification (voir ci-dessous). La section FederationMetadata est créée par l'outil Identity and Access Tool ; ce dernier crée un document de métadonnées décrivant l'application, document qui peut être utilisé par les autorités pour déployer l'application. Vous avez ajouté la section SignOut dans le cadre de l'implémentation de la déconnexion web.

  <system.web>
    <authentication mode="None" />
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" requestValidationMode="4.5" />
    <!--Commented by Identity and Access VS Package-->
    <!--<authentication mode="Windows" />-->
    <authorization>
      <deny users="?" />
    </authorization>

Dans la configuration ci-dessus, l'outil Identity and Access Tool définit par défaut les paramètres d'authentification et d'autorisation ASP.NET de telle sorte que chaque partie de l'application web (sauf exceptions ci-dessus) exige l'authentification des utilisateurs avant de servir des demandes. Si cette approche convient généralement aux applications métiers, il arrive que les développeurs conservent des zones accessibles de façon anonyme. Si cela vous concerne, modifiez les paramètres en conséquence.

    <pages>
      <namespaces>
        <add namespace="System.Web.Helpers" />
        <add namespace="System.Web.Mvc" />
        <add namespace="System.Web.Mvc.Ajax" />
        <add namespace="System.Web.Mvc.Html" />
        <add namespace="System.Web.Optimization" />
        <add namespace="System.Web.Routing" />
        <add namespace="System.Web.WebPages" />
      </namespaces>
    </pages>
    <customErrors mode="Off" />
    <machineKey decryptionKey="998D0533DD570FDCA86A945893F0B2BFC0E1F3645E148F35" validationKey="E739C2EA4B4470820308DA71D81160F22C0D9CD3C97709CB0679E55FDCC2D35B35563D56102F254FB4908644ECB53B3898948F54AAC4A5F0C44754A5A997B79A" />
  </system.web>
  <system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <handlers>
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers>

Aucun commentaire sur la configuration ci-dessus.

    <modules>
      <remove name="FormsAuthentication" />
      <add name="WSFederationAuthenticationModule" type="System.IdentityModel.Services.WSFederationAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
      <add name="SessionAuthenticationModule" type="System.IdentityModel.Services.SessionAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="managedHandler" />
    </modules>
  </system.webServer>

Dans la configuration ci-dessus, les entrées de cette section insèrent dans le pipeline SP.NET les modules HTTPModule qui implémentent les principales fonctionnalités de gestion des protocoles et des sessions. Le module WSFederationAuthenticationModule (FAM) met en œuvre le protocole WS-Federation en validant les jetons entrants et en générant des messages d'authentification à l'autorité conformément aux spécifications du protocole. Le module SessionAuthenticationModule (SAM) crée et valide les cookies de session, en accord avec le module FAM.

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="WebGrease" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-1.3.0.0" newVersion="1.3.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
  <entityFramework>
    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework">
      <parameters>
        <parameter value="v11.0" />
      </parameters>
    </defaultConnectionFactory>
  </entityFramework>

Aucun commentaire sur la configuration ci-dessus.

  <system.identityModel>
    <identityConfiguration>
      <audienceUris>
        <add value="https://localhost:44342/ShiungZZZ" />
      </audienceUris>

Dans la configuration ci-dessus, <system.identityModel> inclut dans un wrapper tous les paramètres spécifiques aux classes WIF. Son premier élément enfant, IdentityConfiguration, fournit une description indépendante du protocole sur le comportement de l'application. La liste AudienceUris fournit toutes les valeurs considérées par WIF comme des étendues acceptables dans les jetons entrants pour les applications actuelles ; en général, celles-ci correspondent au domaine de l'application (ou URI ID D'APPLICATION dans le langage Azure AD). Un jeton entrant doit déclarer que son destinataire souhaité est l'une des valeurs répertoriées ici ; sinon, WIF estime qu'il s'agit d'un jeton volé et refuse l'appel.

           
      <issuerNameRegistry type="System.IdentityModel.Tokens.ValidatingIssuerNameRegistry, System.IdentityModel.Tokens.ValidatingIssuerNameRegistry">
        <authority name="https://sts.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/">
          <keys>
            <add thumbprint="3A38FA984E8560F19AADC9F86FE9594BB6AD049B" />
          </keys>
          <validIssuers>
            <add name="https://sts.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/" />
          </validIssuers>
        </authority>
      </issuerNameRegistry>

Dans la configuration ci-dessus, l'élément ValidatingIssuerNameRegistry contient la liste des tuples nom d'émetteur-clé de vérification de signature acceptables. Dans cette procédure pas à pas, les paramètres reflètent les valeurs associées à votre locataire Azure AD. Cet élément garantit qu'aucun autre émetteur, y compris les autres locataires Azure AD appartenant à d'autres sociétés, ne peut accéder à votre application.

<certificateValidation certificateValidationMode="None">
      </certificateValidation>

Dans la configuration ci-dessus, cet élément désactive la validation de certificat dans le pipeline WIF. Cette mesure est nécessaire dans Azure AD du fait de l'utilisation d'un certificat auto-signé. Sauf en cas d'installation du certificat dans le magasin de certificats local, toute opération de validation de chaîne ou d'homologue se traduirait pas un échec. Notez que cela n'affaiblit pas vraiment la sécurité de l'authentification Azure AD, dans la mesure où ValidatingIssuerNameRegistry garantit que le certificat approprié est utilisé. Toutefois, si vous utilisez WIF dans une même application pour approuver d'autres émetteurs, sachez que ces paramètres s'appliquent aussi à ces émetteurs.

      <securityTokenHandlers>
        <add type="System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
        <remove type="System.IdentityModel.Tokens.SessionSecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
      </securityTokenHandlers>
    </identityConfiguration>

Cette section vous permet de manipuler la collection de classes utilisées par WIF pour traiter des jetons de sécurité entrants (les soi-disant gestionnaires de jetons). Vous pouvez vous en servir pour influencer le comportement des gestionnaires individuels ou pour ajouter et supprimer des types de gestionnaire. Dans ce cas, l'outil supprime le gestionnaire de session par défaut (qui est basé sur DPAPI et qui ne peut pas fonctionner dans les sites web Azure) et le remplace par un gestionnaire compatible avec MachineKey.

  </system.identityModel>
  <system.identityModel.services>
    <federationConfiguration>
      <cookieHandler requireSsl="false" />
      <wsFederation passiveRedirectEnabled="true" issuer="https://login.windows.net/ec4187af-07da-4f01-b18f-64c2f5abecea/wsfed" realm="https://localhost:44342/ExpenseReport" requireHttps="false" />
    </federationConfiguration>
  </system.identityModel.services>
</configuration>

Dans la configuration ci-dessus, <system.identityModel.services> est utilisé pour stocker les coordonnées propres à WS-Federation.

En particulier, l'élément wsFederation est utilisé ici pour enregistrer le point de terminaison d'authentification WS-Federation de votre locataire Azure AD, le domaine (URI ID D'APPLICATION) de l'application à envoyer en tant qu'identificateur au moment de l'authentification, ainsi que d'autres indicateurs qui influencent le comportement local de WIF. Ces indicateurs déterminent notamment si les erreurs 401 déclenchent toujours un message de connexion à l'autorité (passiveRedirectEnabled) ou si les transactions réalisées sur une connexion HTTP non protégée sont autorisées.

Vous pouvez utiliser cet élément pour spécifier d'autres paramètres de protocole ; ceux présentés ici constituent simplement le minimum absolu pour faire fonctionner le flux d'authentification.

Ce document porte sur une tâche somme toute assez limitée, qui consiste à connecter une application .NET à Azure AD pour exécuter une procédure d'authentification web via WS-Federation. Bien d'autres scénarios sont envisageables. Vous pouvez notamment utiliser différents protocoles ouverts, tirer parti d'une pile de programmation quelconque sur n'importe quelle plateforme moderne ou encore travailler directement au niveau du protocole sur le réseau.

Dans la section sur le déploiement de l'application dans Azure, vous avez vu que le portail de gestion vous offre la possibilité de modifier bien d'autres aspects liés aux paramètres d'inscription de votre application. Vous aborderez la plupart de ces contrôles supplémentaires dans la prochaine procédure pas à pas de cette série. Ici, nous allons simplement mentionner comment obtenir les informations nécessaires si vous choisissez d'interagir avec Azure AD au niveau du protocole, pour l'authentification web ou tout autre flux pris en charge.

  1. Ouvrez le portail de gestion Azure dans une fenêtre de navigateur, puis accédez à l'en-tête Applications dans la section Azure AD. Notez que la barre de commandes en bas de l'écran contient une entrée : Afficher les points de terminaison. Cliquez dessus.

    Points de terminaison La boîte de dialogue répertorie tous les points de terminaison que vous pouvez utiliser pour interagir par programme avec votre locataire Azure AD. Voici une brève explication des entrées de la boîte de dialogue :

    • Document de métadonnées de fédération : emplacement du document de métadonnées décrivant le locataire Azure AD en tant qu'autorité d'authentification web. Comme vous l'avez vu dans la procédure pas à pas dans la section sur l'actualisation automatique des clés, ce document contient les coordonnées des métadonnées WS-Federation, ainsi que les métadonnées du protocole SAML dans le même package. Pour plus d'informations, consultez Métadonnées de fédération.

    • Point de terminaison de connexion WS-Federation : point d'entrée de toutes les transactions WS-Federation. Il s'agit du point de terminaison que vous avez utilisé dans la procédure pas à pas pour les flux de connexion et de déconnexion. Pour plus d'informations, consultez WS-Federation Endpoint URL.

    • Point de terminaison de connexion SAML-P : point de terminaison utilisé pour implémenter les flux de connexion dans le protocole SAML. Pour plus d'informations, consultez Métadonnées et points de terminaison du protocole SAML.

    • Point de terminaison de déconnexion SAML-P : point de terminaison utilisé pour implémenter les flux de déconnexion dans le protocole SAML. Pour plus d'informations, consultez Métadonnées et points de terminaison du protocole SAML.

    • Point de terminaison API graphique Azure AD : les requêtes visant à récupérer les informations sur l'annuaire stockées dans le locataire Azure AD doivent être acheminées vers ce point de terminaison à l'aide de la syntaxe de l'API graphique. Pour plus d'informations, consultez Utilisation de l'API Graph pour interroger Azure AD.

    • Point de terminaison de jeton OAuth 2.0 : ce point de terminaison est utilisé pour les flux d'authentification de serveur à serveur. Par exemple, il peut être utilisé pour obtenir des jetons d'accès pour appeler le point de terminaison graphique. Pour plus d'informations, consultez OAuth 2.0 (Preview Version).

Ajouts de la communauté

Afficher:
© 2015 Microsoft