Access Control Service is a Windows Azure service that provides an easy way of authenticating users who need to access your web applications and services without having to factor complex authentication logic into your code.
The following features are available in ACS:
- Integration with Windows Identity Foundation (WIF),
- Support for popular web identity providers (IPs) including Windows Live ID, Google, Yahoo, and Facebook,
- Support for Active Directory Federation Services (AD FS) 2.0,
- An Open Data Protocol (OData)-based management service that provides programmatic access to ACS settings,
- A Management Portal that allows administrative access to the ACS settings.
Windows Azure ACS is built on the principals of claims-based identity – a consistent approach to creating authentication mechanisms for applications running on-premises or in the cloud. Claims-based identity provides a common way for applications and services to acquire the identity information they need about users inside their organization, in other organizations, and on the Internet.
To complete the tasks in this guide, you should understand the following concepts:
Client – In the context of this how-to guide, this is a browser that is attempting to gain access to your web application.
Relying party (RP) application – An RP application is a web site or service that outsources authentication to one external authority. In identity jargon, we say that the RP trusts that authority. This guide explains how to configure your application to trust ACS.
Token – A token is a collection of security data that is usually issued upon successful authentication of a user. It contains a set of claims, attributes of the authenticated user. A claim can represent a user’s name, an identifier for a role a user belongs to, a user’s age, and so on. A token is usually digitally signed, which means it can always be sourced back to its issuer, and its content cannot be tampered with. A user gains access to a RP application by presenting a valid token issued by an authority that the RP application trusts.
Identity Provider (IP) – An IP is an authority that authenticates user identities and issues security tokens. The actual work of issuing tokens is implemented though a special service called Security Token Service (STS). Typical examples of IPs include Windows Live ID, Facebook, business user repositories (like Active Directory), and so on. When ACS is configured to trust an IP, the system will accept and validate tokens issued by that IP. ACS can trust multiple IPs at once, which means that when your application trusts ACS, you can instantly offer your application to all the authenticated users from all the IPs that ACS trusts on your behalf.
Federation Provider (FP) – IPs have direct knowledge of users, authenticate them using their credentials and issue claims about what they know about them. A Federation Provider (FP) is a different kind of authority: rather than authenticating users directly, it acts as an intermediary and brokers authentication between one RP and one or more IPs. Both IPs and FPs issue security tokens, hence they both use Security Token Services (STS). ACS is one FP.
ACS Rule Engine – The logic used to transform incoming tokens from trusted IPs to tokens meant to be consumed by the RP is codified in form of simple claims transformation rules. ACS features a rule engine that takes care of applying whatever transformation logic you specified for your RP.
Access Control Namespace – A namespace is a top level partition of ACS that you use to organize your settings. A namespace holds a list of IPs you trust, the RP applications you want to serve, the rules that you expect the rule engine to process incoming tokens with, and so on. A namespace exposes various endpoints that will be used by the application and the developer to get ACS to perform its function.
How does it work?
1. The client (in this case a browser) requests a page from the RP.
2. Since the request is not yet authenticated, the RP redirects the user to the authority that it trusts, which is ACS. The ACS presents the user with the choice of IPs that were specified for this RP. The user selects the appropriate IP.
3. The client browses to the IP’s authentication page, and prompts the user to log on.
4. After the client is authenticated (for example, the identity credentials are entered), the IP issues a security token.
5. After issuing a security token, the IP redirects the client to ACS and the client sends the security token issued by the IP to ACS.
6. ACS validates the security token issued by the IP, inputs the identity claims in this token into the ACS rules engine, calculates the output identity claims, and issues a new security token that contains these output claims.
7. ACS redirects the client to the RP. The client sends the new security token issued by ACS to the RP. The RP validates the signature on the security token issued by ACS, validates the claims in this token, and returns the page that was originally requested.
What do you need to get it running?
- An active Windows Azure account:
If you don’t have Windows Azure account, you could obtain free trial.
- Visual Studio 2012:
If you want to use latest feature of ACS 2.0 it is recommended using VS2012, but VS2010 could also work with little bit of work.
- Identity and Access tool:
This tool is great add-on for VS2012 which significantly ease connecting ACS with your application.
After few simple steps you should be ready to authenticate users to your application using Windows Azure ACS with identity providers like Microsoft, Google, Facebook etc.