Diese Dokumentation wurde archiviert und wird nicht länger gepflegt.

Webdienste und ACS

Veröffentlicht: April 2011

Letzte Aktualisierung: Juni 2015

Betrifft: Azure

Die folgenden Komponenten werden im Basisszenario verwendet, in dem ein Webdienst in Zugriffssteuerung für Microsoft Azure Active Directory (auch Zugriffssteuerungsdienst oder ACS) integriert wird:

  • Anwendung der vertrauenden Seite – Ihr Webdienst.

  • Client – Ein Webdienstclient, der versucht, Zugriff auf Ihren Webdienst zu erlangen.

  • Identitätsanbieter – Eine Website oder ein Dienst, der den Client authentifizieren kann.

  • ACS – Die Partition von ACS, die für Ihre Anwendung der vertrauenden Seite reserviert ist.

Im Webdienstszenario wird jedoch davon ausgegangen, dass der Client keinen Zugriff auf einen Browser besitzt und autonom (ohne direkte Benutzereingriffe) agiert.

Der Client muss ein von ACS ausgestelltes Sicherheitstoken abrufen, um sich am Dienst anmelden zu können. Dieses Token ist eine signierte Nachricht von ACS an Ihre Anwendung, die eine Sammlung von Ansprüchen zur Identität des Clients enthält. ACS stellt erst ein Token aus, nachdem der Client seine Identität bewiesen hat.

In einem Webdienst- und ACS-Szenario kann ein Client seine Identität auf die folgende Weise beweisen:

  • Durch direkte Authentifizierung mit ACS und Verwenden der Anmeldeinformationstypen der ACS-Dienstidentität.

    noteHinweis
    Weitere Informationen zu Dienstidentitäten finden Sie unter Dienstidentitäten.

    Die folgende Abbildung zeigt das Webdienstszenario, in dem der Client seine Identität mit Anmeldeinformationstypen der ACS-Dienstidentität bereitstellt.

    Windows Azure Active Directory Access Control
    1. Der Client authentifiziert sich bei ACS mithilfe eines der ACS-Dienstidentitäts-Anmeldeinformationentypen. In ACS kann es sich dabei um ein mit einem symmetrischen Schlüssel signiertes SWT-Token (Simple Web Token), ein X.509-Zertifikat oder ein Kennwort handeln. Weitere Informationen finden Sie unter Dienstidentitäten.

    2. ACS überprüft die empfangenen Anmeldeinformationen, gibt die empfangenen Identitätsansprüche in das ACS-Regelmodul ein, berechnet die Ausgabeansprüche und erstellt dann ein Token, das diese Ansprüche enthält.

    3. ACS gibt das von ACS ausgestellte Token an den Client zurück.

    4. Der Client sendet das von ACS ausgestellte Token an die Anwendung der vertrauenden Seite.

    5. Die Anwendung der vertrauenden Seite überprüft das von ACS ausgestellte Token und gibt dann die angeforderte Ressourcendarstellung zurück.

  • Durch Bereitstellen eines Sicherheitstokens von einem anderen vertrauenswürdigen Aussteller (Identitätsanbieter), der diesen Client authentifiziert hat.

    Die folgende Abbildung zeigt das Webdienstszenario, in dem der Client seine Identität mit einem Sicherheitstoken von einem Identitätsanbieter bereitstellt.

    ACS 2.0-Webdienstszenario
    1. Der Client meldet sich am Identitätsanbieter an (z. B. durch Senden der Anmeldeinformationen).

    2. Nachdem der Client authentifiziert wurde, stellt der Identitätsanbieter ein Token aus.

    3. Der Identitätsanbieter gibt das Token an den Client zurück.

    4. Der Client sendet das vom Identitätsanbieter ausgestellte Token an ACS.

    5. ACS überprüft das vom Identitätsanbieter ausgestellte Token, gibt die Daten aus dem vom Identitätsanbieter ausgestellten Token in das ACS-Regelmodul ein, berechnet die Ausgabeansprüche und erstellt dann ein Token, das diese Ansprüche enthält.

    6. ACS stellt ein Token für den Client aus.

    7. Der Client sendet das von ACS ausgestellte Token an die Anwendung der vertrauenden Seite.

    8. Die Anwendung der vertrauenden Seite überprüft die Signatur des von ACS ausgestellten Tokens und überprüft dann die Ansprüche im von ACS ausgestellten Token.

    9. Die Anwendung der vertrauenden Seite gibt die angeforderte Ressourcendarstellung zurück.

Siehe auch

Anzeigen: