Managing identity,
authentication, and authorization is hard. It takes a lot of work by
developers to get it right. One wrong step and you leave a gaping hole
that a bad guy can take advantage of and land your company on the front
page of the newspaper. Security is always a high priority on any
project, but it’s loaded with special terms and more complexity than
developers generally want to deal with.
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:
Notice that this token is
URL-encoded. Later on we’ll look at code that will let us shred this
token and understand the separate parts. If you’ve ever seen a SAML
token, this is far simpler and easier to work with. There isn’t even any
XML!
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.