Demystifying Access Control Service

Having presented quite a few sessions on Claims Based Idenitity and Access Control Service I still see quite a few participants confused on how to get started. While most of them are able to understand the underlying business motivation, they are list lost admist all the new terms like SAML, SWT, OAuth, WRAP, WIF, ACS, ADFS, Claims, Active / Passive Federation, etc. Let’s get them in turn.

At the heart of these offerings is the below simple block diagram which drives the key concept of -  Relying on a trusted External Entity (Identity Provider) for – Authenticating users and Providing user attributes (claims) to saves our services / applications from Identity nightmares. So, for your Service or your Application, you establish trust with an identity provider by sharing a X509 certificate or a shared secret. Clients or users of your service / application no longer connect with you for authentication, rather they authenticate with an identity provider to get back a claims token. That token is then presented to your service / application. As your service / application has a trust established with that IP they can validate the trust of the incoming token and then use the claims bundled in it to authorize the level of access for client / user.

Above flow becomes little complex when RP needs to trust multiple identity providers (for instance you are offering a multi-tenant service for individuals and coporates with each of them having a different identity provider). Not only RP would have to establish trust with all these providers but the Identity Providers too would have to register this RP to issue tokens on request. This is where a mediator called federation provider comes into picture. RP get registered only with federation provider and federation provider in turn is registered and trusted by various identity providers. Hence it simplifies many-to-many relationship into easily manageable one-to-one. Access control service (ACS) is a federation provider hosted on Windows Azure.

You will also find two federation terms used quite frequently – Passive & Active federation. Passive federation is assoicated with web applications (rather web browsers) where authentication happens via a set of redirects. Active federation is assoicated with Web Services and clients that explicity get authenticated.

Once a client authenticates with Identity Provider he get a token back. There are two token formats supported by Access Control Service – SAML and SWT. SAML exchange happens over WS-* protocols while SWT tokens are usually transferred over OAuth WRAP / OAuth 2.0 protocols (details here). You are most likely to use SWT tokens for RESTful services hosted in Azure. You can find more details about these token formats explained here

ACS would accept either of the token formats as input and would also return either of them as outputs. For instance there could be scenarios where you get a SAML token from ADFS (corporate identity provider), you use that to get authenticated with ACS and ACS returns you back a SWT token which in turn is used to access a protected REST Service (offered by a business partner).

Let’s start with SWT tokens. To see SWT tokens and OAuth WRAP in action protecting a WCF REST Service (active federation) I would recommend you have  a look at the ACS samples. Establishing trust between RP & ACS is quite simple – you exchange a shared secret. When client authenticates with ACS he gets back a SWT token which integrated HMAC256 hash. Relying part checks the authenticity of hash and claims inside the token on incoming tokens  to allow access to requesting client. You should see that retrieving SWT tokens using WRAP protocol from ACS and sending it to a RP is quite simple, infact you would hardly need anything beyond HTTP client library.

//Requesting a SWT token with username / password from Access Control Service

var client = new WebClient();
client.BaseAddress = string.Format(“https://{0}.{1}”, serviceNamespace, acsHostName);

var values = new NameValueCollection();
values.Add(“wrap_name”, unamepass.Username); /*Service Identity to be specified in Access Control Service*/
values.Add(“wrap_password”, unamepass.Password);
values.Add(“wrap_scope”, ConfigurationManager.AppSettings["relyingpartyname"]);

byte[] responseBytes = client.UploadValues(“WRAPv0.9/”, “POST”, values); /*SWT token is received in raw format*/

SAML on the other hand is little more complex. Luckily for us Microsoft provides nice Visual Studio integreated tooling (FedUtil – Add STS Reference) for working with SAML tokens along with WIF (Windows Identity Foundation) SDK. This tooling can be leveraged by both services and applications. In fact all you need to establish trust with identity providers is federation metadata and tooling generates that for you in form a file called FederationMedata.xml. WIF SDK, in addition, provides web controls for federated sign in and sign in status (Look at this article in case you want WIF to work with SWT for web applications (passive federation)).

Tooling also sets you up by plugging necessary modules in your RP’s web.config namely – WSFederationAuthenticationModule and SessionAuthenticationModule. Former helps you validate authenticity of incoming token while later establishes a session between client and relying party (FedAuth Cookie) so that token validation doesn’t become an overhead for every operation invoked. You can also add an additional module to this called ClaimsAuthorizationModule which let’s you invoke your custom ClaimsAuthorizationManger class as shown below.

<microsoft.identityModel>    
<service>
<claimsAuthorizationManager type=”WebApplication4.CustomAuthorizationManager”/>
</service>
</microsoft.identityModel>

public class CustomAuthorizationManager : ClaimsAuthorizationManager    
{        
public override bool CheckAccess(AuthorizationContext context)        
{      
//…      
return base.CheckAccess(context);        
}    
}

HTH!!!

Book Review: Microsoft Windows Azure Development Cookbook

Apparently, this is my first public book review. A month back when PACKT Publishing asked me to do a review of this book I was delighted for couple of reasons. Firstly, I would get my hands on a book I so much wanted to read and secondly review the work of the maestro – Neil Mackenzie. If you don’t know Neil most probably you haven’t done a serious Windows Azure project . Neil is the most active person on Windows Azure MSDN Forum, maintains a comprehensive blog on Windows Azure (at times I have felt that the depth of his blog entries surpasses that of MSDN documentation) and a Windows Azure MVP we all are proud of.

Highlight of the book for me are the exercises (referred as recipes), which are to the point, with concise code snippets, cutting the unnecessary verbose. Book’s first chapter starts with a very important yet very less discussed topic – authenticating with Windows Azure Platform. Chapter covers authentication scenarios pertaining to Azure Storage, Service Management, and AppFabric (caching) covering subtle topic of storage key rotation. Second chapter gives a thorough coverage of Blob storage including Leasing and leveraging Azure CDN. Third and fourth chapter dive into Tables and Queues again discussing key topics Pagination and polling back off (we recently helped a client cut on its transactional cost using similar approach). Fifth chapter which happens to be longest chapter of the book is really packed. You would be amazed at how much information is covered in these hundred pages. Chapter covers everything about hosting on Azure – multiple websites in a single role, HTTPS support, VM Role, Azure Connect and MarketPlace DataMarket among others. Chapter sixth and seventh contains vital topics of diagnostics (your key to success on Azure Platform) and service management APIs. It’s interesting to read the PowerShell coverage of these chapters. Finally book ends with couple of chapters around SQL Azure and Azure AppFabric. I was impressed with Neil’s knowledge around SQL Server DB and detailing of DMVs (dynamic management views).

Coming to the cons of the book, depending on your experience you might feel that book could have been better organized. May be an introduction chapter or an appendix at the end providing a 360 degree overview of Windows Azure could have been helpful. Also, while recipes are compact; snippets and corresponding explanations are done separately which at times is tedious to shuffle between. Lack of screenshots might be a concern to few readers. Also few topics like Access Control Service, WCF services, etc. have lesser focus (in case those are your prime use cases).

To sum up, writing Azure book is tough, especially with the rapid release cycles and features being churned regularly. Considering that, I would commend author for his work and would strongly recommend this book to accelerate your knowledge on Windows Azure. Three hundred plus pages can easily transform you into a PRO, helping you create more effective Windows Azure solutions.

Happy Reading !!!

(P.S. You can download a sample chapter of the book from here).