Windows Azure Appfabric ACS Note

Access Control Service (ACS) provides a facility forabstractingyour authentication code, as well as

mapping disparate claims from multiple identity providers into a single token and claim structure. In

addition to saving you the trouble of writing code to authenticate to many identity providers, this makes

it easier to write your authorization code, as you can expect to receive a consistent set of claims from

ACS.

https://www.windowsazure.com/en-us/develop/net/how-to-guides/access-control/

The following figure shows how ACS authentication works with a web application:



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 redirects the client to ACS and the client sends the security token issued by the IP 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 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.

The primary function of ACS is to transform input claims into output claims as follows:

1. Configure ACS and the identity provider to trust each other.

2. Configure ACS and your service (a.k.a., relying party) to trust each other with a

signing key.

3. Configure ACS with rules for mapping input claims to output claims that your

application expects. In the real world, these tasks are performed by system

and/or security administrators.

4. When an application wants to consume the web service, it sends the required

claims to ACS in a request for a token.

5. ACS transforms input claims into output claims based on the mapping rules

you created while configuring ACS.

6. Next, ACS issues a token with output claims to the consumer application. The

consumer application sends the token in the request header to the web

service.

7. The web service validates the claims in the token and provides appropriate

access to the end user.

Active Directory itself doesn’t support a claims-based identity model. You will need Active Directory

Federation Services 2.0 (ADFS 2.0) to provide claims-based identity support to Active Directory. ADFS 2.0 is built using WIF

The important information to take from this example is the fact that
ACS abstracts multiple token

providers from the relying party by always issuing the same type of token. The
relying party has to only

consider the output claims in its authorization logic to provide appropriate access to the end user.

The following steps describe the flow of

information from the requesting user or application to the relying party:

Step 0: Two important prerequisites for claims-based identity to work are

completed in this step. First, trust is established between the relying party (web

service), ACS, and identity providers.Second, an administrator creates an issuer to identify service

consumers and defines the mapping rules between input claims and output claims

in the form of rules in ACS

Step 1: When ACS, the relying party, and identity providers are configured for the

claims-based identity model to work seamlessly, the service consumer must use the

issuer key material to acquire a token from ACS in order to call the web service

Type of Token

-Plain text:

-Signed:

-SAML:

-SWT

Step 2: Based on the claims-mapping rules configured in ACS, ACS maps the input

claims received in the service consumer token to output claims specific to the web

service

Step 3: Regardless of the method used to acquire the input token,
ACS creates an

SWT or a SAML token and sends it to the service consume

Step 4: The consumer packages the token into an HTTP header and sends it to the

web service along with the message payload.

Step 5: The web service validates the token based on the secret key exchange

established in Step 0

Tip:

The key concept to understand here is that if there wasonly oneidentity provider, you could validate the

claims based on that identity provider, but every identity provider generates different claims and thus a different

token structure. This forces the developer to update the relying party code for supporting specific identity

providers. By using ACS, the developer can expect
only one type of token emitted from ACS that is independent of

the identity provider. This makes the relying party extensible. Therefore, when you design your relying party, make

sure you consider the current and future requirements from the user identity perspective.

Scenario 1

shows how an enterprise cloud application can benefit from ACS.

Scenario 2 illustrates the use of ACS in

a cross-enterprise scenario, and finally

scenario 3 shows an ISV cloud service using ACS across multiple

customers.

Scenario 1: Enterprise Cloud Application



Step 0: The T-Room system administrator completes all the prerequisites to make

ACS work for the T-Room application.

Step 1: First, the requestor goes to access the web application.
The web application

identifies there is no token in the request. Therefore, requestor is redirected to ACS

and then to the login page of the appropriate identity provider. The requestor

authenticates with the identity provider and acquires a token.

Step 2: The requestor posts the acquired token to ACS for claims mapping.

Step 3: ACS is an important piece of the identity federation orchestration because

the token is sent to ACS to transform input claims to output claims the T-room

application understands. T-Room application is not designed with any specific

identity provider in mind, but only the claims. This is a very important concept to

understand.

Step 4: ACS returns a token to the requestor. This token consists of the output claims

that only the T-Room application understands.

Step 5: The requestor packages the token along with the payload and sends it to the

relying party (the T-Room web application).

Step 6: The T-Room application processes these claims in a claims-processing

module and determines the level of access the requestor is entitled to. The claimsprocessing

module doesn’t depend on any identity provider but only validates the

claims from the requestor’s token.

Scenario 2: Cross-Enterprise Application

Step 1: When an Enterprise B employee wants to sign in to the PartnerAccess

web application, the employee is authenticated with Enterprise B’s Active

Directory, and the ADFS 2.0 generates a SAML token for ACS. Because

Enterprise B is in control of its employee identities,
and Enterprise A trusts

Enterprise B’s authentication process, it makes sense to delegate the

authentication of Enterprise B’s employees to Enterprise B.

Scenario 3: ISV Cloud Service

independent software vendor (ISV)

Token Signing

In ACS, tokens are signed using either an X.509 certificate or a symmetric key, depending on your token

format. SAML tokens are signed with X.509 certificates, and SWT tokens are signed with a 256-bit

symmetric key.

Which token format should you use? As usual, it depends. However, consider that SAML tokens are

the default for Windows Identity Foundation applications, and are compatible with many protocols,

including WS-Federation and WS-Trust. SWT tokes are also compatible with many protocols, including

OAuth WRAP and WS-Federation.



Concepts and Terminology

Security Token (SAML Token)2

A SAML token is an XML message consisting of sets of claims digitally signed by the issuing authority.

The token is issued by a Secure Token Service (STS). The ACS and relying party both process claims from

SAML tokens.

Request for Security Token (RST)

Every relying party requires a unique set of claims it can process.
RST is the request made to an STS to

acquire these claims to an STS. For example, a requestor may make this request to ACS to acquire claims

for a relying party.

Web Resource Authorization Protocol (WRAP) and Simple Web

Token (SWT)

Version 1 of ACS implements the REST-friendly Web Resource Authorization Protocol (WRAP) that

defines the Simple Web Token standard. The token issued by ACS adheres to the SWT specification,

which you can find in the WRAP profiles on the OAuth web site at
http://groups.google.com/group/oauth-wrap-wg. SWT tokens are HTTP form encoded key-value pairs

signed with an HMAC-SHA256 cryptographic key. ACS always emits either an SWT or SAML for different

types of input tokens (such as SAML, SWT, Facebook tokens, LiveID tokens, and so on), so the relying

party can always expect either SWT of SAML from ACS.
SWT is typically designed for REST-based web

services. SAML is supported by a wide range of software vendors like IBM, Microsoft, Oracle,
andComputer Associates.