Export (0) Print
Expand All

Web Applications and ACS

Published: April 7, 2011

Updated: February 21, 2014

Applies To: Azure

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

  • Relying party (RP) application—Your web application.

  • Client—A browser or an application that is attempting to gain access to your web application.

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

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

When your web application handles user authentication with ACS, the client must obtain a security token issued by ACS in order to log on to your application. This token contains a set of claims about the user's identity. ACS does not issue a token unless the user first proves his or her identity by presenting a security token from another trusted issuer (identity provider) that has authenticated that user.

The following figure describes this scenario.

ACS 2.0 Web Site Scenario
  1. The client (in this case a browser) requests a resource from the relying party application.

  2. Since the request is not yet authenticated, the relying party application redirects the client to the appropriate identity provider. The relying party application can determine which identity provider to redirect the client to using the Home Realm Discovery capabilities of ACS.

  3. The client browses to the identity provider’s authentication page, and prompts the user to log on.

  4. After the client is authenticated (for example, the identity credentials are entered), the identity provider issues a security token.

  5. After issuing a security token, the identity provider redirects the client to ACS.

  6. The client sends the security token issued by the identity provider to ACS.

  7. ACS validates the security token issued by the identity provider, inputs the identity claims in this token to the ACS rules engine, calculates the output identity claims, and issues a new security token that contains these output claims.

  8. ACS redirects the client to the relying party application.

  9. The client sends the new security token issued by ACS to the relying party application.

  10. The relying party application validates the signature on the security token issued by ACS and validates the claims in this token.

  11. The relying party application returns the resource representation that was originally requested in Step 1.

For the detailed instructions about how to integrate your web application with ACS, see How to: Create My First Claims-Aware ASP.NET Application Using ACS.

See Also

Community Additions

© 2014 Microsoft