Chapter 14

AppFabric: Access Control Service

What’s in this chapter?

• Using the Access Control Service to secure web applications with Windows Live ID and Google ID
• Integrating the Access Control Service log on page into your application
• Setting up single sign-on from the local network to the cloud

Security is one of the key aspects of cloud computing. Often, cloud applications run in the public space, so managing who has access is crucial. Also, business applications that run in the cloud should be as accessible as if they were running in the local network. The Access Control Service helps you with these scenarios.

What Is the Access Control Service?

In Chapter 9, “Identity in Azure,” you learned about identity federation with Windows Identity Foundation (WIF); you built your own Security Token Service (STS) to provide tokens for authentication and authorization with websites and web services with a trust relationship on that STS. Because of the importance of the STS, building your own STS may not be the best idea from a security perspective. Most of the time, you should rely on a battle-tested STS, such as Active Directory Federation Services (ADFS) 2.0. For Windows Azure the Access Control Service (ACS) is the STS of choice. Not just because it is part of the Windows Azure suite of services, but also because it supports several ways to authenticate and several protocols. In addition, ACS is a cloud-based solution, so new features are added more quickly than with traditional software packages.

Access Control Service Architecture

The key to the flexibility of ACS lies in its architecture. ACS acts as a universal adapter, supporting multiple identity providers, authentication and authorization protocols, and token formats. Contrary to the STS you built in Chapter 9, ACS is not an Identity Provider (IdP). As shown in the architecture in Figure 14-1, ACS relies on external services such as Windows Live ID (default), Facebook, and ADFS 2.0 to identify users. The latter option makes it possible to integrate with the Active Directory of your local network, so users can use their network credentials to access applications (relying parties) connected to ACS. These applications don’t necessarily need to be hosted inside Windows Azure. Any relying party that trusts ACS and is accessible to the user will work.

Figure 14-1

ACS basically consists of four components (refer to Figure 14-1):

• The STS issues tokens for use with applications that trust ACS.
• The STS uses the Token Transformation Rule Engine to transform an incoming token from an identity provider to an ACS token trusted by the relying parties.
• The rules in the Rule Engine determine which information is passed in the token and may add additional claims.
• The Rule Engine can be managed either through the Management Portal or through a custom application using the Management API.

The Management Portal and Management API also manage configuration of identity providers within ACS, as well as the trust relationship between ACS and relying parties that accept tokens from ACS.

Access Control Service Fundamentals

ACS is a cloud service, so you must share it with others. As with the Service Bus discussed in Chapter 13, you define a Service Namespace to create your own ACS environment. You can create multiple namespaces if you have environments you want to keep separated. This can be useful to separate test and production environments, different groups of applications, different groups of users, and so on.

Identity Providers

Within a Service Namespace you can configure multiple identity providers and multiple relying parties. You can also configure which identity providers are valid for which relying parties. Windows Live ID is configured as an identity provider out-of-the-box, and Google or Yahoo are available preconfigured, so you can add these easily. If you want to use Facebook, you first must create a Facebook application, so that’s a little more work. With the Management Portal you can add any identity provider using WS-Federation, such as ADFS 2.0. With ADFS 2.0 you can authenticate using a Windows account, which you can do with a username and password, but also with a client certificate or smartcard, enabling multifactor authentication. The Management Service also enables you to add OpenID 2.0–based identity providers.

One of the major advantages of ACS reliance on external identity providers is that it is up to ACS to stay up to date when the identity provider changes its protocol. When Facebook changed its protocol, applications that used ACS were shielded from those changes and continued to work as if nothing had happened.

The limited number of identity providers (currently) supported may seem a major restriction, but because ACS supports both WS-Federation and OpenID, it is perfectly acceptable to create your own authentication mechanism. You can also construct a protocol bridge to another authentication mechanism, as shown in Figure 14-2. Such a protocol bridge isn’t hard to construct if you use the Visual Studio template for a STS, as discussed in Chapter 9, although you must tighten the security of the code you get from the template.

Figure 14-2

Service Identities and Management Service Accounts

