Présentation et débogage du flux du service Broker d’authentification web (HTML)

  • Article

[ Cet article est destiné aux développeurs de Windows 8.x et Windows Phone 8.x qui créent des applications Windows Runtime. Si vous développez une application pour Windows 10, voir la Documentation ]

Vous pouvez utiliser le service Broker d’authentification Web pour activer l’authentification unique pour vos utilisateurs et les authentifier de façon transparente auprès d’un même service dans plusieurs applications du Windows Store. Le service Broker d’authentification Web prenant en charge les protocoles d’authentification Internet OAuth et OpenID, vous pouvez intégrer votre application à un service Web qui authentifie les utilisateurs. Vous pouvez alors utiliser les identités d’utilisateur provenant de services tels que Facebook, Flickr, Google et Twitter dans vos applications.

Lorsqu’une application appelle le service Broker d’authentification Web, l’utilisateur se voit présenter une boîte de dialogue dans laquelle les pages Web nécessaires sont affichées pour la connexion. Le fournisseur de ce service doit autoriser l’utilisateur à approuver explicitement cette authentification, généralement en proposant une option Maintenir la connexion. Il doit aussi clairement préciser aux utilisateurs la manière dont leur identité est utilisée. Un lien vers une déclaration de confidentialité sur la page de connexion est le moyen généralement employé dans ce cas. Une fois que l’utilisateur a effectué ces étapes, la boîte de dialogue disparaît et l’utilisateur retrouve l’application.

Le diagramme suivant montre un exemple de boîte de dialogue modale.

Exemple de boîte de dialogue d’authentification d’utilisateur

Avantages liés à l’utilisation du service Broker d’authentification Web

Le service Broker d’authentification Web fournit les avantages suivants :

  • une interface utilisateur conviviale qui dispense le développeur d’applications d’héberger un contrôle de navigateur dans ses propres applications ;
  • l’intégration de la page web d’un fournisseur à une interface utilisateur Windows 8. Pour plus d’informations sur les fournisseurs en ligne, voir Service Broker d’authentification Web pour les fournisseurs en ligne ;
  • des informations d’identification utilisateur isolées de votre application ;
  • une prise en charge native de l’authentification unique auprès des fournisseurs en ligne.

Fonctionnement du service Broker d’authentification Web

Le service Broker d’authentification Web fait office d’intermédiaire ou de médiateur entre votre application et votre service d’authentification. Il se compose d’un ensemble d’API, d’un service Broker et d’un hôte Web. Votre application utilise les API pour communiquer avec le service Broker. Le service Broker créer un processus hôte Web dans un conteneur d’application distinct. Le service Broker communique avec l’application, assemble l’interface utilisateur et contrôle le cycle de vie de l’hôte d’authentification Web. L’hôte d’authentification Web affiche les pages du site Web du fournisseur en ligne d’authentification.

Le diagramme suivant présente le flux d’informations dans le cadre de l’utilisation du service Broker d’authentification Web.

Flux de données pour le service Broker d’authentification Web

