Webdienste und ACS

Aktualisiert: 19. Juni 2015

Gilt für: Azure

Im Folgenden finden Sie die Teilnehmer des Grundlegenden Szenarios, in dem ein Webdienst in Microsoft Azure Active Directory Access Control integriert ist (auch bekannt als Access Control Service oder ACS):

• 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 vertrauende Parteianwendung vorgesehen 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 bei Ihrem Dienst anzumelden. Dieses Token ist eine signierte Nachricht von ACS an Ihre Anwendung mit einer Reihe von Ansprüchen über die Identität des Clients. ACS stellt kein Token aus, es sei denn, der Client beweist zuerst seine Identität.

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

• Durch direkte Authentifizierung mit ACS und Verwenden der ACS Service Identity-Anmeldeinformationstypen

  Hinweis

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

  In der folgenden Abbildung wird das Webdienstszenario veranschaulicht, in dem der Client seine Identität mit ACS-Dienstidentitäts-Anmeldeinformationstypen nachweist.

  

  1. Der Client authentifiziert sich mit ACS mithilfe eines der ACS Service Identity-Anmeldeinformationstypen. In ACS kann dies ein simple Web Token (SWT) sein, das mit einem symmetrischen Schlüssel, einem X.509-Zertifikat oder einem Kennwort signiert ist. 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 ein Token, das diese Ansprüche enthält.

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

  4. Der Client sendet das 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.

  

  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 im vom Identitätsanbieter ausgestellten Token in das ACS-Regelmodul ein, berechnet die Ausgabeansprüche und erstellt ein Token, das diese Ansprüche enthält.

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

  7. Der Client sendet das acS-ausgestellte Token an die Anwendung der vertrauenden Seite.

  8. Die Anwendung der vertrauenden Partei überprüft die Signatur für das ausgestellte ACS-Token und überprüft die Ansprüche im ausgestellten ACS-Token.

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

Weitere Informationen

Konzepte

Access Control Service 2.0
Erste Schritte mit ACS
Gewusst wie: Erstellen meines ersten anspruchsfähigen ASP.NET Diensts mithilfe von ACS