Not all identity providers lend themselves well to doing service-to-service communication without user interaction. For this purpose ACS also provides a concept known as a Service Identity. This is an identity you define within ACS, so ACS is the identity provider. A service can then authenticate with ACS using a username-password combination, X.509 certificate, or symmetric key. How to use this is discussed in more detail in the section “Working with Service Identities.”

The Management Service of ACS is accessed in a similar fashion as you would access services using a Service Identity. Accounts for the Management Service have exactly the same properties, but these accounts apply only to the Management Service.

Supported Protocols

To authorize users with applications, ACS defaults to WS-Trust and WS-Federation, but ACS also supports OAuth Web Resource Authorization Protocol (OAuth WRAP) and OAuth. OAuth is an open standard that enables users to hand out tokens for authorization to data hosted by a service provider (application). OAuth tokens can authorize for parts of the data and with limited access rights. An example is a token that grants a photo print service access to a selection of pictures on a site such as Flickr or Picasa. OAuth 2.0 is the current version of the standard, but although OAuth WRAP is deprecated, ACS supports it for backward compatibility with existing applications.

Available Token Formats

The following are the token formats ACS supports:

• Security Assertion Markup Language (SAML) 1.1: SAML is an XML format and standard governed by the Organization for the Advancement of Structures Information Standards (OASIS). SAML 1.1 is supported by WIF and is used in Chapter 9.
• SAML 2.0: The most recent version of the SAML token format.
• Simple Web Token (SWT): This is basically a string of key-value pairs with a signature; although it also contains information about the issuer, the application the token applies to, and when the token expires. The simplicity of SWT makes it easier to use this format with applications not natively supporting a token format.

Rules and Rule Groups

What goes into a token sent to a relying party is governed by rules. These rules can look at the incoming claims and determine which claims are placed in the outgoing token. Rules are grouped in rule groups. All rules in a rule group are executed if a token is created for a relying party for which the rule group is enabled. You can create multiple rule groups, and you can enable multiple rule groups to a relying party. Also, a rule group can apply to multiple relying parties. A rule is scope for a particular identity provider, so whether the rule fires depends on whether it applies to the identity provider used by the user.

Getting Started with the Access Control Service

Now that you understand what the Access Control Service is, and how it is structured, you can start to work with it. That means setting up ACS and setting up applications to make use of the tokens ACS provides.

Creating a Service Namespace

The first thing you need to do is set up a Service Namespace, as shown in the following steps. You do this from the Management Portal under Service Bus, Access Control & Caching.

Figure 14-3

After the Service Namespace is created, you can select it in the Management Portal, and click Access Control Service in the Manage Access Control section of the taskbar. This redirects you to the aforementioned URL. You can also go to the URL directly and log in with Windows Live ID, if you’re not already logged in.

Securing a Web Application

After you create a Service Namespace, you can start with enabling applications to accept authentication through ACS. For applications using WIF, this doesn’t differ much from what you learned in Chapter 9, although ACS works differently than an STS you create. You need to create a web application.

The preceding steps should be familiar to you from Chapter 9. Now you need to hook up the application to ACS. You need to ensure the application accepts tokens from ACS.

Figure 14-4

The error in Figure 14-4 happens because the application hasn’t been configured yet as a relying party in ACS. ACS issues tokens only to applications it knows about, so other people can’t use your ACS and run up the costs. There is also a security aspect to this. If a token sent to an application contains information about the user only some applications should know about, then sending tokens to any application asking for one would result in a security breach. The following steps register the application with ACS.

If you run the application now, you will be asked to log in with your Windows Live ID, unless you’re still logged into your ACS Management Portal because then you’re already logged in. If you want to check if you need to log in, start a private browsing session in your browser.

After logging in, you will receive another error from ACS, which is shown in Figure 14-5. That’s because although a rule group has been created for the relying party, it contains no rules. Therefore, the generated token will be empty, and that’s not allowed. To solve this, you must add rules to the rule group.

