Third Party Identity Providers

Authentication, identity management and access control are critical components of many cloud services. Claims-based access is typically used for SSO (single sign-on) solutions in enterprise environments that use WS-Federation, SAML, and WS-Trust, but has not been an option for REST-based cloud services.

ACS (Access Control Service) is a Windows Azure service that handles authentication and access control logic for applications deployed to Windows Azure. It implements WRAP (Web Resource Authentication Protocol), a REST-friendly protocol that developers can use to request compact Simple Web Tokens (SWTs) from ACS and then use those tokens to control access to REST services.

Many developers don’t want to take on the burden of managing identity information, and most users already have an identity from their on-premises network or a third party such as Office 365, Google, Facebook, Yahoo!, or others. ACS simplifies authentication, identity management, and access control for both developers and users, by making it possible for Windows Azure applications and services to reliably and easily accept on-premise identities or off-premise identities from trusted third party identity providers.

This diagram from the MSDN article ACS Architecture shows how it works:


The client application sends the user’s credentials to a trusted identity provider such as Office 365, Facebook, Google, or others, and the identity provider returns a token. The identity provider token is then sent to the ACS Security Token Service (STS) endpoint, which returns an ACS token that can be used to control access to Windows Azure cloud services. STS maps input claims to output claims based on access control rules that the developer has defined.

ACS supports a variety of protocols that allow it to be accessed from any web platform including .NET Framework, WCF, Silverlight, ASP.NET, Java, Python, Ruby, PHP, and Flash.