Le flux type d’utilisation du service Broker d’authentification Web est le suivant :

  1. 1. Votre application appelle le service Broker d’authentification Web à l’aide de la méthode WebAuthenticationBroker.AuthenticateAsync. Vous fournissez un URI de demande de départ et un URI de rappel lorsque l’appel d’authentification est terminé. Ceux-ci correspondent à un URI de point de terminaison d’autorisation et à un URI de redirection dans le protocole OAuth 2.0. Le protocole OpenID et les versions antérieures d’OAuth ont des concepts similaires.
  2. Le service Broker crée une boîte de dialogue système qui est modale pour l’application appelante.
  3. Le service Broker sélectionne un conteneur d’application dédié distinct de l’application appelante ou de toute autre application du système et efface les cookies persistants. Remarque  Ce conteneur d’application n’est jamais partagé simultanément par deux applications, à moins que le service Broker ait été démarré en mode Authentification unique (SSO).  
  4. Le service Broker démarre l’hôte d’authentification Web dans le conteneur d’application sélectionné.
  5. Le service Broker joint la fenêtre de l’hôte à la boîte de dialogue qu’il a créée précédemment. La fenêtre de l’hôte est responsable de l’affichage du contenu Web.
  6. L’hôte d’authentification Web accède à l’URI de la demande. Il s’agit généralement d’une page de connexion.
  7. Pendant que l’utilisateur interagit avec le site Web du fournisseur en ligne en cliquant sur des liens ou en soumettant des informations, l’hôte vérifie chaque URI pour déterminer s’il correspond à un URI de rappel fourni par l’application avant d’y accéder.
  8. Si une correspondance est trouvée, l’hôte met fin à la navigation et envoie un signal au service Broker.
  9. Le service Broker fait disparaître la boîte de dialogue, efface du conteneur d’application les cookies persistants créés par l’hôte, puis renvoie les données de protocole à l’application.

Fonctionnement de l’authentification unique du service Broker d’authentification Web

Le service Broker d’authentification Web active l’authentification unique (SSO) en autorisant les cookies persistants à demeurer dans un conteneur d’application SSO à fonctionnalité spécifique. Pour utiliser ce conteneur, votre application peut appeler la surcharge de la méthode AuthenticateAsync qui n’accepte pas d’URI de rappel. L’URL de redirection de départ doit être au format « ms-app://<SID> », où <SID> correspond au SID du package appelant. Vous pouvez ensuite inscrire le SID de chacune de vos applications auprès du service d’authentification en tant qu’URL de redirection valide (aussi appelé « point de terminaison de redirection »).

Par exemple, Fabrikam est le développeur d’une application du Windows Store qui utilise les services de Contoso. Au moment du développement, Fabrikam a inscrit son application auprès du Centre de développement Windows, suite à quoi elle a reçu un SID unique. Ensuite, Fabrikam a inscrit ses SID d’application en tant qu’URL de redirection valides auprès du service d’authentification Contoso.com. Fabrikam a inscrit deux de ses SID en tant qu’URL de redirection, l’une d’elles étant « ms-app://S-1-5-4321 ».

Au moment de l’exécution, l’application du Windows Store de Fabrikam appelle le service Broker d’authentification Web en mode SSO. Dans le cadre du traitement de la demande, Contoso.com vérifie que l’URL de redirection est présente dans l’ensemble des URL inscrites. Une fois que Contoso a authentifié l’utilisateur, une redirection est effectuée vers l’URL de redirection à laquelle a été ajouté un jeton d’accès : « ms-app://S-1-5-4321?token=ABC ». Lorsque le service Broker d’authentification Web rencontre une URL de ce format correspondant au SID de l’application appelante, il retourne le jeton contenu dans la chaîne de requête ou publie les données dans l’application.

Si des cookies ont déjà créés dans le conteneur d’application SSO, l’utilisateur n’a pas besoin de se connecter à Contoso. Toute tentative d’emprunt d’identité de l’application de Fabrikam par une autre application échoue, car Contoso vérifie l’identité de l’application en s’assurant que l’application demandée fait partie des URL de redirection déjà inscrites et le service Broker d’authentification Web s’assure que seule l’application qui partage le même SID qu’une application vers laquelle Contoso veut effectuer une redirection obtient les données de protocole.

Résolution des problèmes du service Broker d’authentification Web

Il existe plusieurs façons de résoudre les problèmes liés aux API du service Broker d’authentification Web pour votre application. Vous pouvez notamment examiner les journaux des opérations ou bien passer en revue les demandes et réponses Web avec Fiddler.

Journaux des opérations