Now when you run the application you will no longer get an error from ACS. Instead, you will get the dangerous request exception you also received in Chapter 9. You must add the WifRequestValidator discussed in Chapter 9 to solve this issue. After you do that, you’re logged into the website, which indicates this in the top right. However, on closer inspection you’ll note there is no username. The problem is that Windows Live ID actually doesn’t give you a name claim, which is what WIF uses as the username, by default. You can solve this in two ways:

• Modify WIF to use another claim type for the username.
• Modify the generated rule to transform the incoming claim type to the name claim type.

Figure 14-5

The latter makes more sense because if you ever switch to another STS, the name claim might be available again. Also, using rules you can unify identifiers coming in from different identity providers because these are likely to differ.

To modify the generated rule, follow these steps:

Now when you log in again through ACS you’ll find an identifier behind the Welcome message. Because Windows Live ID uses your e-mail address as the login name, you may have expected that to be in the nameidentifier claim. As you can see in Figure 14-6, that is not the case. The only thing you get is some unique identifier of the user. You can use that identifier to store information in your application about the user. If you require information beyond the unique identifier, you must store that in your own database. This includes any authorizations you may want to give the user.

Figure 14-6

Because the nameidentifier claim is not a name, you can’t use it for display purposes. If you intend to have a username displayed coming from data within the application, it is better not to transform the claim as shown here. That way you can fill in the name value yourself.

Configuring Additional Identity Providers

Authenticating users through Windows Live ID, which is the default for ACS, may work fine for your application; it probably beats building your own functionality to log in, recover a forgotten password, and so on. The downside, of course, is that your users require a Windows Live ID, and you can safely assume that not all users have one or are inclined to get one. However, if you add Google and Yahoo! as identity providers, you’ll cover a lot more people, and your users can choose which provider they use. If they don’t have an account with any of these providers, they can create one with the provider they trust the most. Adding these providers is easy.

Figure 14-7

As you can see in Figure 14-7, you can change the text of the login link and set an image to be shown with the login link. What you enter there is used on the page the user sees when an application sends the user to ACS to log in. There the user can select the login method by clicking the appropriate link. This page is also known as the home realm discovery page. The home realm is the network where you come from or where you log in. This name is misleading for Google or Yahoo! because you are not on the network of one of those companies (unless you happen to work there).

As you can also see in Figure 14-7, you can also select which relying parties the identity provider applies to. By default, all configured relying parties are selected. A reason why you may want to change this could be that you have an application that should be accessible only to users in your own network through ADFS, whereas other applications must be available for users outside the company. Because you can differentiate between identity providers, there is no need to set up a separate Service Namespace for this scenario.

Because the current rule group works only with Windows Live ID, you still need to add a rule for Google.

Figure 14-8

Google provides ACS with more information about the user than Windows Live ID. In addition to the nameidentifier claim, you also get the name and e-mail address of the user. This ties back to the earlier comments about whether it’s a good idea to transform the nameidentifier claim that Windows Live ID provides to a name claim.

Because there are now two identity providers configured in ACS for your application, you are not sent to Windows Live ID directly when you start the application. Instead, you are sent to the home realm discovery page, which is shown in Figure 14-9. From the home realm discovery page, you can choose how you want to log in. If you now choose Google, you can log in with any Google account. After you’re authenticated, and you have given Google permission to share your information with your ACS Service Namespace, you’re logged in to the application and your name is shown in the Welcome message.

Figure 14-9

Customizing the Access Control Service

The Access Control Service (ACS) is more than just a gateway that provides users with the ability to log on using identity providers such as Windows Live ID, Google ID, and so on. It is a platform that supports many access control scenarios through the different protocols it supports. It also provides extensibility points you can use to customize and manage how ACS works for you.

Enhancing the Login Experience

Up until now the login experience was quite simple. When you start the sample application, you are immediately sent to ACS because all pages are secured. WIF crafts the correct login link from configuration, which was built with FedUtil. When you reach ACS, it either shows you the home realm discovery page, or sends you to the identity provider if only one is configured. This works fine but doesn’t work as well if your users come into a page that’s public, and if you have pages that contain both public and personalized content. Also, the home realm discovery page hosted by ACS is functional, but it doesn’t shine in the design department.

