There are tons of technical resources out there detailing how to implement/code ACS, which I will share at the end of this post.  So I’m not going to go through those.  The goal here is to give you an understanding of what ACS is on a high level and why you might need it when securing a part of your site.  It is for those who may have heard of ACS before but not entirely sure what it is and what it’s for.  Also we have an upcoming Cloud Day event so it’s just appropriate that we post this  

Ok, the way we’ll go about this is through an analogy. 

Picture from Jocelyn’s tumblr

Let’s imagine a teen-looking guy (of legal drinking age) on his way to 7-Eleven to buy an ice cold beer.  You’re the storekeeper.  When he enters your store and tries to purchase a beer, a few things will happen:

1. The storekeeper (you) will ask for an ID to validate the buyer’s age. (He doesn’t look old enough?)

2. The guy trying to purchase the beer reaches out to his wallet to pull out a driver’s license, or whatever ID that proves he is who he says (photo) and that he is old enough as he claims (birth date).

3. If he is of legal drinking age as it says on his driver’s license, the storekeeper (you) will allow him to purchase the beer, and you will hand him back his license (this last part is important later).

This simple scenario pretty much plays out what ACS can do for you (which we will get into more detail in a bit), using the principles of claims-based identity.  A user goes to your website to access a protected resource (beer), the site asks the user for a security token to prove that he is who he says and of legal drinking age (driver’s license), and finally he is provided access to the protected resource without giving out any password.  The storekeeper (you) didn’t need to write down or maintain his identity in your logbook, you know you can trust the driver’s license and the department that issued it.  You being shown the driver’s license is the process of making a “claim”.

Where’s the “Enter your password” part?

There are actually two other things that need to happen first, way before the buyer entered the store, to enable him to purchase the beer in the end.  Let’s number them steps 0.a and 0.b:

0.a – He was born and given a birth certificate

0.b – He used his birth certificate in obtaining a driver’s license.

“Being born,” in a claims-identity world, is similar to signing up for an online account   When a user signs up for a Live ID, Google account, Facebook, or maybe assigned a login account in your company using Active Directory, that user is “born” into the online world with an identity – a username and a password at the very least.  Similar to a “birth certificate,” with your name written on it and ink-marked with your tiny foot (not sure if this applies to every country but just go along with me here).

For step 0.b, in being issued a driver’s license, the issuer (i.e. Department of Motor Vehicles) will use the birth certificate as a form of identification.  It’s a fact that birth certificates can come from different countries around the world.  Fortunately, the DMV (issuer) can deal with different sorts of birth certificates from other countries (let’s just assume that for a minute).  Whether someone was born from the “Evil Empire” (Live ID), or “Don’t be Evil” country (Google account), the “Walled Garden” country (Facebook account) or in his own country (Active Directory in your own company).  In the end, the DMV will give him the same driver’s license regardless of the origin of his birth certificate.

Access Control Service

The 0.b step I just described above is exactly what ACS can do for you – it manages the different Identity Providers (IP) in your behalf (Live ID, Google, Facebook, ADFS, etc.).  This enables you as a developer to anticipate only one type of token and build a very simple logic to extract the “claims” from that token (name, age) that you can work against.  No need to worry if a person logged in using xyz@live.com or xyz@gmail.com, etc. ACS will take care of re-routing the user to the appropriate IP login page and getting the token you need.  You just work with the token given to you by ACS and use it to authenticate and authorize the user accessing the protected resource in your site.  The end game is that your user has already logged-in to one of these IPs to access the protected resource in your site.

In this claims-based identity world, you are referred to as the Relying Party (RP) because you rely on ACS to manage identities for you.  In this role, ACS acts as a federation provider (FP).  Also, anything that can issue security tokens (usually through a web service) is referred to as a Security Token Service (STS). ACS is also an STS in this case because it issues security tokens for you.  (ADFS that sits in front of your Active Directory is also an STS).

Picture from MSDN article

The other benefit of this is that you don’t have to maintain a list of usernames and passwords in your system.  Password maintenance requires a considerable amount of expertise in encryption and security (security to secure security wow).  You can let other companies (IP’s)do that for you. 

There are however still cases where you might need to maintain your own users/passwords in a database somewhere, such as in your own Active Directory. In other cases all you really need is to identify the person, and store one of the claims information such as email address (in a mini-database) for email marketing purposes (the storekeeper has a sweepstakes promo and he needs to inform the buyer if his name was drawn).  Other than that, a password is just a long list of gibberish text that presents a maintenance overhead on your part. 

If you do have an Active Directory, it is still worth maintaining because ACS can work with several other ADs (through Active Directory Federation Services or ADFS) from other companies so that company A doesn’t need to create an account for an employee in company B in case that employee needs access to company A.  ACS can keep those credentials isolated from each other, but still facilitate authentication across each company’s protected resources.  How?  Through trust mechanisms…

Trust is the Key

At the end of the day, it all boils down to trust – you as a storekeeper from 7-Eleven needs to trust the Department of Motor Vehicles that issued the driver’s license.  In that world, this trust is straightforward – you’re not required to call DMV to confirm the validity of the driver’s license shown to you.

However in the online/programmatic world, you need to set up and declare this trust in some form.  That’s what you do after signing up for an ACS account – you set up the trust relationships across the IP’s and RP’s, and declare the “language” (token format) that they can use to talk to each other when passing these security tokens, among other things.  Here are some screenshots of how that might look like in ACS for a cloud app that I have set up previously.  This allowed me to do away with coding a login form and setting up a user/password pair database for my cloud app if the user already has an account with Live, Google, or Facebook.

(You’ll notice at the top that there’s a yellow highlight that says “developer preview”.  That simply means there’s a free non-production version of ACS at the moment that you can use to test.  So head over to https://portal.appfabriclabs.com/ to check out what it looks like)

From the screenshots above you’ll now notice a few familiar terms that we have been mentioning so far – Relying Party, Identity Providers, and Token (Format).  Also notice there’s a Token lifetime.  With ACS (and identity scenarios in general), it appears that the user’s token cannot be used forever – it has an expiry date.  This is no different with the driver’s license expiring at some point.  But the analogy ends there.  If the user’s token were to expire, he will be forwarded back to the identity provider’s login page to supply his login/password again. (In the physical world you don’t see someone going back to the birth certificate issuing department when his driver’s license expires so he can go grab a beer in 7-Eleven). 

On the developer’s side, everything stays the same, we (RP) will still expect a token after the user has “ding dong’ed” back to the IP and ACS (STS).  Also if a new Identity Provider pops up in the future (FriendsBook?) , I can easily “add it in” in ACS once ACS supports it.

The Windows Azure part in all this

I actually learned a bit of claims-based identity in a backwards kind of way through ACS.  What I mean by that is that claims-based identity didn’t originate from ACS.  It’s been around for sometime.  ADFS is an on-premise example of that.  Here’s a grid of claims-identity Microsoft technologies (from one of David Chappell’s pdfs I found using a quick Bing search):

You’ll see that the cloud equivalent of the on-premise ADFS 2.0 is Windows Azure AppFabric Access Control.  If you have the expertise, capacity, and manpower to set up your federation service (STS), the on-premise ADFS will work for you.   Fortunately, ACS is another option for setting up this kind of environment, without having to deal with the infrastructure myself.

Also for the sake of completeness, do know that Access Control Service is just one of many services under “AppFabric,”  which is actually a collection of services provided for you in Windows Azure.  Check out this page to find out more.

Wrapping Up

I hope this beer analogy was useful in explaining what ACS is on a high level and why you might need it (or not need it) in securing a protected resource in your site.  The terms and acronyms above will now be familiar to you when you read about claims-based identity and Access Control in general.  I’m no security expert, but these links helped me understand a bit of what I shared with you about ACS:

• Re-Introducing the Windows Azure AppFabric Access Control Service
• Primer: federated identity in a nutshell
• Claims-Based Identity Overview and Concepts
• Brokered Authentication: Security Token Service (STS)
• Claims-Based Identity for Windows: Technologies and Scenarios
• Claims Based Identity & Access Control Guide (Codeplex)
• Windows Azure AppFabric site
• UPDATE: Windows Azure News from MIX11

Also make sure to attend our upcoming Cloud Day event this coming April 27th.  Click here for more details.

Related Posts