Windows Azure ACS and AD

Tuesday, July 30, 2013
by asalvo

Windows Azure Access Control Services (ACS), and Windows Azure Active Directory (WAAD) are part of the identity application service offerings provided by the Windows Azure platform. Both ACS And WAAD provide authentication and can return a list of claims, which can be used to identify users, and perform authorization. Windows Azure Active Directory is the same service which Microsoft’s SaaS offerings, such as Office 365 use.

Similarities

Authentication using Access Control Services and and Windows Azure Active Directory is achieved using the Windows Identity Framework (WIF). In .Net 4.5, the latest version of WIF has been integrated into .Net allowing for easier use and one less dependency that needs to be managed during development, deployment and support. Two of the more noticeable changes with this integration in .Net 4.5 is that the namespaces have changed from Microsoft.* to System.*, and that there is a new Identity and Access add-on for VS 2012 which allows for the configuration of WIF using the declarative model.

WIF can be used in a declarative model (configuration via app/web.config files) or programmatic model. You can achieve a functional Authentication system using just the declarative model, but more advanced scenarios will require the addition of the programmatic model in conjunction with the declarative model, or as a complete replacement. Advanced scenarios include:

  • Custom login pages that mix ACS/WAAD and additional Authentication providers (i.e. Forms Authentication)
  • Custom Authorization beyond the claims return by ACS and WAAD (I would consider most enterprise applications to fall into this camp)
  • Mapping a users multiple social identities to a single account in your application(s)

In addition to using WIF with ACS and WAAD, both services also provide a Rest based API for management of the services. This is more interesting in the case of WAAD, as the Rest API allows you to configure multiple tenants, manage users and groups.

Access Control Services

Authentication

Access Control Services differs from Windows Azure Active Directory in that it provides an abstraction between your application and various identity providers. While there is an option to Authenticate directly to ACS, it’s primary use is to broker requests to one or more supported identity providers. ACS includes support for the following identity providers:

  • Facebook
  • Google
  • Live (Microsoft Account)
  • Yahoo
  • WS – Federation

WS-Federation includes support for Microsoft AD FS 2.0 and Windows Azure Active Directory in addition to services that implement the WS-Federation standard. So if you already have ACS in place, you can add support for a WAAD tenant, including Office 365 as an identity provider.

This abstraction of the identity provider, provides several key benefits to applications and organizations.

Authorization

ACS does not provide support for authorization, other then passing claims it receives from identity providers thru to your application. This document providers links to each supported identity provider and the claims they provider.

In order to implement authorization in your application, you will need to map users to permissions either directly, or via groups (which you would also have to manage yourself).

ACS does offer a rules engine for modifying the claims returned, but I am unaware of a way to tie this into groups or permissions for all but the simplest scenarios (i.e. limited number of users).

Windows Azure Active Directory

Authentication

Windows Azure Active Directory can be used for both Authentication via the Windows Identity Framework, and group level Authorization via the Rest API. You can also choose to use your own Authorization framework and just use WAAD for Authentication. Where as ACS is primarily a broker of Identity Providers, WAAD is an Identity Provider and directory store.

Authorization

Authorization in WAAD, at this time, is limited to Group Membership only. However it does provide support for indirect group membership (I belong to Group A, which belongs to Group B, which means I also belong to Group B), which allows for complex group membership support.

Given a well architected Asp.Net MVC application with well defined routes, you could implement your entire Authorization framework using a custom Authorize Attribute that checks WAAD group membership using the IsInGroup Rest API call.

Some examples of when you would need to do additional programming if:

  • Your routes are not well defined
  • You need more complex permissions then route/resource based permissions
  • You need to map multiple user identities to a single account

Other Features

A key difference between ACS and WAAD, is that WAAD is a directory store, capable of storing Users and groups, among other object types. These objects can be managed using the WAAD API.

Another feature of WAAD, is it’s ability to synchronize with on-premise active directory using ADFS. As I mentioned already, WAAD is the same directory that is used by Office 365, which many enterprise customers are already synchronizing with their on-premise Active Directory.

What Should I Use?

I am expecting Microsoft to continue to enhance Windows Azure Active Directory, whereas Access Control Services seems to have reached a certain level of maturity where there has not been a lot of active development on it recently.

As with most decisions, there are a variety of factors to consider, and multiple solutions may fulfill your needs equally. I’ve listed some of the criteria I am considering for two possible implementations at work. A key decision criteria for us is if we want to implement a department wide, or company wide authentication and authorization solution, which may be the subject of a future blog post. 

Criteria

  • Do you need to support social identity providers such as Google and Facebook?
  • Do you need to support single sign-on across multiple applications?
  • Do you need to support corporate users that have an identity via an on-premise Active Directory, which is not being synced to any other WAAD tenant, or does not have AD FS running?
  • Do you need to support users that already have an identity in an existing WAAD tenant?
  • Do you need to provide Single Sign On across multiple applications?
  • If you do need SSO across multiple applications, do you own/control all of those applications, are are they split between different departments in your organization?

Resources

Tags: Azure

Comments

comments powered by Disqus