Connecting in the cloud with AppFabric : Controlling access with ACS

We’re going to cover how you can integrate the user’s identity inside your company with applications running in the cloud. We’ll do this by leveraging claims-based authorization, which allows you to federate your internal identities with applications in the cloud by using standards-based tokens.

1. Identity in the cloud

When you move all of these concerns out of your own network and into the cloud, these concerns become even bigger issues. The application is no longer sitting right next to the source of authentication; the identity boundaries have been broken. How do you fix this problem?

The short answer is to build yet another identity store (a place to store usernames and passwords) and give every user yet another username and password to remember. They won’t remember them—they’ll either write it down on a sticky note on their monitor, or they’ll call you once a month to remind them what it is. This is a bad experience for the user, and it’s dangerous for the owner of the application.

We call this the identity fishbowl. Your identity (who you are and what you can do) is fairly easily maintained on your network, but the second you go off-premises you leave your fishbowl. The application in the cloud doesn’t have any way to connect to your Active Directory to authenticate you. The way to bridge these worlds is with open standards and the concept of a federated identity.

There are some other challenges, as well. Let’s go beyond the previous scenario where you have an internal user trying to access your application in the cloud. What if the user doesn’t work for you, but is a customer or vendor of some sort. What if you need to provision 100 user accounts for that new customer, or 10,000 accounts? This is a lot of work for the administrator, it gives your end user yet another identity to remember, and it exposes you to a risk of not deleting an account when it should be. You’re on the hook for managing those accounts, not the customer or vendor. If you have user accounts in your identity store that are active and belong to someone who has left the company, you’re leaving a wide open hole for them (or an outside evil-doer) to compromise that account and access your application when they shouldn’t.

What you want is an easy and secure way for your internal users and external users (customers, vendors, and so on) to be able to access your application using the identities they already have. This approach also has to have low impact on the service code. You don’t want to have to fix the code every time you enroll a new customer, or find a new protocol to support. You want to write applications, not become enterprise security ninjas. Well, most of us do anyway.

ACS handles all of these concerns for us in a brilliantly elegant way. Before we can really talk about ACS, though, we need a common understanding of some of the core concepts ACS is built on.

2. Working with actors

The security field is loaded with special vocabulary and concepts that scare most developers. Even knowing the importance of security, many developers just find some sample code and paste it in. They either don’t have the understanding needed to work with the code, or they won’t change it for fear of making a mistake.

There are several actors in this security play that we need to define. The most important is your service or application—the resource you’re trying to protect. It’s commonly called the protected resource or the relying party because it’s relying on the security infrastructure.

The next actor is also easily defined: the client. This is the application that’s trying to access the relying party. Clients are also sometimes called issuers. This side can get a little complicated when you have a second client that’s being delegated through the first client to the protected resource.

Finally we have the ACS service itself. In security lingo, ACS is called the authorization server or trusted authority. It provides the security infrastructure the client must use to authenticate and use the protected resource.

In our play, the authorization server is the director, the protected resource is the lead actor, and the client is the supporting actor.

3. Tokens communicate authorization

Our three actors need some way to communicate, and they do this by passing tokens around. There are many formats for tokens, and there are many ways to pass them around. The messages they pass around usually include a set of claims, which we’ll get to in a moment.

You likely use a token every day—your driver’s license. You can use it to prove your identity or to prove a claim. A bar might demand you satisfy (prove) your claim that you’re over 21. You never have to give them your birth certificate; you just give them your driver’s license. You proved who you were, and when you were born, when you applied for your license. The Department of Motor Vehicles validated your credentials and provided you with a token that proves your claim of age on the license. The department is the trusted source, the bar with the beer is the protected resource, and your license is the token. You’re the client.

The following figure shows this relationship between you, the bar, and the Department of Motor Vehicles. You first authenticate to the DMV. Once they’re satisfied, they give you a secure token that provides data for some claims. You can then use this token to get a frosty beverage at any bar, even if not everybody knows your name. You can see this relationship in figure 1.

Some token formats are proprietary and some are an open standard. Microsoft has worked with Google and Yahoo! to develop a new, simple open standard that can be used across the cloud and the web. This standard is called OAuth, short for open authorization. There are other open standards that are popular, such as SAML (Security Assertion Markup Language), but they tend to be more complex and geared for SOAP instead of REST. OAuth’s goal is to provide a simple token and protocol that makes it easy to secure REST-based services.

ACS is based on OAuth, but it knows how to read other types of tokens as well. There are two halves to OAuth. The first is the Web Resource Authorization Protocol (WRAP). This is the protocol used to make authorization requests and to move requests and tokens around on the wire. The other half of OAuth is the Simple Web Token (SWT), which defines the token itself. SWT tokens are simple to read and understand. The goal in designing OAuth and SWT was to build protocols that any platform could leverage to secure REST-based services.

All tokens coming from ACS will be SWT tokens. Here’s a sample token:

The OAuth working group’s website includes the specification for these protocols and formats. They’re surprisingly easy to read, but they do lack an interesting plot. They’re much easier to read than the WS-* and SAML/STS specifications, if that means anything. You can read them all in about 30 minutes.

4. Making claims about who you are

With all these tokens flying around, we need something to put in them. Although there are other pieces of data stored in tokens, the real reason tokens exist is to deliver what is called “a set of claims.”

A claim set is a list of claims made about the client or user by the authorization server. What a claim represents is completely open and can be defined by the systems using it. The claim must serialize to plain text—there isn’t any fancy XML in OAuth, just a name-value collection of claims. A claim set might include a user’s name, their birth date, their customer level, a list of roles or groups they belong to, or anything else your service (the protected resource) needs.

Your service will use these claims to make security and behavior decisions. The first decision is whether the user is allowed to access your service. Then, once you have let them in, you can use the claims to determine what they can do. If their role claim includes manager, you might let them apply discounts to existing orders. If the role claim is staff, maybe they can only create normal orders. What you ask for in claims and what you do with them once you get them is up to you.

This use of claims moves us away from the traditional role-based access control (RBAC) and toward claims-based access control (CBAC). The concepts are the same; the difference is in how we get the data regarding the user’s identity and how we make decisions based on that data.

As you implement ACS, it’s possible to add the use of SWT tokens to your system without ripping out the old way of managing identity. This is useful if you’re trying to transition to the new platform without breaking what already exists.