Windows Azure AppFabric Access Control
Access Control is part of the AppFabric set of middleware services in Windows Azure. It provides a central point for handling federated security and access control to your services and applications, running in the cloud or on premise. AppFabric Access Control has built in support for federating against AD FS 2.0 – or any custom identity provider that supports the WS-Federation protocol.
In addition to supporting web based and SOAP based federation scenarios, Access Control also support federation using the OAuth protocol and REST based services. It has a web based management portal as well as OData based management services for configuring and managing the service.
The Access Control service has a rule engine that can be used to transform the incoming claims, thus being able to translate from a certain set of claims to another set of claims. It can also translate token formats to/from SAML 1.0, SAML 2.0 and Simple Web Token (SWT) formats.
Using the Access Control service you set up trust between the service and every STS that you want to federate with, including your own AD FS 2.0 STS:
Federated Identity through Windows Azure AppFabric Access Control
In this case your application running in Windows Azure still only has one point to point trust – to the Access Control service – and all the dependencies to the business partners are managed by this service.
Below is a sequence diagram showing the generic flow for single sign on using the Access Control service. The terms used in the diagram maps to our example as:
Client – the client in our domain or our business partner’s domain.
Identity Provider – our Active Directory + AD FS2 or our business partner’s STS.
Relying party – our application running in Windows Azure
The above diagram shows the flow when the application is a web application and the client is a web browser client (also known as a ‘passive client’). If the application would expose web services that a locally installed smart client (an ‘active client’) would consume, for example WCF services consumed by a WPF client – the first step in the sequence would be to directly login to the identity provider – instead of being redirected to a login page.
Federation with public Identity Providers
Windows Azure Access Control also let you use some of the largest public Internet services as Identity Providers. Out of the box there is built in support for using Windows Live ID, Facebook, Yahoo and Google as identity providers. The Access Control service handles all protocol transitions between the different providers, including Open ID 2.0 for Google and Yahoo, Facebook Graph for Facebook, and WS-Federation for Windows Live ID. The service then delivers a single SAML 1.1, SAML 2.0, or SWT token to your web application using the WS-Federation protocol once a user is signed in.
This is of course a really interesting feature when you are building public facing consumer oriented services, but could also be really useful in business to business scenarios. If for example you are building a SAAS solution, using the public identity providers like Facebook and Windows Live ID could be the option for smaller businesses while your enterprise customers could use their own STS for federation.
Here are some recommended resources if you want to dig deeper into the subject.
Category: sso, azure, english