ACS provides two login options, which you can find in the ACS Management Portal by following these steps:

You are now presented with information for both login options, which are discussed in more detail in the next two sections.

Linking to the Login Page

The first option you have is to link to ACS yourself. This doesn’t make the graphical design any better, but it does give you more control over what happens when a user logs in. To embed it in the application, take the following steps.

Step 4 is crucial. The link provided by ACS is missing information for WIF to recognize the response from ACS as a sign in response. Adding a properly formatted wctx parameter to the querystring fixes that. The wctx parameter sends context information in the request to ACS (or any other STS) that gets passed around and back to the requestor, so the requestor can give itself information on how to process the response to its own request. The string in step 4 is URL-encoded and contains three name-value pairs:

• rm=0
• id=passive
• ru=/

The first two help WIF identify the passive federation response. The third, which actually has a double URL encoding because the value is a forward slash, indicates which page to go to after the sign-in has been processed. Because the steps currently have this code, it redirects you to the home page. If you want to redirect to another page, all you need to do is add the path, keeping in mind that you must replace a forward slash with %252f. Also, don’t forget to encode the URL and querystring you want to send along.

Hosting a Custom Login Page

Because the default home realm discovery page doesn’t look nice, and likely doesn’t fit the design of your application, you may want to provide your own. ACS provides you with a JSON feed to accomplish this. The JSON feed contains an entry for each configured identity provider available for the relying party. Each entry contains the values listed in Table 14-1.

Table 14-1: ACS Home Realm Discovery JSON Feed Values

The most important value in Table 14-1 is the login URL. As you saw in the previous paragraph, it needs to be tweaked to ensure WIF recognizes the sign in response. Also a slight mistake can actually make ACS return an error. If you use the default URL or use the example login provided in the ACS Management Portal, logging in to the relying party doesn’t work. You can fix this by altering the parameters sent to ACS to get the JSON feed. Table 14-2 shows the URL parameters you can use to alter the login URL.

Table 14-2: Parameters for the Home Realm Discovery JSON Feed

From Table 14-2, the context parameter is what you need to use to get a login URL that works with WIF. Its value should be exactly the same as the wctx parameter you used earlier.

When you use the reply_to parameter to specify the return URL, you will likely get an ACS error—and not the desired effect. You can configure the return URL in the context parameter as shown earlier with the wctx parameter.

To create a working self-hosted login page, take the following steps:

When you run the application and click the Login link, you see the login page you just added to the application. It looks the same as the page hosted in ACS, except that the background is now bright red. That, of course, is only so you can see that you are actually viewing the page you added instead of the ACS hosted page. You can modify the design of the page as you see fit and integrate it into an application to align with the technology you use (for example: ASP.NET MVC, PHP). You can find more samples to integrate with ACS in the Codeplex site setup for ACS 2.0 samples and documentation at http://acs.codeplex.com/. There you can also find samples to use for other protocols.

Working with Service Identities

If you want to secure web services with ACS, you can’t use any of the external identity providers. You need to authenticate with ACS directly. This is what Service Identities are for. A Service Identity is a credential that a client can use to request a token to access a web service. This works using active federation, as discussed in Chapter 9, and works with the same types of bindings using the WS-Federation protocol. As discussed earlier, ACS also supports other protocols, for which you can find samples and documentation at http://acs.codeplex.com/. However, if you use .NET, why would you deviate from what you already know and the standard supported by Windows Identity Foundation?

Creating a Relying Party Service

Creating a WCF service in Windows Azure is similar to what you learned in Chapter 9. However, because the STS is already there, you don’t need to create it. Also, you can take a few shortcuts to speed up the process. The first thing you need to do is create a service. It makes sense to run it only under HTTPS, so instead of first going through the motions to make a basic service and connect the client, you can set it up under HTTPS directly.

1. Create a new cloud project called AcsActiveRP.

2. Add a WCF Service Web Role to the solution and call it WcfWebRoleRP.

3. Open the WcfWebRoleRP configuration and go to Endpoints.

