Web Services and ACS

  • Article

Updated: June 19, 2015

Applies To: Azure

The following are the participants of the basic scenario in which a web service is integrated with Microsoft Azure Active Directory Access Control (also known as Access Control Service or ACS):

  • Relying party application—Your web service.

  • Client—A web service client that is attempting to gain access to your web service.

  • Identity Provider—A site or service that can authenticate the client.

  • ACS —The partition of ACS that is dedicated to your relying party application.

However, the web service scenario assumes that the client does not have access to a browser and is acting autonomously (without a user directly participating in the scenario).

The client must obtain a security token issued by ACS in order to log on to your service. This token is a signed message from ACS to your application, with a set of claims about the client’s identity. ACS does not issue a token unless the client first proves his or her identity.

In a web service and ACS scenario, a client can prove his or her identity in the following ways:

  • By authenticating directly with ACS and using the ACS Service Identity credential types

    Note

    For more information about service identities, see Service Identities.

    The following figure illustrates the web service scenario with the client proving his identity with ACS service identity credential types.

    Windows Azure Active Direct Access Control

    1. The client authenticates with ACS using one of the ACS Service Identity credential types. In ACS, this can be a Simple Web Token (SWT) token signed with a symmetric key, an X.509 certificate, or a password. For more information, see Service Identities.

    2. ACS validates the received credentials, inputs the received identity claims into the ACS rules engine, calculates the output claims, and creates a token that contains those claims.

    3. ACS returns the ACS-issued token to the client.

    4. The client sends the ACS-issued token to the relying party application.

    5. The relying party application validates the token issued by ACS and then returns the requested resource representation.

  • By presenting a security token from another trusted issuer (Identity Provider) that has authenticated that client

    The following figure illustrates the web service scenario with the client proving his identity with a security token from an Identity Provider.

    ACS 2.0 Web Service Scenario

    1. The client logs in to the Identity Provider (for example, sends the credentials).

    2. After the client is authenticated, the Identity Provider issues a token.

    3. The Identity Provider returns the token to the client.

    4. The client sends the Identity Provider-issued token to ACS.

    5. ACS validates the Identity Provider-issued token, inputs the data in the Identity Provider-issued token to the ACS rules engine, calculates the output claims, and creates a token that contains those claims.

    6. ACS issues a token to the client.

    7. The client sends the ACS-issued token to the relying party application.

    8. The relying party application validates the signature on the ACS-issued token, and validates the claims in the ACS-issued token.

    9. The relying party application returns the requested resource representation.

See Also

Concepts

Access Control Service 2.0
Getting Started with ACS
How to: Create My First Claims-Aware ASP.NET Service Using ACS