Cette documentation est archivée et n’est pas conservée.

Services web et ACS

Publication: avril 2011

Mis à jour: juin 2015

S'applique à: Azure

Voici une liste des participants au scénario de base dans lequel un service web est intégré à Microsoft Azure Active Directory Access Control (également appelé Access Control Service 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 pouvoir se connecter à votre service. Ce jeton est un message signé envoyé par ACS à votre application, avec un jeu de revendications concernant l'identité du client. ACS ne délivre pas de jeton à moins que le client ne prouve d'abord son identité.

Dans un scénario avec service web et ACS, un client peut prouver son identité des manières suivantes :

  • En s'authentifiant directement auprès d'ACS et en utilisant les types d'informations d'identification Identité de service ACS

    noteRemarque
    Pour plus d'informations sur les identités de service, voir Identités de service.

    La figure suivante illustre le scénario de service web dans lequel le client prouve son identité avec les types d'informations d'identification Identité de service ACS.

    Contrôle d'accès Microsoft Azure Active Directory
    1. Le client s'authentifie auprès d'ACS à l'aide de l'un des types d'informations d'identification Identité de service ACS. 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, voir Identités de service.

    2. ACS valide les informations d'identification reçue, transmet les revendications d'identité reçues au moteur de règles ACS, calcule les revendications de sortie, puis 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. Celle-ci 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é.

    Scénario de service Web ACS 2.0
    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 de sécurité délivré par le fournisseur d'identité à ACS.

    5. ACS valide le jeton délivré par le fournisseur d'identité, transmet les données contenues dans ce jeton au moteur de règles ACS, calcule les revendications de sortie, puis crée un jeton qui contient ces revendications.

    6. ACS délivre un jeton au client.

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

    8. Celle-ci valide la signature du jeton délivré par ACS et valide les revendications qu'ACS contient.

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

Voir aussi

Afficher: