Federated Identity with Microsoft Azure Access Control Service

The Premise | Goals and Requirements | Overview of the Solution - Example of a Customer with its Own Identity Provider, Example of a Customer Using a Social Identity, Trust Relationships with Social Identity Providers, Description of Mapping Rules in a Federation Provider | Alternative Solutions | Inside the Implementation | Setup and Physical Deployment - Establishing a Trust Relationship with ACS, Reporting Errors from ACS, Initializing ACS | Working with Social Identity Providers - Managing Users with Social Identities, Working with Windows Live IDs, Working with Facebook | Questions | More Information

In Chapter 4, "Federated Identity for Web Applications," you saw how Adatum used claims to enable users at Litware to access the a-Order application. The scenario described how Adatum could federate with partner organizations that have their own claims-based identity infrastructures. Adatum supported the partner organizations by establishing trust relationships between the Adatum federation provider (FP) and the partner's identity provider (IdP).

Adatum would now like to allow individual users who are not part of a partner's security domain to access the a-Order application. Adatum does not want to manage the user accounts for these individuals: instead, these individuals should be able to use an existing identity from social identity providers such as Microsoft® Windows® Live®, Google, Yahoo!, or Facebook. How can Adatum enable users to reuse an existing social identity, such as Facebook ID, when they access the a-Order application? In addition to establishing trust relationships with the social identity providers, Adatum must find solutions to these problems:

In this chapter, the term "social identity" refers to an identity managed by a well-known, established online identity provider.

• Different identity providers may use different protocols and token formats to exchange identity data.
• Different identity providers may use different claim types.
• The Adatum federation provider must be able to redirect users to the correct identity provider.
• The a-Order application must be able to implement authorization rules based on the claims that the social identity providers issue.
• Adatum must be able to enroll new users with social identities who want to use the a-Order application.

The Azure™ AppFabric Access Control Service (ACS) is a cloud-based federation provider that provides services to facilitate this scenario. ACS can transition between the protocols used by different identity providers to transfer claims, perform mappings between different claim types based on configurable rules, and help locate the correct identity provider for a user when they want to access an application. For more information, see Chapter 2, "Claims-Based Architectures."

Note

ACS currently supports the following identity providers: Windows Live, Google, Yahoo!, and Facebook. In addition, it can work with ADFS 2.0 identity providers or a custom security token service (STS) compatible with WS-Federation or WS-Trust. ACS also supports OpenID, but you must configure this programmatically rather than through the portal.

In this chapter, you'll learn how Adatum enables individual customers with a range of different social identity types to access the a-Order application alongside Adatum employees and employees of an existing enterprise partner. This chapter extends the scenario described in Chapter 4, "Federated Identity for Web Applications," and shows Adatum building on its previous investments in a claims-based identity infrastructure.

The Premise

Now that Adatum has enabled federated access to the a-Order application for users at some of Adatum's partners such as Litware, Adatum would like to extend access to the a-Order application to users at smaller businesses with no identity infrastructure of their own and to individual consumer users. Fortunately, it is likely that these users will already have some kind of social identity such as a Google ID or a Windows Live ID. Smaller businesses want their users to be able to track their orders, just as Rick at Litware is already able to do. Consumer users want to be able to log on with their social identity credentials and use the a-Order program to determine the status of all their orders with Adatum. They don't want to be issued additional credentials from Adatum just to use the a-Order application.

Poe Says:
	Consumer users will benefit from using their existing social identities because they won't need to remember a new set of credentials just for accessing the a-Order application. Adatum will benefit because they won't have the overhead of managing these identities—securely storing credentials, managing lost passwords, enforcing password policies, and so on.

Goals and Requirements

The goal of this scenario is to show how federated identity can make the partnership between Adatum and consumer users and users at smaller businesses with no security infrastructure of their own work more efficiently. With federated identity, one security realm can accept identities that come from another security realm. This lets people in one domain access resources located in the other domain without presenting additional credentials. The Adatum issuer will trust the common social identity providers (Windows Live ID, Facebook, Google, Yahoo!) to authenticate users on behalf of the a-Order application.

Note

Adatum trusts the social identity providers indirectly. The federation provider at Adatum trusts the Adatum ACS instance and that in turn trusts the social identity providers. If the federation provider at Adatum trusted all the social identity providers directly, then it would have to deal with the specifics of each one: the different protocols and token formats. ACS handles all of this complexity for Adatum and that makes it really easy for Adatum to support a variety of social identity providers.

In addition to the goals, this scenario has a number of other requirements. One requirement is that Adatum must control access to the order status pages and the information that the application displays based on the identity of the partner or consumer user who is requesting access to the a-Order application. In other words, users at Litware should only be able to browse through Litware's orders and not another company's orders. In this chapter, we introduce Mary, the owner of a small company named "Mary Inc." She, of course, should only be able to browse through her orders and no one else's.

Another requirement is that, because Adatum has several partner organizations and many consumer users, Adatum must be able to find out which identity provider it should use to authenticate a user's credentials. As mentioned in previous chapters, this process is called home realm discovery. For more information, see Chapter 2, "Claims-Based Architectures."

One assumption for this chapter is that Adatum has its own identity infrastructure in place.

Overview of the Solution

With the goals and requirements in place, it's time to look at the solution. As you saw in Chapter 4, "Federated Identity for Web Applications," the solution includes the establishment of a claim-based architecture with an issuer that acts as an identity provider on the customer's side and an issuer that acts as the federation provider on Adatum's side. Recall that a federation provider acts as a gateway between a resource and all of the issuers that provide claims about the resource's users.

In addition, this solution now includes an ACS instance, which handles the protocol transition and token transformation for issuers that might not be WS-Federation based. This includes many of the social identity providers mentioned earlier in this chapter.

Jana Says:
	Although using ACS simplifies the implementation of the Adatum issuer, it does introduce some running costs. ACS is a subscription service, and Adatum will have to pay based on its usage of ACS (ACS charges are calculated based on the number of Access Control transactions plus the quantity of data transferred in and out of the Azure datacenters).

Figure 1 shows the Adatum solution for both Litware that has its own identity provider, and Mary who is using a social identity—Google, in this example.

Figure 1

Accessing the a-Order application from Litware and by using a social identity

The following two sections provide a high-level walkthrough of the interactions between the relying party (RP), the federation provider, and the identity provider for customers with and without their own identity provider. For a detailed description of the sequence of messages that the parties exchange, see Appendix B.

Example of a Customer with its Own Identity Provider

To recap from Chapter 4, "Federated Identity for Web Applications," here's an example of how the system works for a user, Rick, at the partner Litware, which has its own identity provider. The steps correspond to the shaded numbers in the preceding illustration.

Step 1: Authenticate Rick

1. Rick is using a computer on Litware's network. Litware's Active Directory® service has already authenticated him. He opens a browser and navigates to the a-Order application. Rick is not an authenticated user in a-Order at this time. Adatum has configured a-Order to trust Adatum's issuer (the federation provider). The application has no knowledge of where the request comes from. It redirects Rick's request to the Adatum federation provider.
2. The Adatum federation provider presents the user with a page listing different identity providers that it trusts (the "Home realm Discovery" page). At this point, the federation provider doesn't know where Rick comes from.
3. Rick selects Litware from the list and then Adatum's federation provider redirects him to the Litware issuer that can verify that Rick is who he says he is.
4. Litware's identity provider verifies Rick's credentials and returns a security token to Rick's browser. Litware's identity provider has configured the claims in this token for the Adatum federation provider and they contain information about Rick that is relevant to Adatum. For example, the claims establish his name and that he belongs to the sales organization in Litware.

Step 2: Transmit Litware’s Security Token to the Adatum Federation Provider

1. Ricks’ browser now posts the issued token back to the Adatum federation provider. The Adatum federation provider validates the token issued by Litware and creates a new token that the a-Order application can use.

Step 3: Transforming the Token

1. The federation provider transforms the claims issued by Litware into claims that Adatum's a-Order application understands. (The mapping rules that translate Litware claims into Adatum claims were determined when Adatum configured its issuer to accept Litware's issuer as an identity provider.)
2. The claim mappings in Adatum's issuer remove some claims and add others that the a-Order application needs in order to accept Rick as a user, and possibly control access to certain resources.

Step 4: Transmit the Transformed Token and Perform the Requested Action

1. The Adatum issuer uses browser redirection to send the new token to the application. In the a-Order application, Windows Identity Foundation (WIF) validates the security token and extracts the claims. It creates a ClaimsPrincipal object and assigns it to HttpContext.User property. The a-Order application can then access the claims for authorization decisions. For example, in this scenario, the application filters orders by organization, which is one of the pieces of information provided as a claim.

Example of a Customer Using a Social Identity

Here's an example of how the system works for a consumer user such as Mary who is using a social identity. The steps correspond to the un-shaded numbers in the preceding illustration.

Step 1: Present Credentials to the Identity Provider

1. Mary is using a computer at home. She opens a browser and navigates to the a-Order application at Adatum. Adatum has configured the a-Order application to trust Adatum's issuer (the federation provider). Mary is currently un-authenticated, so the application redirects Mary's request to the Adatum federation provider.
2. The Adatum federation provider presents Mary with a page listing different identity providers that it trusts. At this point, the federation provider doesn't know which security realm Mary belongs to, so it must ask Mary which identity provider she wants to authenticate with.

   Markus Says:
   	In the sample, the simulated issuer allows you to select between Adatum, partner organizations, and social identity providers.

   3. Mary selects the option to authenticate using her social identity and then Adatum's federation provider redirects her to the ACS issuer to verify that Mary is who she says she is. Adatum's federation provider uses the **whr** parameter in the request to indicate to ACS which social identity provider to use—in this example it is Google.

   > [!NOTE]
   > In this sample, the Adatum simulated issuer allows users to enter the email address associated with their social identity provider. The simulated issuer parses this email address to determine the value of the <STRONG>whr</STRONG> parameter. Another option would be to let the user choose from a list of social identity providers. You should check what options are available with the issuer that you use; you may be able to query your issuer for the list of identity providers that it currently supports.
   

   4. ACS automatically redirects Mary to the Google issuer.

      Note

      Mary never sees an ACS page; when ACS receives the request from the Adatum issuer, ACS uses the value of the whr parameter to redirect Mary directly to her social identity provider. However, if the whr parameter is missing, or does not have a valid value, then ACS will display a page that allows the user to select the social identity provider that she wants to use.

   5. Google verifies Mary's credentials and returns a security token to Mary's browser. The Google identity provider has added claims to this token for ACS: the claims include basic information about Mary. For example, the claims establish her name and her email address.

      Bharath Says:
      	Mary must give her consent before Google will pass the claims on to ACS.

      Step 2: Transmit the Identity Provider's Security Token to ACS

      1. The Google identity provider uses HTTP redirection to redirect the browser to ACS with the security token it has issued.
      2. ACS receives this token and verifies that it was issued by the identity provider.

      Step 3: Transform the Claims

      1. If necessary, ACS converts the token issued by the identity provider to the security assertion markup language (SAML) 2.0 format and copies the claims issued by Google into the new token.
      2. ACS returns the new token to Mary's browser.

      Step 4: Transmit the Identity Provider's Security Token to the federation Provider

      1. Mary’s browser posts the issued token back to the Adatum federation provider.
      2. The Adatum federation provider receives this token and validates it by checking that ACS issued the token.

      Step 5: Map the Claims

      1. Adatum's federation provider applies token mapping rules to the ACS security token. These rules transform the claims into claims that the a-Order application can understand.
      2. The Adatum federation provider returns the new claims to Mary's browser.

      Step 6: Transmit the Mapped Claims and Perform the Requested Action

      1. Mary's browser posts the token issued by the Adatum federation provider to the a-Order application. This token contains the claims created by the mapping process.
      2. The application validates the security token by checking that the Adatum federation provider issued it.
      3. The application reads the claims and creates a session for Mary. It can use Mary's identity information from the token to determine which orders Mary can see in the application.

      Because this is a web application, all interactions happen through the browser. (See the section "Browser-Based Scenario with ACS" in Appendix B for a detailed description of the protocol for a browser-based client.)

      The principles behind these interactions are exactly the same as those described in Chapter 4, "Federated Identity for Web Applications."

      Adatum's issuer, acting as a federation provider, mediates between the application and the external issuers. The federation provider has two responsibilities. First, it maintains a trust relationship with partner issuers, which means that the federation provider accepts and understands Litware tokens and their claims, ACS tokens and their claims, and tokens and their claims from any other configured partner. Second, the federation provider needs to translate claims from partners and ACS into claims that a-Order can understand. The a-Order application only accepts claims from Adatum's federation provider (this is its trusted issuer). In this scenario, a-Order expects claims of type Role and Organization in order to authorize operations on its web site. The problem is that ACS claims don't come from Adatum and they don't have these claim types. In the scenario, the claims from ACS only establish that a social identity provider has authenticated the user. To solve this problem, the Adatum federation provider uses mapping rules that add a Role claim to the claims from ACS.

      Bharath Says:
      	Different social identity providers return different claims to ACS: for example, the Windows Live ID identity provider only returns a guid-like nameidentifier claim, the Google identity provider returns name and email claims in addition to the nameidentifier claim.

      Trust Relationships with Social Identity Providers

      The nature of a trust relationship between Adatum and a business partner such as Litware, is subtly different from a trust relationship between Adatum and a social identity provider such as Google or Windows Live. In the case of a trust relationship between Adatum and a business partner such as Litware, the trust operates at two levels; there is a business trust relationship characterized by business contracts and agreements, and a technical trust relationship characterized by the configuration of the Adatum federation provider to trust tokens issued by the Litware identity provider. In the case of a trust relationship between Adatum and a social identity provider such as Windows Live, the trust is only a technical trust; there is no business relationship between Adatum and Windows Live. In this scenario, Adatum establishes a business trust relationship with the owner of the social identity when the owner enrolls to use the a-Order application and registers his or her social identity with Adatum. A further difference between the two scenarios is in the claims issued by the identity providers. Adatum can trust the business partner to issue rich, accurate claims data about its employees such as cost centers, roles, and telephone numbers, in addition to identity claims such as name and email. The claims issued by a social identity provider are minimal, and may sometimes be just an identifier. Because there is no business trust relationship with the social identity provider, the only thing that Adatum knows for sure is that each individual with a social identity has a unique, unchanging identifier that Adatum can use to recognize that it's the same person returning to the a-Order application.

      Note

      An individual's unique identifier is unique to that instance of ACS: if Adatum creates a new ACS instance, each individual will have a new unique identifier. This is important to be aware of if you're using the unique identifier to map to other user data stored elsewhere.

      Description of Mapping Rules in a Federation Provider

      The claims that ACS returns from the social identity provider to the Adatum federation provider do not include the role or organization claims that the a-Order application uses to authorize access to order data. In some cases, the only claim from the social identity provider is the nameidentifier that is a guid-like string. The mapping in rules in the Adatum federation provider must add the role and organization claims to the token. In the sample, the mapping rules simply add the OrderTracker role, and "Mary Inc." as an organization.

      The following table summarizes the mapping rules that the Adatum federation provider applies when it receives a token from ACS when the user has authenticated with Google.

      Input claim	Output claim	Notes
      nameidentifier		A unique id allocated by Google.
      emailaddress		The users registered email address with Google. The user has agreed to share this address.
      name	name	The users name. This is the only claim passed through to the application. The issuer property of the claim is set to adatum, and the originalissuer is set to acs\Google.
      identityprovider		Google
      	Role	The simulated issuer adds this claim with a value of "Order Tracker."
      	Organization	The simulated issuer adds this claim with a value of "MaryInc."

      The following table summarizes the mapping rules that the simulated issuer applies when it receives a token from ACS when the user has authenticated with Windows Live ID.

      Input claim	Output claim	Notes
      nameidentifier		A unique id allocated by Windows Live ID.
      identityprovider		uri:WindowsLiveID
      	name	The simulated issuer copies the value of the nameidentifier claim to the name claim. The issuer property of the claim is set to adatum, and the originalissuer is set to acs\LiveID.
      	Role	The simulated issuer adds this claim with a value of "Order Tracker."
      	Organization	The simulated issuer adds this claim with a value of "MaryInc."

      The following table summarizes the mapping rules that the simulated issuer applies when it receives a token from ACS when the user has been authenticated by a Facebook application.

      Input claim	Output claim	Notes
      nameidentifier		A unique id allocated by the Facebook application.
      identityprovider		Facebook-194130697287302. The number here uniquely identifies your Facebook application.
      name	name	The users name. This is the only claim passed through to the application. The issuer property of the claim is set to adatum, and the originalissuer is set to acs\Facebook.
      	Role	The simulated issuer adds this claim with a value of "Order Tracker."
      	Organization	The simulated issuer adds this claim with a value of "MaryInc."

      Bharath Says:

      These mappings are, of course, an example and for demonstration purposes only. Notice that as they stand, anyone authenticated by Google or Windows Live ID has access to the "Mary Inc." orders in the a-Order application. A real federation provider would probably check that the combination of identityprovider and nameidentifier claims is from a registered, valid user and look up in a local database their name, role, and organization.

      In the scenario described in this chapter, because of the small numbers of users involved, Adatum expects to manage the enrolment as a manual process. For a description of how this might be automated, see Chapter 7, "Federated Identity with Multiple Partners and Microsoft Azure Access Control Service."

      Alternative Solutions

      Of course, the solution we've just described illustrates just one implementation choice; another possibility would be to separate Adatum's identity provider and federation provider and let ACS manage the federation and the claims transformation. Figure 2 shows the trust relationships that Adatum would need to configure for this solution.

      

      Figure 2

      Using ACS to manage the federation with Adatum's partners

      In this alternative solution, ACS would trust the Adatum and Litware identity providers and there is no longer a trust relationship between the Litware and Adatum issuers. Adatum should also evaluate the costs of this solution because there will be additional ACS transactions as it handles sign-ins from users at partners with their own identity providers. These costs need to be compared with the cost of running and managing this service on-premises.

      Bharath Says:
      	Adatum has already invested in its own identity infrastructure and has an existing federation provider running in their own datacenter. As a rather risk-averse organization, Adatum prefers to continue to use their tried and tested solution rather than migrate the functionality to ACS.

      A second alternative solution does away with ACS leaving all the responsibilities for protocol transition and claims transformation to the issuer at Adatum. Figure 3 shows the trust relationships that Adatum would need to configure for this solution.

      

      Figure 3

      Using the Adatum issuer for all federation tasks

      Although this alternative solution means that Adatum does not need to pay any of the subscription charges associated with using ACS, Adatum is concerned about the additional complexity of its issuer, which would now need to handle all of the protocol transition and claims transformation tasks. Furthermore, implementing this scenario would probably take some time (weeks or months), while Adatum could probably configure the solution with ACS in a matter of hours. The question becomes one of business efficiency: would Adatum get a better return by investing in creating and maintaining infrastructure services, or by focusing on their core business services?

      Jana Says:
      	This alternative removes a dependency on ACS: an external, third-party service. It still relies on the social identity providers for their authentication services.

      Inside the Implementation

      The Visual Studio solution named 6-FederationWithAcs found at https://claimsid.codeplex.com is an example of how to use federation with ACS. The structure of the application is very similar to what you saw in chapter 4, "Federated Identity for Web Applications." There are no changes to the a-Order application: it continues to trust the Adatum simulated issuer that provides it with the claims required to authorize access to the application's data.

      The example solution extends the Adatum simulated issuer to handle federation with ACS, and uses an ACS instance that is configured to trust the social identity providers. The next section describes these changes.

      Setup and Physical Deployment

      You can see the entry for ACS (https://federationwithacs-dev.accesscontrol.windows.net/) in the issuerNameRegistry section of the Web.config file in the Adatum.SimulatedIssuer.6 project. This entry includes the thumbprint used to verify the token that the Adatum federation provider receives from ACS. This is the address of the ACS instance created for the sample.

      Poe Says:
      	You can select the certificate that ACS uses to sign the token it issues to the Adatum federation provider in the Azure AppFabric portal.

      When the developers at Adatum want to deploy their application, they will modify the configuration so that it uses the Adatum federation provider. They will also modify the configuration of the Adatum federation provider by adding a trust relationship with the production ACS instance.

      Establishing a Trust Relationship with ACS

      Establishing a trust relationship with ACS is very similar to establishing a trust relationship with any other issuer. Generally, there are six steps in this process:

      1. Configure Adatum's issuer to recognize your ACS instance as a trusted identity provider.

         Note

         You may be able to configure the Adatum issuer automatically by providing a link to the FederationMetadata.xml file for the ACS namespace. However, this FederationMetadata.xml will not include details of all the claims that your ACS namespace offers, it only includes the nameidentifier and identityprovider claims. You will need to configure details of other claim types offered by ACS manually in the Adatum issuer.

      2. Configure the social identity providers that you want to support in ACS.

      3. Configure your ACS instance to accept requests from the Adatum issuer (the Adatum issuer is a relying party as far as ACS is concerned.)

      4. Edit the claims rules in ACS to pass the claims from the social identity provider through to the Adatum issuer.

      5. If necessary, edit the claims transformation rules in the Adatum issuer that are specific to the social identity providers.

      6. If necessary, edit the claims rules in the Adatum issuer that are specific to the a-Order application.

      You can refer to documentation provided by your production issuer for instructions on how to perform these steps. You can find detailed instructions for the ACS configuration in Appendix E of this guide.

      Reporting Errors from ACS

      You can specify a URL that points to an error page for each relying party that you define in ACS. In the sample, this page is called ErrorPage.aspx and you can find it in the Adatum.FederationProvider.6 project. If ACS detects an error during processing, it can post JavaScript Object Notation (JSON) encoded error information to this page. The code-behind for this page illustrates a simple approach for displaying this error information; in practice, you may want to log these errors and take different actions depending on the specific error that occurs.

      Markus Says:
      	It's important to mark ErrorPage.aspx as un-authenticated in the web.config file to avoid the risk of recursive redirects.

      Note

      An easy way to generate an error in the sample so that you can see how the error processing works is to try to authenticate using a Google ID, but to decline to give consent for ACS to access your data by clicking on No thanks after you have logged into Google.

      Initializing ACS

      The sample application includes a set of pre-configured partners for Fabrikam Shipping, both with and without their own identity providers. These partners require identity providers, relying parties, and claims-mapping rules in ACS in order to function. The ACS.Setup.6 project in the solution is a basic console application that you can run to add the necessary configuration data for the pre-configured partners to your ACS instance. It uses the ACS Management API and the wrapper classes in the ACS.ServiceManagementWrapper project.

      Note

      You will still need to perform some manual configuration steps; the ACS Management API does not enable you to create a new service namespace. You must perform this operation in the ACS management portal.

      For more information on working with ACS, see Appendix E.

      Working with Social Identity Providers

      The solution described in this chapter enables Adatum to support users with identities from trusted partners such as Litware, and with identities from social identity providers such as Google or Windows Live ID. Implementing this scenario in the real world would require solutions to two additional problems.

      First, there is the question of managing how we define the set of identities (authenticated by one of the social identity providers) that are members of the same organization. For example, which set of users with Windows Live IDs and Google IDs are associated with the organization Mary Inc? With a partner such as Litware with its own identity provider, Adatum trusts Litware to decide which users at Litware should be able to view the order data that belongs to Litware.

      Second, there are differences between the claims returned from the social identity providers. In particular, Windows Live ID only returns the nameidentifier claim. This is a guid-like string that Windows Live guarantees to remain unchanged for any particular Windows Live ID within the current ACS namespace. All we can tell from this claim is that that this instance of ACS and Windows Live have authenticated the same person, provided we get the same nameidentifier value returned. There are no claims that give us the user's email address or name.

      The following potential solutions make these assumptions about Adatum.

      • Adatum does not want to make any changes to the a-Order application to accommodate the requirements of a particular partner.
      • Adatum wants to do all of its claims processing in the Adatum federation provider. Adatum is using ACS just for protocol transition, passing through any claims from the social identity providers directly to the Adatum federation provider.

      Managing Users with Social Identities

      Taking Litware as an example, let's recap how the relationship with a partner organization works.

      • Adatum configures the Adatum federation provider to trust the Litware identity provider. This is a one-time, manual configuration step in this scenario.
      • Adatum adds a set of claims-mapping rules to the Adatum federation provider, to convert claims from Litware into claims that the Adatum a-Order application understands. In this scenario, the relevant claims that the a-Order application expects to see are name, Role and Organization.

        Poe says:
        	The Adatum federation provider should generate the Organization claim rather than pass in through from Litware. This mitigates the risk that a malicious administrator at Litware could configure the Litware identity provider to issue a claim using another organization's identity.

        - Litware can authorize any of its employees to access the Adatum a-Order application by ensuring that Litware's identity provider gives the user the correct claim. In other words, Litware controls who has access to Litware's data in the Adatum a-Order application.

        The situation for a smaller partner organization without its own identity provider is a little different. Let's take MaryInc, which wants to use Windows Live IDs and Google IDs as an example.

        • Unlike a partner with its own identity provider, there is no need to set up a new trust relationship because Adatum already trusts ACS. From the perspective of the Adatum federation provider, ACS is where the MaryInc employee claims will originate.
        • The Adatum federation provider cannot identify the partner organization of the authenticated user from the claims it receives from ACS. Therefore, Adatum must configure a set of mapping rules in the federation provider that map a user's unique claim from ACS (such as the nameidentifier claim) to appropriate values for the name, Role and Organization claims that the a-Order application expects to see.
        • If MaryInc wants to allow multiple employees to access MaryInc data in the a-Order application, then Adatum must manually configure additional mapping rules in its federation provider.

        This last point highlights the significant difference between the partner with its own identity provider and the partner without. The partner with its own identity provider can manage who has access to its data in the a-Order application; the partner without its own identity provider must rely on Adatum to make changes in the Adatum federation provider if it wants to change who has access to its data.

        Working with Windows Live IDs

        Unlike the other social identity providers supported by ACS that all return name and emailaddress claims, Windows Live ID only returns a nameidentifier claim. This means that the Adatum federation provider must use some additional logic to determine appropriate values for the name, Role and Organization claims that the a-Order application expects to see.

        This means that when someone with a Windows Live ID enrolls to use the Adatum a-Order application, Adatum must capture values for the nameidentifier, name, Role and Organization claims to use in the mapping rules in the federation provider (as well as any other data that Adatum requires). The only way to discover the nameidentifier value is to capture the claim that Windows Live returns after the user signs in, so part of the enrollment process at Adatum must include the user authenticating with Windows Live.

        Note

        It is possible to access data in the user's Windows Live ID profile, such as the user's name and email address, programmatically by using Windows Live Messenger Connect. This would eliminate the requirement that the user manually enter information such as his name and email address when he enrolled to use the a-Order application. However, the benefits to the users may not outweigh the costs of implementing this solution. Furthermore, not all users will understand the implications of temporarily giving consent to Adatum to access to their Windows Live ID profile data.

        With ADFS you can create custom claims transformation modules that, for example, allow you to implement a mapping rule based on data retrieved from a relational database. With this in mind, the enrollment process for new users of the Adatum a-Order application could populate a database table with the values required for a user's set of claims.

        Working with Facebook

        The sample application enables you to use Facebook as one of the supported social identity providers. Adding support for Facebook did not require any changes to the a-Order web application. However, there are differences in the way the Adatum federation provider supports Facebook as compared to the other social identity providers, and differences in the ACS configuration.

        Configuring Facebook as an identity provider in ACS requires some additional data; an Application ID that identifies your Facebook application, an Application secret to authenticate with your Facebook application, and a list of claims that ACS will request from Facebook. The additional configuration values enable you to configure multiple Facebook applications as identity providers for your relying party.

        Each set of Facebook application credentials is treated as a separate identity provider in ACS.

        The implication for the Adatum federation provider is that it must be able to identify the Facebook application to use for authentication in the whr parameter that it passes to ACS. The following code sample from the FederationIssuers class in the Adatum federation provider shows how the Facebook application ID is included in the whr value.

        // Facebook
        homeRealmIdentifier = "facebook.com";
        issuerLocation = Federation. AcsIssuerEndpoint;
        whr = "Facebook-194130697287302";
        this.issuers.Add(homeRealmIdentifier,
          new IssuerInfo(homeRealmIdentifier, issuerLocation, whr));
        

        Questions

        1. Which of the following issues must you address if you want to allow users of your application to authenticate with a social identity provider such as Google or Windows Live® network of Internet services?
           1. Social identity providers may use protocols other than WS-Federation to exchange claims tokens.
           2. You must register your application with the social identity provider.
           3. Different social identity providers issue different claim types.
           4. You must provide a mechanism to enroll users using social identities with your application.
        2. What are the advantages of allowing users to authenticate to use your application with a social identity?
           1. The user doesn't need to remember yet another username and password.
           2. It reduces the features that you must implement in your application.
           3. Social identity providers all use the same protocol to transfer tokens and claims.
           4. It puts the user in control of their password management. For example, a user can recover a forgotten password without calling your helpdesk.
        3. What are the potential disadvantages of using ACS as your federation provider?
           1. It adds to the complexity of your relying party application.
           2. It adds an extra step to the authentication process, which negatively impacts the user experience.
           3. It is a metered service, so you must pay for each token that it issues.
           4. Your application now relies on an external service that is outside of its control.
        4. How can your federation provider determine which identity provider to use (perform home realm discovery) when an unauthenticated user accesses the application?
           1. Present the user with a list of identity providers to choose from.
           2. Analyze the IP address of the originating request.
           3. Prompt the user for an email address, and then parse it to determine the user's security domain.
           4. Examine the ClaimsPrincipal object for the user's current session.
        5. In the scenario described in this chapter, the Adatum federation provider trusts ACS, which in turn trusts the social identity providers such as Windows Live and Google. Why does the Adatum federation provider not trust the social identity providers directly?
           1. It's not possible to configure the Adatum federation provider to trust the social identity providers because the social identity providers do not make the certificates required for a trust relationship available.
           2. ACS automatically performs the protocol transition.
           3. ACS is necessary to perform the claims mapping.
           4. Without ACS, it's not possible to allow Adatum employees to access the application over the web.

        More Information

        Appendix E of this guide provides a detailed description of ACS and its features.

        You can find the MSDN® documentation for ACS 2.0 at https://msdn.microsoft.com/en-us/library/gg429786.aspx.

        Next | Home