• 2 min read

Implementing Single Sign-on with Windows Azure Active Directory

Editor’s Note: Today’s post comes from Gayana Bagdasaryan, Technical Writer in our Identity Federation team. In this post I will cover the basics of the Web Single Sign-on scenario that…

Editor’s Note: Today’s post comes from Gayana Bagdasaryan, Technical Writer in our Identity Federation team.

In this post I will cover the basics of the Web Single Sign-on scenario that can be implemented with the help of Windows Azure Active Directory.

Before I go any further, I would like to stress that what is currently available is a Developer Preview Release of Windows Azure Active Directory, therefore things are not as simple and seamless to implement as they will be once Windows Azure Active Directory becomes generally available. The goal of this post is to encourage you to play with the preview, and experiment with it.

The scenario is very simple and very common in the identity world. Let’s say you are an ISV and you have a business application running in the cloud. One of your customers is a company with an Office 365 subscription. You want the employees of your customer to be able to access your application in exactly the same way they access their Office 365 applications. In other words, you want to establish web single sign-on, also called identity federation.

You can implement web single sign-on with the help of Windows Azure Active Directory that was provisioned for your customer when they subscribed to Office 365. Windows Azure Active Directory provides directory, authentication, and authorization services, including a Security Token Service (STS).

With the web single sign-on, you will provide access to your cloud application to your customer’s employees through a federated mechanism that relies on an STS that is provided by Windows Azure Active Directory. You and your customer will accomplish this by performing the following tasks:

  1. Your customer must provision your application in Windows Azure Active Directory. Also, as part of this step, you must provision your customer to have access to your cloud application. In other words, you need to ensure that users from the Office 365 tenant with your customer’s specific domain are granted access to your application.
  2. You must protect your cloud application with WS-Federation and onboard your customer. In other words, establish trust between your cloud application and the single sign-on endpoint of the directory.

For detailed information about web single sign-on, see:

For more information, see: Single Sign On with Windows Azure Active Directory: a Deep Dive.