4. Change the protocol of Endpoint1 to https and set the public port to port 8443.

5. Save the configuration.

6. Open Web.config.

7. Find the <serviceMetadata> element and change the httpGetEnabled attribute to httpsGetEnabled.

8. In the same behavior add the configuration to use the request headers for the meta data as you learned in Chapter 9 with the following XML:

<useRequestHeadersForMetadataAddress>
  <defaultPorts>
    <add scheme="https" port="8443" />
  </defaultPorts>
</useRequestHeadersForMetadataAddress>

code snippet 01_MetadataRequestHeadersConfig.txt

9. Because you’re not going to expose the service on HTTP first, you need to add a binding and a service endpoint configuration that uses HTTPS. The following configuration takes care of that:

<bindings>
  <basicHttpBinding>
    <binding name="myBinding">
      <security mode="Transport">
        <transport clientCredentialType="None" />
      </security>
    </binding>
  </basicHttpBinding>
</bindings>
<services>
  <service name="WcfWebRoleRP.Service1">
    <endpoint address=""
              binding="basicHttpBinding"
              bindingConfiguration="myBinding"
              contract="WcfWebRoleRP.IService1" />
  </service>
</services>

code snippet 02_HttpsBasicHttpEndpointConfig.txt

After you create the service, you can hook it up to ACS. This is a two-step process. First, use FedUtil to set the appropriate configuration on the server, and then register the relying party with ACS. As you’ve learned in Chapter 9, the devil is in the details when it comes to using WIF, and to ensure you do it correctly follow these steps.

Service1 is spelled with a capital letter. This value is used in the audience URI configuration, which needs to match exactly with the audience URI in the token.

At this point the configuration is nearly correct. There are just two issues you need to correct:

• The ws2007FederationHttpBinding is now configured for Message security, and as such it doesn’t take into account that the service is running under HTTPS. You can solve this by changing

  <security mode="Message">

<security mode="TransportWithMessageCredential">

• The endpoint is configured with an absolute address, even though the following is also configured:

  <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />

With these issues resolved, there is one more thing you need to do: ensure the WSDL is accessible. To do this, add the following configuration to enable the Metadata Exchange endpoint:

<endpoint address="mex"
          binding="mexHttpsBinding"
          contract="IMetadataExchange" />

code snippet 03_MetadataExchangeConfig.txt

Configuring ACS

With the service done it’s time to shift your attention to ACS. There you need to configure the relying party and the Service Identity. Start with the former.

In step 5, the credential type of choice is Password, which translates to a username and password combination when you call the service. If you prefer stronger security, you can also use Symmetric Key or an X.509 certificate. With the former you just specify the key, without a username. With the latter you use a certificate in ACS for which you have the certificate with private key installed on the service side. Of these options using an X.509 certificate is by far the most secure because it is much harder to copy around certificates than simple strings. If you elect to use a certificate, you are prompted to upload the .cer file of the certificate you want to use. You learn how to deal with this in the client later.

After setting up the Service Identity, you can set up the relying party. This is just like setting up a relying party for passive federation. The user interface is geared toward passive federation, but don’t let that fool you. It just means that you can skip some information because, for instance, a return URL is not used for active federation. The following steps take you through the process.

The relying party configuration is now done, but there are no rules yet in the rule group. Without at least one rule, a valid token can’t be created when the client requests a token. A service identity doesn’t have a lot of information associated with it, so the rule can be a simple Passthrough rule. A Passthrough rule, as the name suggests, passes through all claims coming from the issuer. Creating one is easy.

Creating the Client

With the service ready and ACS configured, the last step is to create a client that uses the service. First, you need to set up the service proxy by adding a service reference to the service you created.

When the service proxy is created, the configuration contains the necessary binding configuration. This configuration defaults to using a symmetric key for authentication. Previously you created a Service Identity with a password, so you need to change this. Fortunately, the ACS Federation Metadata not only contains the endpoint of the default authentication method, but also the alternative methods. Visual Studio adds all the alternative bindings, and as comments shows how you should change the custom binding to use one of the other methods. All you need to do is change to the correct method.