Il est souvent possible de déterminer ce qui ne fonctionne pas à l’aide des journaux des opérations. Il existe un canal du journal des événements dédié, Microsoft-Windows-WebAuth\Operational, qui permet aux développeurs de sites Web de comprendre comment leurs pages Web sont traitées par le service Broker d’authentification Web. Pour l’activer, lancez eventvwr.exe et activez le journal Opérationnel sous Application and Services\Microsoft\Windows\WebAuth. Le service Broker d’authentification Web ajoute également une chaîne unique à la chaîne de l’agent utilisateur pour s’identifier sur le serveur Web. Cette chaîne est "MSAuthHost/1.0". Notez que le numéro de version peut changer dans le futur. Vous ne devez donc pas nécessairement utiliser ce numéro de version dans votre code. Voici un exemple de chaîne de l’agent utilisateur complète :

User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Win64; x64; Trident/6.0; MSAuthHost/1.0)

Exemple d’utilisation de journaux opérationnels

  1. Activer les journaux opérationnels
  2. Exécuter l’application sociale Contoso Observateur d’événements affichant les journaux opérationnels WebAuth
  3. Les entrées des journaux générés peuvent être utilisées pour comprendre le comportement du service Broker d’authentification Web plus en détail. Dans ce cas, ces entrées peuvent être les suivantes :
    • Début de la navigation : consigne le moment où AuthHost démarre, et contient des informations sur les URL de démarrage et de terminaison.
    • Illustration des détails de la section Début de la navigation
    • Achèvement de la navigation : consigne l’achèvement du chargement d’une page Web.
    • Balise META : consigne le moment où une balise META est rencontrée, y compris les détails.
    • Arrêt de la navigation : navigation arrêtée par l’utilisateur.
    • Erreur de navigation : AuthHost rencontre une erreur de navigation au niveau d’une URL incluant HttpStatusCode.
    • Fin de la navigation : une URL de terminaison est rencontrée.

Utilisation de Fiddler avec le service Broker d’authentification Web

Le débogueur web Fiddler peut être utilisé avec des applications Windows 8.

  1. Étant donné qu’AuthHost s’exécute dans son propre conteneur d’application pour lui donner la fonctionnalité réseau privé, vous devez définir une clé de Registre : Windows Registry Editor Version 5.00

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\authhost.exe\EnablePrivateNetwork = 00000001

    •                      Data type
                           DWORD

  2. Ajoutez une règle pour AuthHost, car c’est ce qui génère le trafic sortant.

    CheckNetIsolation.exe LoopbackExempt -a -n=microsoft.windows.authhost.a.p_8wekyb3d8bbwe
CheckNetIsolation.exe LoopbackExempt -a -n=microsoft.windows.authhost.sso.p_8wekyb3d8bbwe
CheckNetIsolation.exe LoopbackExempt -a -n=microsoft.windows.authhost.sso.c_8wekyb3d8bbwe
D:\Windows\System32>CheckNetIsolation.exe LoopbackExempt -s
List Loopback Exempted AppContainers
[1] -----------------------------------------------------------------
    Name: microsoft.windows.authhost.sso.c_8wekyb3d8bbwe
    SID:  S-1-15-2-1973105767-3975693666-32999980-3747492175-1074076486-3102532000-500629349
[2] -----------------------------------------------------------------
    Name: microsoft.windows.authhost.sso.p_8wekyb3d8bbwe
    SID:  S-1-15-2-166260-4150837609-3669066492-3071230600-3743290616-3683681078-2492089544
[3] -----------------------------------------------------------------
    Name: microsoft.windows.authhost.a.p_8wekyb3d8bbwe
    SID:  S-1-15-2-3506084497-1208594716-3384433646-2514033508-1838198150-1980605558-3480344935

  3. Ajoutez une règle de pare-feu pour le trafic entrant vers Fiddler.

Pour plus d’informations, voir le blog sur l’utilisation du débogueur Web Fiddler avec des applications du Windows Store.

Rubriques associées

Service Broker d’authentification Web pour les fournisseurs en ligne

Exemple de service Broker d’authentification Web

Windows.Security.Authentication.Web