Freigeben über


Grundlegendes zum Workflow des Webauthentifizierungsbrokers und Debuggen dieses Workflows (HTML)

[ Dieser Artikel richtet sich an Windows 8.x- und Windows Phone 8.x-Entwickler, die Windows-Runtime-Apps schreiben. Wenn Sie für Windows 10 entwickeln, finden Sie weitere Informationen unter neueste Dokumentation]

Sie können den Webauthentifizierungsbroker verwenden, um für Benutzer das einmalige Anmelden (Single Sign-On, SSO) zu ermöglichen und eine nahtlose Authentifizierung bei einem Dienst für mehrere Windows Store-Apps zu erreichen. Der Webauthentifizierungsbroker unterstützt die Internetauthentifizierungsprotokolle OAuth und OpenID, sodass Sie Ihre App in einen Webdienst integrieren können, der Benutzerauthentifizierung bereitstellt. Dies ermöglicht die Nutzung der Benutzeridentität in Ihren Apps durch Dienste wie Facebook, Flickr, Google und Twitter.

Wenn eine App den Webauthentifizierungsbroker aufruft, wird dem Benutzer ein Dialogfeld angezeigt, in dem die für die Anmeldung erforderlichen Webseiten gerendert werden. Der Anbieter des Diensts muss dem Benutzer die Möglichkeit geben, dieser Authentifizierung explizit zuzustimmen. In der Regel wird dazu eine Option wie "Angemeldet bleiben" verwendet. Außerdem muss der Anbieter unmissverständlich erläutern, wie die Identität des Benutzers verwendet wird. Zu diesem Zweck wird meist ein Link zu den Datenschutzbestimmungen auf der Anmeldeseite bereitgestellt. Nachdem der Benutzer die entsprechenden Schritte ausgeführt hat, wird das Dialogfeld geschlossen, und der Benutzer kann mit der Verwendung der App fortfahren.

Das folgende Diagramm zeigt einen modalen Beispieldialog.

Beispieldialogfeld für die Benutzerauthentifizierung

Vorteile des Webauthentifizierungsbrokers

Der Webauthentifizierungsbroker bietet die folgenden Vorteile:

  • Eine leicht zu bedienende Programmieroberfläche, die den App-Entwickler vom Zwang befreit, ein Browsersteuerelement in der eigenen App hosten zu müssen.
  • Integration einer Webseite eines Anbieters mit einer Windows 8-Benutzeroberfläche. Weitere Informationen zu Onlineanbietern finden Sie unter Webauthentifizierungsbroker für Onlineanbieter.
  • Benutzeranmeldeinformationen, die von der App isoliert sind.
  • Native Unterstützung für einmaliges Anmelden mit Onlineanbietern.

Funktionsweise des Webauthentifizierungsbrokers

Der Webauthentifizierungsbroker ist der Broker oder Vermittler zwischen Ihrer App und Ihrem Authentifizierungsdienst. Er besteht aus einem API-Satz, einem Broker und einem Webhost. Ihre App verwendet die APIs zur Kommunikation mit dem Broker. Der Broker erstellt einen neuen Webhostprozess in einem separaten App-Container. Der Broker kommuniziert mit der App, assembliert die Benutzeroberfläche (UI) und steuert den Lebenszyklus des Webauthentifizierungshosts. Der Webauthentifizierungshost rendert die Seiten von der Website des Onlineauthentifizierungsanbieters.

Das folgende Diagramm zeigt den Datenfluss bei Verwendung des Webauthentifizierungsbrokers.

Datenfluss für den Webauthentifizierungsbroker