The last thing you need is the code to call the service, which is almost the same code you used in the chapter to call a service with the same signature. The difference is that now you can’t use your Windows identity, so you should provide a username and password. Listing 14-1 shows the modified code, which you should add to the Main method of Program.cs. The bolded lines show you the added lines, which provide the username and password.

Listing 14-1: Loop Calling the Service on User Input

while (true)
{
    Console.Write("Enter a value: ");
    var input = Console.ReadLine();
    if (string.IsNullOrEmpty(input)) break;
    int value;
    if (int.TryParse(input, out value))
    {
        var client = new ServiceReference1.Service1Client();
        client.ClientCredentials.UserName.UserName = "AcsServiceIdentity";
        client.ClientCredentials.UserName.Password = "Password";
        Console.WriteLine(client.GetData(value));
    }
}

If you run the client now, you should be able to call the service. The initial response may take a while, and sometimes the first call even times out. Don’t be alarmed, just try again. If you get any other exception than a timeout, check the error message to see what’s wrong. In the inner exception you will find an ACS error code and description.

Refining the Service

In Chapter 9, several modifications were made to the service up front to provide proper cookie handling in a load balanced environment such as Windows Azure. At this point the configuration is just a deafult ws2007FederationHttpBinding, so the changes needed for the load balanced environment haven’t been made yet. To get that operational, you need to modify the binding to be like the binding used in Chapter 9, and you need to set up SessionSecurityTokenHandler. Fortunately, changing the binding to the custom binding used in Chapter 9 has no effect on the client configuration. Everything will work fine.

Authenticating with a Client Certificate

Client certificates are an effective way of authentication. Certificates are tried and tested, and can use a large encryption key for optimal security. Because you need to explicitly install a certificate on both the client and the identity provider, in this case ACS, the chances of a security breach are much lower than with a username and password. With the latter a malicious programmer can just try username and password combinations. With certificates this isn’t quite so easy.

Setting up client authentication with ACS is fairly simple. In essence you need to create a certificate, upload it to ACS, and modify your application to use the certificate. With the following steps, you create a certificate and upload it to ACS.

With ACS all set, you need to modify the configuration of your client to use the certificate. This consists of two steps:

• Modifying the issuer like you did before
• Specifying the certificate to use

The first step is needed because ACS provides a different endpoint for each authentication type. Each authentication type uses a slightly different protocol configuration, so if you point the client to another endpoint, you also need to modify the protocol binding slightly. The following steps take care of that for certificate authentication.

1. Open app.config of AcsActiveClient.

2. Now replace the <issuer> element with the fourth alternative option, which ends in /v2/wstrust/13/certificate.

3. Add the following code to the <system.serviceModel> section:

<behaviors>
  <endpointBehaviors>
    <behavior name="ClientCredentialsBehavior">
      <clientCredentials>
        <clientCertificate
            storeLocation="CurrentUser"
            storeName="My"
            x509FindType="FindByThumbprint"
            findValue=""/>
      </clientCredentials>
    </behavior>
  </endpointBehaviors>
</behaviors>

code snippet 04_ClientCertificateBehaviorConfig.txt

4. Open the certificate file you created and go to the Details tab.

5. Scroll down to the Thumbprint property and select it, as shown in Figure 14-10 (without the leading space).

6. Copy the thumbprint and paste it into the behavior configuration as the value for the findValue attribute.

7. Find the endpoint configuration and add behaviorConfiguration="ClientCredentialsBehavior" to the element, so it looks like this configuration:

<endpoint address="https://127.0.0.1:8443/Service1.svc"
          binding="customBinding"
          bindingConfiguration="WS2007FederationHttpBinding_IService1"
          behaviorConfiguration="ClientCredentialsBehavior"
          contract="ServiceReference1.IService1"
          name="WS2007FederationHttpBinding_IService1" />

code snippet 05_CertificateBehaviorEndpointConfig.txt

Figure 14-10

