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.
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
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.