So sieht der typische Workflow bei Verwendung des Webauthentifizierungsbrokers aus:

  1. 1. Die App ruft den Webauthentifizierungsbroker mithilfe der WebAuthenticationBroker.AuthenticateAsync-Methode auf. Sie stellen einen Anforderungs-URI als Ausgangspunkt und einen Rückruf-URI für den Abschluss des Authentifizierungsaufrufs bereit. Diese entsprechen einem Autorisierungsendpunkt-URI und einem Umleitungs-URI im OAuth 2.0-Protokoll. Das OpenID-Protokoll und Vorgängerversionen von OAuth funktionieren ähnlich.
  2. Der Broker erstellt ein für die aufrufende App modales Systemdialogfeld.
  3. Der Broker wählt einen dedizierten App-Container aus, der von der aufrufenden App oder anderen Apps im System getrennt ist, und löscht eventuell vorhandene persistente Cookies. Hinweis  Dieser App-Container wird nie von zwei Apps gleichzeitig genutzt, es sei denn, der Broker wurde im Modus "Einmaliges Anmelden" (Single Sign-on, SSO) gestartet.  
  4. Der Broker startet den Webauthentifizierungshost im ausgewählten App-Container.
  5. Der Broker fügt das Fenster des Hosts an das zuvor erstellte Dialogfeld an. Das Hostfenster übernimmt das Rendern des Webinhalts.
  6. Der Webauthentifizierungshost navigiert zum Anforderungs-URI. In der Regel handelt es sich dabei um eine Anmeldeseite.
  7. Während der Benutzer mit der Website des Onlineanbieters interagiert, beispielsweise durch Klicken auf Links oder Übermitteln von Daten, prüft der Host jede URI auf Übereinstimmung mit einer von der App angegebenen Rückruf-URI, bevor er zu ihr navigiert.
  8. Wenn eine Übereinstimmung gefunden wird, beendet der Host die Navigation und sendet ein Signal an den Broker.
  9. Der Broker entfernt das Dialogfeld, löscht möglicherweise vorhandene, vom Host erstellte persistente Cookies aus dem App-Container und gibt die Protokolldaten an die Anwendung zurück.

Funktionsweise des einmaligen Anmeldens mit dem Webauthentifizierungsbroker

Der Webauthentifizierungsbroker ermöglicht das einmalige Anmelden (Single Sign-On, SSO), indem er die Aufbewahrung von persistenten Cookies in einem speziellen SSO-App-Container zulässt. Zum Verwenden dieses Containers kann die App die Überladung der AuthenticateAsync-Methode aufrufen, für die kein Rückruf-URI erforderlich ist. Die anfängliche Umleitungs-URL muss das Format "ms-app://<SID>" haben, wobei <SID> der SID des aufrufenden Pakets entspricht. Anschließend können Sie die SID für jede App beim Authentifizierungsdienst als gültige Umleitungs-URL (auch als "Umleitungsendpunkt" bezeichnet) registrieren.

Beispiel: Fabrikam ist ein Entwickler einer Windows Store-App, die Dienste von Contoso nutzt. Während der Entwicklung hat Fabrikam die Anwendung im Windows Dev Center registriert und daraufhin eine eindeutige SID erhalten. Anschließend hat Fabrikam seine App-SIDs beim Contoso.com-Authentifizierungsdienst als gültige Umleitungs-URLs registriert. Fabrikam hat zwei seiner SIDs als Umleitungs-URLs registriert. Eine davon lautete "ms-app://S-1-5-4321".

Zur Laufzeit ruft die Windows Store-App von Fabrikam den Webauthentifizierungsbroker im SSO-Modus auf. Im Rahmen der Anforderungsverarbeitung wird von "Contoso.com" überprüft, ob sich die Umleitungs-URL in der Gruppe registrierter URLs befindet. Nach der Authentifizierung des Benutzers durch Contoso erfolgt die Weiterleitung mit einem angefügten Zugriffstoken an die angeforderte Umleitungs-URL: "ms-app://S-1-5-4321?token=ABC". Erkennt der Webauthentifizierungsbroker eine URL in diesem Format, die mit der SID der aufrufenden App übereinstimmt, gibt er das in der Abfragezeichenfolge oder in den bereitgestellten Daten enthaltene Token an die App zurück.