Strictly speaking, step 9 is superfluous. The binding uses a certificate and the certificate to use is in the configuration. The username and password specified are just ignored because they are not used with the configured protocol.

Federating from a Local Network with ADFS 2.0

One of the great things about the way identity federation works is that the security token service and the relying party don’t necessarily need to contact each other. As long as the client can reach both, it can get a token from the STS and present it to the relying party. The trust relationship between the STS and the relying party ensures the token is accepted. This has two advantages:

• You can use your network credentials to sign in to an application running in Windows Azure.
• An STS in the local network is much less likely to be compromised.

This scenario was already briefly covered in Chapter 9 and shown in Figure 9-3, so before you actually learn how to set this up, you may want to reread that section.

The main ingredient for this scenario is Active Directory Federation Services 2.0 (ADFS), which acts as the STS in the local network. ADFS 2.0 is a free add-on for Windows Server 2008 and up.

Installing ADFS 2.0

To install ADFS 2.0 you need an Active Directory domain running on Windows Server 2008 or higher. For a domain you need to enable the Active Directory Domain Services (ADDS) role of Windows Server.

Setting up a Windows Server 2008 machine and installing ADDS is beyond the scope of this book, but you can find ADDS setup instructions at http://bit.ly/installadwin2008. Be sure to pick a domain name that doesn’t collide with online domains. You can ensure this by using the .local suffix. It’s also a good idea to use a meaningful domain name, for instance azuredemo.local.

Users with a domain account can use their credentials for authentication to acquire a token from ADFS 2.0. They can do so from outside the domain, providing they have access to the ADFS 2.0 server, in which case they are prompted for their credentials. If users are logged into the local domain, because their computer is tied to the domain and they work in the local network, they get a single sign-on (SSO) experience because the browser uses the credentials used to log on to the computer transparently.

After you set up the domain, you can install ADFS 2.0. ADFS 2.0 requires Internet Information Server, Windows Identity Foundation, Windows PowerShell, and several hotfixes. The installer checks for the prerequisites and installs these automatically if possible. Otherwise, you must install them manually. You can download the free ADFS 2.0 installer from http://bit.ly/adfs2rtw. You must take the following steps to perform a simple ADFS 2.0 installation:

With the previous steps, you install a single ADFS 2.0 service. There are however several different topologies. Which topology is best depends on your network setup, whether the service is available on a public address, and what your security level needs to be.

It is beyond the scope of this book to discuss the different topologies, but you can find more information in the ADFS 2.0 section of TechNet, and more specifically on the pages discussing the possible deployment topologies. You can find the latter at http://bit.ly/ADFS2Topo.

Adding ADFS 2.0 as Identity Provider

When you’ve installed ADFS 2.0 in your domain, you can add it as an identity provider for your ACS Service Namespace. If you use ADFS 2.0 to extend the reach of local network credentials to federate across the network boundary (and firewall), it is most likely that the ADFS 2.0 service is only available from the local network. Of course, it is not a requirement. However, if you plan to expose ADFS 2.0 to the outside world, you (or the system administrator) should be aware of the design considerations that go with that. The aforementioned section of TechNet and the link to deployment topologies are required reading in that case. If you expose ADFS 2.0 to the outside world, ACS can reach the federation meta data file. Otherwise, you need to store it locally and upload it to ACS, as is done in the following configuration steps.

When you check the rules that are part of the default rule group, there are quite a few now; you need to page through the list of rules to see all of them. Through the federation meta data, ADFS 2.0 exposes all the claim types it is capable of producing, including any custom claim types you may have configured. However, by default ADFS 2.0 does not send any claim to the relying party unless it has been configured to send specific claims. The claim types listed in the federation meta data are claim types that ADFS 2.0 could expose based on the data you could store about users in Active Directory.

Because ADFS 2.0 publishes so many possible claim types, it makes sense to actually create a separate rule group for it. That way you can more easily keep it apart from other identity providers.

Making ACS an ADFS Relying Party

That ACS has read the federation meta data and configured ADFS 2.0 as an identity provider is only half the process. ADFS 2.0 won’t issue a token unless it knows the relying party, in this case ACS. To make ACS a known relying party, take the following steps:

