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.
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
- a simple and interoperable security model that works with any platform at the service consumer or service provider.
- federated security scenarios for REST-based resources.
- flexible, rules-driven, and claims-based authorization.
- the ability to extend applications to users or business partners in other trusted domains, without impact to the service provider.
- a demilitarized zone (DMZ) in the cloud—the ACS becomes the first stop for scalable Denial of Service (DoS) attack prevention.
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.
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).
Here is an example of how you might approach configuring the ACS:
- Create a token policy (Figure 4). This indicates the token lifetime in seconds and the signing key to be used for all tokens issued by this policy. Your application must have access to this key (it is a shared secret) in order to authorize access based on the issued token.
- Create a scope (Figure 5). A scope can be a specific URI (a single web resource) or a base URI (that might apply to many resources within the same application domain). You associate a scope with a token policy. This determines which key will be used to sign the tokens issued for this scope.
- Create rules for each scope (Figure 6). A rule can be a pass-through or simple rule. A pass-through rule lets you pass the value of an incoming claim to the value of an outgoing claim. A simple rule allows you to match the value of an incoming claim and issue an outgoing claim accordingly. Figure 6 maps an incoming "Issuer" claim to an outgoing "action" claim. You can read it as follows: "If the caller authenticated against the TodoList issuer, grant them access to the GetItems operation at the service." This example includes similar rules for CreateItem and UpdateItem. Your goal is to produce outgoing claims useful to the service provider based on your knowledge of the incoming claims. There are many possibilities, but I'd like to expand on that specifically in a dedicated article.
- Create a token issuer (Figure 7). The token issuer authenticates incoming requests for an ACS token via symmetric key or SAML token. If the service consumer will authenticate with a symmetric key, it can be generated as shown in Figure 6. If with a SAML token, you can either specify the public key of the SAML token issuer or gather it from the federation metadata produced by the SAML token issuer. You can create a token issuer per user, per application, per partner, per role and so on.
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.
Authentication and authorization through the ACS for this scenario is based on the following interoperable protocols:
- Web Resource Authorization Protocol (WRAP) describes a simple mechanism for requesting tokens and authenticating to web resources with the resulting token.
- Simple Web Token (SWT) describes a way to assert a set of name/value pairs with an SHA 256 HMAC signature to prevent tampering.
- HTTPS is required to secure WRAP messages.
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=TodoList wrap_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%3d wrap_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%3d wrap_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.
