Online Identity Management via Windows Azure Access Control Service

Windows Azure Access Control Service can be used to integrate your application's authentication and authorization logic with whatever Identity providers you wish, as long as they support one of the security protocols that the service understands

The easiest way for a developer to implement claims-based authentication and authorization in an application, is by combining the power of two key components: Windows Identity Foundation and Windows Azure Access Control Service (ACS). In this article, we’ll focus on ACS.

If you are already using any kind of social login for you application, then you already know what this article is going to be about. If not, you may want to read my blog post “Introduction to the Claims world” first.

Windows Azure Platform is a constantly growing and improving cloud platform, offering a variety of services. Windows Azure Access Control Service is a Federation Provider, offered as a service. You can use ACS to easily integrate your application’s authentication and authorization logic with an unlimited number of Identity providers as long as they support one of the security protocols that the service understands (e.g. WS-Trust, WS-Federation, OAuth 2).

The key thing with ACS is that you don’t need to have your application deployed into Windows Azure  to leverage its capabilities. You can use Access Control Service with your application wherever you deploy it. Also, it doesn’t necessarily need to be an ASP.NET application, or even a web application. You can use ACS from your WPF application, Windows 8 Metro Style Application, or  Windows Phone 7 application.

Let’s see what it is all about.

When you want to begin working with Windows Azure ACS, open the management portal to create an Access Control Service Namespace. As with all of the other services from the Windows Azure family, you must choose a globally unique name within the domain. While I can live with a service name “” (because I can hide it behind my own domain), I can’t really hide my Access Control service namespace name. The users will, one way or another, see its full, real, potentially ugly, name. This is a disadvantage I can live with for now, and I do really believe this will change in the (hopefully near) future. Once your namespace is created and activated, you can go its management portal. Yes, the Access Control Service has its own management portal, where you manage all the aspects of this Federation provider. Of course, you have the full power of Windows Azure Management REST APIs to manage your ACS, in case you need to, or you don’t want to use the portal.  Here is a screenshot of the location of the ACS management tab in the Windows Azure Developer portal:


You can configure your application to trust tokens issued by your ACS, as soon as the namespace is created. However, when you try to authenticate a user, you will see an error message indicating that there is no Relying Party (RP) application configured in the namespace. There are 3 key components that you need to configure in your ACS namespace in order unleash the claims-based power – “Identity Providers”, “Relying Party Applications”, “Rule Groups”.

Let’s take a look at the ACS management interface:


Identity Providers

When you create a service namespace in ACS you have a Live ID Provider preconfigured for you. You can’t remove it because the Live ID is being used to authenticate you so you can work with the management portal. There is out of the box support (understand “zero code, zero confusion”) for four major identity providers (i.e. Microsoft Live ID, FaceBook, Google, and Yahoo) and a practically unlimited number of WS-Federation providers (such as Active Directory Federation Services 2.0). When you create (or edit) an identity provider (IdP), you must specify following properties:

  • Name – this how the Idp will be displayed in the list of your IdPs
  • Login Link Text – this is the actual text that will be shown to the users, when a login button (link) is displayed in your login page
  • Image URL – this optional field lets you specify an image or icon, which is displayed along with the login link text

Relying Party Applications

The second component that you need to configure is your Relying Party applications. You can configure as many RPs in your ACS namespace as you like. An address of http://localhost/ (as well as is fully supported, so you can build, debug, and test your application locally, before you deploy.  For each RP you add, you’ll need to specify:

  • Name – this is just an alias of your application for your convenience, and it’ll appear in the list of configured applications
  • Application address – this is the URL address of your application
  • Return URL – upon successful authentication, this is URL your user will be redirected to
  • Error URL – this is the URL where the user will be redirected in case an error happens during the Authentication process. Although this parameter is optional, I highly encourage you to complete it and properly handle requests to that URL. One reason for the user to be redirected to that URL is if they decline access to their data for your application. This may happen with a Facebook IdP, Google IdP, and others.


Because ACS is actually a Federation Provider, before you can use it in your application you need to configure one last thing: Rules. The Rules, are actually Claims transformation rules, which help you transform any input claim, into another claim. The idea is that you only configure you application once so that it works with, and understands, the Claims from ACS. Once that initial configuration is done, you won’t have to worry about what claims are actually provided by the different Identity Providers. You can apply as many transformation rules as you wish to an input claim, to generate or transform it into an output claim.

Once you configure the required Identity Providers, Relying Party Applications, and Rules, you are ready to go. The other neat feature of ACS is that you can change the IdPs, trust relationships, and rules even while running live and changes are immediately reflected! There is a very useful REST service that returns (in JSON format) the list of Identity Providers supported by calling the Relying Party. So if you use this, the list of supported IdPs will be auto-updated to your application, the moment you make a change. You can find a lot of useful information about building a custom login page and the address of your REST service by following the “Application Integration” link under “Development” in the ACS Management portal.

Now you’re ready to use the Windows Azure Access Control Service to integration your application’s authentication and authorization logic.

How you log in to Simple Talk has changed

We now use Redgate ID (RGID). If you already have an RGID, we’ll try to match it to your account. If not, we’ll create one for you and connect it.

This won’t sign you up to anything or add you to any mailing lists. You can see our full privacy policy here.


Simple Talk now uses Redgate ID

If you already have a Redgate ID (RGID), sign in using your existing RGID credentials. If not, you can create one on the next screen.

This won’t sign you up to anything or add you to any mailing lists. You can see our full privacy policy here.