After completing the previous steps, everything should work. You can test this with the AcsPassiveRP project you created earlier.

These steps should log you in and show the website with the username including the NETBIOS domain name, which is AZUREDEMO in this case.

Modifying the Token with Rule Groups

Earlier in the chapter you learned how to adjust a token to transform an incoming claim to another, so you could use it as the username. Depending on the identity provider, you can get few or quite a few claims, and you can pass these through or create new claims based on them. It does not matter how many claims you receive; you can create as many derivative claims as you like.

The Anatomy of a Rule

Rule groups are all about rules. A rule group is just a container of rules, making it easier to manage rules. You already created some simple rules, so you probably have some idea of how they work. Basically, a rule is an if-statement. It adds a claim to a token if certain conditions are met. These conditions are tested against an incoming claim. The conditions consist of three parts:

• The issuer of the claim
• The type of the claim
• The value of the claim

If all these conditions are met, the Then portion of the rule is executed and a claim is added to the token sent to the relying party. The issuer of the incoming claim can be either of the configured identity providers or the ACS itself. The latter is the case with a Service Identity, but also when the rule acts on a result of another claim rule. This implies that rule processing actually happens in two steps, as shown in Figure 14-11.

Figure 14-11

The input claim type determines which name-value pair is evaluated. Unless you are passing through everything that comes in, you must specify a specific type. For preconfigured identity providers, ACS knows which types it can receive, and you can select those types from the drop-down. You can also specify it manually in the textbox, but this doesn’t make sense for identity providers with known claim types. If you connected an identity provider using the Federation Metadata file, like you learned with ADFS, the claim types are also known up front because these are specified in the Federation Metadata.

The claim value is a string that is checked if you specify one. Otherwise, the existence of the type is enough for the Then portion of the rule to be executed. This most often is used in pass-through scenarios.

In the Then portion of a rule, you again must specify the claim type and the claim value. You can pass through both from the If portion, or just the type or the value. Of course, you can also define a completely new type and value. You can either specify the type manually or select the type from the drop-down. The drop-down consists of all the known types in ACS, either because they are preconfigured or coming from one of the preconfigured identity providers, or because you imported Federation Metadata from an identity provider or relying party.

Dealing with User Data

ACS does not provide any options to save data about users that you could use in rules to generate a token with additional user information. In contrast, ADFS has the option to configure Attribute Stores that hold data about the user, and by default Active Directory is configured as one. In ADFS, you can then specify rules that use the data in the attribute store. Because ACS doesn’t provide that, it makes sense to manage user data in the relying parties. The downside, of course, is that you must do that on all relying parties individually, unless you can let them share Azure Storage or a SQL Azure database. However, because ACS uses rule groups, you could create a rule group per user and use a single incoming claim to generate all the outgoing claims you need. For a small number of users, you can manage this with the ACS Management Portal, but for a larger user base, this becomes unmanageable. With the Management Service API, you can automate that management for values that users provide (for example, e-mail, phone number, or favorite pet), and provide a more appropriate user interface for user administrators to do this.

Summary

In this chapter you learned that the Access Control Service is a ready-to-go Security Token Service that supports protocols such as WS-Federation, OpenID, and OAuth. It also enables you to use different identity providers, such as Windows Live ID, Facebook, and WS-Federation identity providers such as ADFS. Because ACS supports WS-Federation, it works well with Windows Identity Foundation, so it is easy to set up a relying party like you learned in Chapter 9. In addition you learned how you can customize the login experience of users, so the page presented to them is not a plain ACS page but a page that fits well with the user interface design of your application.

You also learned that for active federation relying parties you can use service identities, identities you define in ACS, and which clients can authenticate using a symmetric key, username and password, or certificate.

A key scenario for ACS is authenticating users that access business applications hosted in the cloud from the local network of their organization. You learned how to set up this using Active Directory Federation Services 2.0, which hooks into the Active Directory of an organization. The same also works if the local identity provider is not ADFS but uses the WS-Federation protocol.