ACS is an Azure service that provides easy authentication for web applications without requiring developers to build authentication logic. It supports popular identity providers like Microsoft, Google, and Facebook, and integrates with Active Directory. ACS uses claims-based identity to get user information and uses a rule engine to transform claims between identity providers and applications.

1. Windows Azure Access Control List
During the implementation of the project e-SUAP was tested technology of windows Azure ACS for security
management which ended up being very interesting.
Most developers are not identity experts and do not want to spend time developing authentication and
authorization mechanisms for their applications and services. ACS is an Azure service that provides an easy
way for you to authenticate users to access your web applications and services without having to add
complex authentication logic to your code.
The following features are available in ACS:
 Integration with Windows Identity Foundation (WIF).
 Support for popular web identity providers (IPs) including Microsoft accounts (formerly known as 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.
Concepts
ACS is built on the principles 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 get 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 terms and concepts are used in
this guide:
Client - A browser that is attempting to gain access to your web application.
Relying party (RP) application - Your web app. An RP application is a website 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 user gains access to an RP application by presenting a valid token that was issued by an authority
that the RP application trusts. A collection of security data that is issued when a client is authenticated. It
contains a set of claims, which are attributes of the authenticated user, such as a user's name or age, or an

2. identifier for a user role. A token is digitally signed so its issuer can be identified and its content cannot be
changed.
Identity Provider (IP) - An authority that authenticates user identities and issues security tokens, such as
Microsoft account (Windows Live ID), Facebook, Google, Twitter, and Active Directory. When ACS is
configured to trust an IP, it accepts and validates the tokens that the IP issues. Because ACS can trust
multiple IPs at the same time, when your application trusts ACS, you can your application can offer users
the option to be authenticated by any of the IPs that ACS trusts on your behalf.
Federation Provider (FP) - Identity providers (IPs) have direct knowledge of users, authenticate users by
using their credentials, and issue claims about users. A Federation Provider (FP) is a different kind of
authority. Instead of authenticating users directly, the FP brokers authentication. It acts as an intermediary
between a relying party application and one or more IPs. ACS is a federation provider (FP).
ACS Rule Engine - Claims transformation rules convert the claims in tokens from trusted IPs so they can be
used by an RP. ACS includes a rule engine that applies the claims transformation rules that you specify for
your RP.
Access Control Namespace - Provides a unique scope for addressing ACS resources within your application.
The namespace contains your settings, such as the IPs you trust, the RP applications you want to serve, the
rules that you apply to incoming tokens, and it displays the endpoints that the application and the
developer use to communicate with ACS.
The following figure shows how ACS authentication works with a web application:

3.  The client (in this case, a browser) requests a page from the RP.
 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.
 The client browses to the IP's authentication page, and prompts the user to log on.
 After the client is authenticated (for example, the identity credentials are entered), the IP issues a
security token.
 After issuing a security token, the IP directs the client to send the security token that the IP issued
to ACS.
 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.
 ACS directs the client to send the security token that ACS issued to the RP. The RP validates the
signature on the security token, extracts claims for use by the application business logic, and
returns the page that was originally requested.

4. 

6. The namespace NET Framework 4.5 for the management of the claims within the application code, in the
case of a NET application, is System.Security.Claims.
http://msdn.microsoft.com/it-it/library/system.security.claims(v=vs.110).aspx