Partager via

Services web et ACS

  • Article

Mise à jour : 19 juin 2015

S’applique à : Azure

Voici les participants au scénario de base dans lequel un service web est intégré à Microsoft Azure Active Directory Access Control (également appelé service Access Control ou ACS) :

  • Application de partie de confiance : votre service web.

  • Client : client de service web qui tente d'accéder votre service web.

  • Fournisseur d'identité : site ou service qui peut authentifier le client.

  • ACS : partition d’ACS dédiée à votre application de partie de confiance.

Toutefois, le scénario de service web part du principe que le client n'a pas accès à un navigateur et qu'il agit de manière autonome (sans qu'un utilisateur participe directement au scénario).

Le client doit obtenir un jeton de sécurité émis par ACS pour se connecter à votre service. Ce jeton est un message signé d’ACS à votre application, avec un ensemble de revendications sur l’identité du client. ACS n’émet pas de jeton, sauf si le client prouve d’abord son identité.

Dans un service web et un scénario ACS, un client peut prouver son identité de la manière suivante :

  • En authentifiant directement avec ACS et en utilisant les types d’informations d’identification ACS Service Identity

    Notes

    Pour plus d’informations sur les identités de service, consultez Identités de service.

    La figure suivante illustre le scénario de service web avec le client montrant son identité avec les types d’informations d’identification d’identité de service ACS.

    Windows Azure Active Direct Access Control

    1. Le client s’authentifie auprès d’ACS à l’aide de l’un des types d’informations d’identification ACS Service Identity. Dans ACS, il peut s’agir d’un jeton SWT (Simple Web Token) signé avec une clé symétrique, un certificat X.509 ou un mot de passe. Pour plus d’informations, consultez Identités de service.

    2. ACS valide les informations d’identification reçues, entre les revendications d’identité reçues dans le moteur de règles ACS, calcule les revendications de sortie et crée un jeton qui contient ces revendications.

    3. ACS retourne le jeton émis par ACS au client.

    4. Le client envoie le jeton émis par ACS à l’application de partie de confiance.

    5. L’application de partie de confiance valide le jeton émis par ACS, puis retourne la représentation de ressource demandée.

  • En présentant un jeton de sécurité d'un autre émetteur approuvé (Fournisseur d'identité) qui a authentifié ce client

    La figure suivante illustre le scénario de service web dans lequel le client prouve son identité avec un jeton de sécurité délivré par un fournisseur d'identité.

    ACS 2.0 Web Service Scenario

    1. Le client se connecte au fournisseur d'identité (par exemple, il envoie les informations d'identification).

    2. Une fois le client authentifié, le fournisseur d'identité émet un jeton.

    3. Le fournisseur d'identité retourne le jeton au client.

    4. Le client envoie le jeton émis par le fournisseur d’identité à ACS.

    5. ACS valide le jeton émis par le fournisseur d’identité, entre les données du jeton émis par le fournisseur d’identité dans le moteur de règles ACS, calcule les revendications de sortie et crée un jeton qui contient ces revendications.

    6. ACS émet un jeton au client.

    7. Le client envoie le jeton émis par ACS à l’application de partie de confiance.

    8. L’application de partie de confiance valide la signature sur le jeton émis par ACS et valide les revendications dans le jeton émis par ACS.

    9. Ensuite, elle retourne la représentation de ressource demandée.

Voir aussi

Concepts

Access Control Service 2.0
Prise en main avec ACS
Création de mon premier service ASP.NET prenant en charge les revendications avec ACS