Falls im SSO-App-Container bereits Cookies erstellt wurden, müsste sich der Benutzer nicht bei Contoso anmelden. Falls nun eine andere App versucht, sich als App von Fabrikam auszugeben, tritt ein Fehler auf, da Contoso die Identität der App überprüft hat. Bei dieser Überprüfung wurde sichergestellt, dass eine der bereits registrierten Umleitungs-URLs anfordert wird und der Webauthentifizierungsbroker dafür gesorgt hat, dass nur eine App, die eine SID besitzt, an die Contoso weiterleiten möchte, die Protokolldaten erhält.

Problembehandlung für den Webauthentifizierungsbroker

Es gibt verschiedene Möglichkeiten, die Problembehandlung für die Webauthentifizierungsbroker-APIs Ihrer App durchzuführen. Beispiele hierfür sind die Untersuchung von Betriebsprotokollen und die Untersuchung von Webanforderungen und -antworten mit Fiddler.

Betriebsprotokolle

Häufig können Sie anhand der Betriebsprotokolle ermitteln, was nicht funktioniert. Dank des dedizierten Ereignisprotokollkanals "Microsoft-Windows-WebAuth\Operational" können Websiteentwickler nachvollziehen, wie ihre Webseiten vom Webauthentifizierungsbroker verarbeitet werden. Starten Sie zur Aktivierung des Brokers "eventvwr.exe", und aktivieren Sie das Betriebsprotokoll unter "Anwendungen und Dienste\Microsoft\Windows\WebAuth". Darüber hinaus hängt der Webauthentifizierungsbroker eine eindeutige Zeichenfolge an die Zeichenfolge des Benutzer-Agents an, um sich selbst auf dem Webserver zu identifizieren. Die Zeichenfolge lautet "MSAuthHost/1.0". Beachten Sie, dass sich die Versionsnummer ändern kann. Verlassen Sie sich also in Ihrem Code nicht auf diese Versionsnummer. Beispiel der vollständigen Zeichenfolge des Benutzer-Agents:

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

Beispiel für die Verwendung von Betriebsprotokollen

  1. Aktivieren von Betriebsprotokollen
  2. Ausführen der Contoso-App für soziale NetzwerkeEreignisanzeige mit WebAuth-Betriebsprotokollen
  3. Anhand der generierten Protokolleinträge kann das Verhalten des Webauthentifizierungsbrokers genauer nachvollzogen werden. In diesem Fall können sie Folgendes enthalten:
    • Navigation - Starten: Protokolliert, wann AuthHost gestartet wird, und enthält Informationen zu den Start- und End-URLs.
    • Veranschaulicht die Details von "Navigation - Starten"
    • Navigation abgeschlossen: Protokolliert den Abschluss des Ladevorgangs einer Webseite.
    • META-Tag: Protokolliert, wann ein META-Tag auftritt (einschließlich Details).
    • Navigation - Beenden: Die Navigation wurde vom Benutzer beendet.
    • Navigationsfehler: AuthHost ermittelt einen Navigationsfehler bei einer URL, einschließlich HttpStatusCode.
    • Navigationsende: End-URL liegt vor.

Verwenden von Fiddler mit dem Webauthentifizierungsbroker

Der Fiddler-Webdebugger kann für Windows 8-Apps verwendet werden.

  1. Da AuthHost in einem eigenen App-Container ausgeführt wird, um Funktionen für private Netzwerke zu ermöglichen, müssen Sie einen Registrierungsschlüssel festlegen: 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. Fügen Sie eine Regel für AuthHost hinzu, da darüber ausgehender Datenverkehr generiert wird.

    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. Fügen Sie Fiddler eine Firewallregel für eingehenden Datenverkehr hinzu.

Weitere Informationen finden Sie im Blog zur Verwendung des Fiddler-Webdebuggers mit Windows Store-Apps.

Verwandte Themen

Webauthentifizierungsbroker für Onlineanbieter

Beispiel für einen Webauthentifizierungsbroker

Windows.Security.Authentication.Web