Access Control in the Cloud: Windows Azure AppFabric's ACS

There is a new solution in town for authenticating Representational State Transfer (REST)–based web resources—and it's called the Access Control Service (ACS). Part of the Windows Azure platform AppFabric offering, the ACS makes it possible to achieve authentication and authorization scenarios not previously possible for web resources, including a standards-based way to authenticate from Windows, AJAX, or Silverlight clients and federation scenarios with business partners. This article will be the first of a short series on the ACS. Here I'll introduce the ACS and provide an overview of some fundamental features and implementation scenarios. In subsequent articles I will dive in further.

What Is the ACS?

Simply put, the ACS is a standards-based token issuer in the cloud: a hosted, multi-tenant offering available to every AppFabric account. Once you've signed up for a Windows Azure Platform account, you can begin configuring your applications to rely on the ACS to easily authorize access for trusted applications, users, and partners. Figure 1 illustrates a very high-level perspective on the flow of communication among participants.

Figure 1: Access control participants and flow

The client application (Service Consumer) requests a token from the ACS—supplying either a symmetric key or Security Assertion Markup Language (SAML) token. The ACS (Token Issuer) verifies that the request came from a trusted caller; evaluates rules associated with the scope of the request; and issues a security token carrying the claims granted the caller. The web resource (Service Provider) verifies that the security token was issued by a trusted token issuer (the ACS account) and uses the issued claims to authorize access accordingly.

There are a lot of useful scenarios enabled with this simple flow including

Access Control Setup

From the AppFabric management portal you will create one or more service namespaces for your AppFabric account. Each service namespace usually coincides with a particular set of applications for which you want to host services with the Service Bus (SB) or protect resources with the ACS. For example, Figure 2 shows the management, SB, and ACS details for one of my AppFabric service namespaces, BustaCloudDemos.

Figure 2: AppFabric service namespace details

To configure your ACS instance, you will likely use the ACS Management Browser (see Figures 4 through 7, to be discussed later). You supply the service namespace and the management key (from Figure 2), and the tool communicates with the ACS management endpoint on your behalf. To request tokens, you hit the ACS STS endpoint (also from Figure 2)—passing a properly formatted request for an ACS token and supplying a valid token that the ACS can use to authenticate this request. I'll talk more about this process later.

Note: The ACS management endpoint is a REST-based service that you can interact with directly, and there is also a code sample with the AppFabric SDK that includes a simple API to call the management endpoint (acm.exe). Obviously it is easier to work with the management browser when you are first trying it out.

Resource Model

Figure 3 illustrates the ACS resource model configured through the management endpoint. First and foremost you can see that there is a management key (shown blacked out in Figure 2) for each service namespace; you use this to request a key to authenticate to the management endpoint. When you set out to configure your ACS instance, you're usually thinking in terms of your application resources (scopes) and your clients (users, applications, or partners that you want to grant access to).

Figure 3: The ACS resource model

Here is an example of how you might approach configuring the ACS:

Figure 4: ACS Management Browser: adding a token policy

Figure 5: ACS Management Browser: adding a scope

Figure 6: ACS Management Browser: adding a rule

Figure 7: ACS Management Browser: adding a token issuer

Protocols and Messaging

For this discussion, I am using a TodoList client application that relies on a Windows Communications Foundation (WCF) service to create, read, update and delete Todo items. The client app requests a token from the TodoList issuer, authenticating with a symmetric key. If the client application successfully authenticates, the caller is granted create, read, and update rights per the rules shown in Figure 6. Figure 8 illustrates the protocols and symmetric keys involved.

Figure 8: Protocols and keys involved in ACS messaging

Authentication and authorization through the ACS for this scenario is based on the following interoperable protocols:

As Figure 8 suggests, clients send token requests to the STS endpoint of the ACS instance: [https://bustaclouddemos.accesscontrol.windows.net/WRAPv0.9].

The client passes a valid issuer key (a Hash Message Authentication Code—HMAC—value) to authenticate to the ACS when requesting a token for the web resource. This token can be sent in plain text, or the request can be signed using a SHA 256 HMAC signature. The following illustrates the parameters passed in a plain text request, which include the name of the token issuer at the ACS (wrap_name), the issuer key (wrap_password), and the scope of the request (wrap_scope):

wrap_name=TodoListwrap_password= YQoz…zlCg=wrap_scope= https://localhost:8000/TodoListService

For signed requests (based on the assertion WRAP profile) the parameters change to those shown here:

wrap_assertion_format=SWT wrap_assertion=Issuer=TodoList&Audience=https://bustaclouddemos.accesscontrol.windows.net/WRAPv0.9&ExpiresOn=1265009431&HMACSHA256=vEJnIAcCI38Z%2f3yXfRN4h6NZOtCdrJ6hr2NMDfU7%2frQ%3dwrap_scope=https://localhost:8000/TodoListService

In this case, the format of the assertion (wrap_assertion_format) is SWT (SAML is another option), and the assertion (wrap_assertion) contains an SWT passing the authentication token, any other relevant name/value pairs (claims), and a SHA 256 HMAC signature.

Both plain text and signed requests return the SWT (wrap_access_token), which includes claims issued by the ACS in name/value pairs, and a signature using the token policy HMAC key. In addition, the token expiry time is returned (wrap_access_token_expires_in):

wrap_access_token=action=UpdateItem,CreateItem,GetItems&Issuer=https://bustaclouddemos.accesscontrol.windows.net&Audience=http://localhost:8000/TodoListService&ExpiresOn=1265036295&HMACSHA256=MvE%2bdiRFVJBEez4Y2y4cllEiplGDBozyFMoUM3jMVP4%3dwrap_access_token_expires_in=28800

This token is passed to the web resource in the Authentication header in the following format:

Authorization: WRAP access_token="action=UpdateItem,CreateItem,GetItems&Issuer=https://bustaclouddemos2.accesscontrol.windows.net&Audience=http://localhost:8000/TodoListService&ExpiresOn=1265036295&HMACSHA256=MvE%2bdiRFVJBEez4Y2y4cllEiplGDBozyFMoUM3jMVP4%3d"

The web resource validates the SWT signature and uses the token policy key to verify that the token was issued by the expected ACS token policy. At this point, the claims passed with the token (as issued by the ACS) can be used to authorize access as appropriate. In the example from Figure 4, a valid client is issued three action claims: getitems, createitem, and updateitem. The caller would be able to create, read, and update Todo items, but not delete them.

To Be Continued

In this article, I provided you with a high-level perspective of the participants involved when securing web resources with the ACS, the protocols involved, the flow of communication, and some instructions for setting up the ACS for a specific application scenario. In the next few articles for this column, I will explore additional scenarios and more specific implementation details.

Michele Leroux Bustamante ([email protected]) is chief architect for IDesign, chief security architect for BiTKOO, a Microsoft Regional Director for San Diego, and a Microsoft MVP for Connected Systems. Her latest book is Learning WCF (O'Reilly), and she blogs at www.dasblonde.net.