Introduction

The Windows Azure AppFabric Access Control Service (ACS) makes it easy to authenticate and authorize users of your web sites and services. ACS integrates with popular web and enterprise identity providers, is compatible with most popular programming and runtime environments, and supports many protocols including: OAuth, OpenID, WS-Federation, and WS-Trust.

On this site you will find code samples and documentation for intergrating ACS with your relying party applications. For comprehensive product documentation on ACS 2.0, see the Access Control Service Documentation on MSDN.

Contents

Prerequisites: Describes what's required to get up and running with ACS 2.0
Getting Started: Walkthrough a simple end-to-end web application scenario
Samples: Descriptions and Readmes for the ACS Samples

Key Features

  • Integrates with Windows Identity Foundation and tooling (WIF)
  • Out-of-the-box support for popular web identity providers including: Windows Live ID, Google, Yahoo, and Facebook
  • Out-of-the-box support for Active Directory Federation Server v2.0
  • Support for OAuth 2.0 (draft 10), WS-Trust, and WS-Federation protocols
  • Support for the SAML 1.1, SAML 2.0, and Simple Web Token (SWT) token formats
  • Integrated and customizable Home Realm Discovery that allows users to choose their identity provider
  • An OData-based Management Service that provides programmatic access to ACS configuration
  • A Web Portal that allows administrative access to ACS configuration

Platform Compatibility

ACS is compatible with virtually any modern web platform, including .NET, PHP, Python, Java, and Ruby. For a list of .NET system requirements, see Prerequisites.

Core Scenario

Most of the scenarios that involve ACS consist of four autonomous services:
Relying Party Application (RP): Your web site or service
Client: The browser or application that is attempting to gain access to the Relying Party Application
Identity Provider (IdP): The site or service that can authenticate the Client
ACS: The partition of ACS that is dedicated to the Relying Party Application
The core scenario is similar for web services and web sites, though the interaction with web sites utilizes the capabilities of the browser.

Web Site Scenario

This web site scenario is shown below:

Main1.png
  1. The Client (in this case a browser) requests a resource at the RP. In most cases, this is simply an HTTP GET.
  2. Since the request is not yet authenticated, the RP redirects the Client to the correct IdP. The RP may determine which IdP to redirect the Client to using the Home Realm Discovery capabilities of ACS.
  3. The Client browses to the IdP authentication page, and prompts the user to login.
  4. After the Client is authenticated (e.g. enters credentials), the IdP issues a token.
  5. After issuing a token, the IdP redirects the Client to ACS.
  6. The Client sends the IdP issued token to ACS.
  7. ACS validates the IdP issued token, inputs the data in the IdP issued token to the ACS rules engine, calculates the output claims, and mints a token that contains those claims.
  8. ACS redirects the Client to the RP.
  9. The Client sends the ACS issued token to the RP.
  10. The RP validates the signature on the ACS issued token, and validates the claims in the ACS issued token.
  11. The RP returns the resource representation originally requested in (1).

Web Service Scenario

The core web service scenario is shown below. It assumes that the web service client does not have access to a browser and the Client is acting autonomously (without a user directly participating in the scenario).

Main2.png
  1. The Client logs in to the IdP (e.g. sends credentials)
  2. After the Client is authenticated, the IdP mints a token.
  3. The IdP returns the token to the Client.
  4. The Client sends the IdP-issued token to ACS.
  5. ACS validates the IdP issued token, inputs the data in the IdP issued token to the ACS rules engine, calculates the output claims, and mints a token that contains those claims.
  6. ACS returns the ACS issued token to the Client.
  7. The Client sends the ACS issued token to the RP.
  8. The RP validates the signature on the ACS issued token, and validates the claims in the ACS issued token.
  9. The RP returns the resource representation originally requested in (1).

Last edited Apr 21, 2012 at 12:56 AM by asmalser, version 44

Comments

Santibal May 5, 2011 at 10:06 AM 
When I try to sign with a custom sts with WIF througth AC, I receive a 404 http error when i put my username and password in sts login form. If i try to authenticate with Live Id oor Facebook, i haven't the problem.

Any hint?

Thanks

imorrish Nov 12, 2010 at 10:29 PM 
Where can I get the public key for the Default Asymmetric Token Signing Key X.509 Certificate created for my service namespace?

cdr Aug 19, 2010 at 9:39 AM 
Hi,

same as rsdev5, I'm trying the MVC service sample, and I'm setting up the STS by uploading a new X.509 cert made by MakeCert (signing cert).

When I try to download the federation metadata (https://cdr-test2-sb.accesscontrol.appfabriclabs.com/FederationMetadata/2007-06/FederationMetadata.xml) I get the following error message:

Sorry, an error occurred while processing your request.

HTTP Error Code: 400
Message: No tenant signing key of type X509 certificate is provisioned.
Trace ID: b5e94475-de72-4b23-9c7d-5fc7dfa77aba

When i try to modify cert settings from the STS portal i get the following error:

Sorry, an unexpected error occurred while processing your request.

HTTP Error Code: 500
Message: Internal Server Error.
Trace ID: 0e14d4e4-6ebe-456d-9a75-5339cf3db3de

Any hint?

Thanks.

rsdev5 Aug 19, 2010 at 8:57 AM 
Hi,

I was trying the ASPNET Simple Service example.
Very good doc but I can't get it to work.

I have 2 problems:
1. Clicking on Certificates and Keys shows an error: "Sorry, an unexpected error occurred while processing your request."
2. When I use 'acssample' as the wrap user (after creating a Service Identity with that name) I get an exception saying:
Error:Code:401:SubCode:T0:Detail:ServiceIdentityNotFoundInDataStore

Even though I see it on the portal.

Am I missing something?

Thanks

vibronet Aug 10, 2010 at 10:12 PM 
Hi Rlmorgan,
all that you see here is perfectly in line with the "geneva" vision. This new release of ACS adds support to many new protocols to the offering currently in production, all based on claims and all interoperable to the extent of the state of the art of claims-based standards today. Those protocols and identity providers were added in response to community feedback: thanks to its nature of hosted service, it is perfectly feasible that more protocols will be added in subsequent releases.
Also note: although ACS provides a very handy gateway for securing access to services hosted in Windows Azure, you are by no means constrained by it. In Windows Azure you can run arbitrary code and even pursue approaches based on non-Microsoft technologies such as PHP. From your code you can decide to trust whatever identity provider and whatever protocol fits your needs, ACS or on-premises instances of ADFS2 are just possible choices among the full range of identity providers your code can support. If you elect to stick with Microsoft technologies, *at this point in time* the SAML protocol is natively supported only in ADFS2: but I would not conclude that Microsoft is not true to the Geneva vision. In fact, in my opinion the sheer number of open protocols and web identity providers supported in the latest ACS release is a GREAT example of our willingness to execute on that vision.
Best,

Vittorio

rlmorgan2378 Aug 10, 2010 at 6:09 PM 
So I have to install ADFSv2 in order to authenticate to Azure? This seems entirely opposite to the openness to protocols and IdP implementations promised by the work formerly called Geneva. Can Microsoft explain why it has reneged on this promise? Is there something difficult about supporting SAML?

tslinehan Aug 10, 2010 at 3:25 AM 
WIF supports the SAML token format but not the protocol. You could use AD FSv2 which does support SAML 2.0 IdP lite to translate it to WS-Fed and pass to ACS.

rlmorgan2378 Aug 9, 2010 at 11:19 PM 
Why is there no support for SAML protocol? I have 500,000 users in my organizational SAML IdP, and another 150 SAML IdPs in our federation. WIF supports SAML, doesn't it?