Setting up authorization with Office365 (WAAD) for an Azure Web Role

I’ve been working with porting an existing ASP.Net application over to an Azure Web Role. At the same time I wanted to look into setting up authorization against third party providers, in particular for Office 365 users.
Topics covered in this post:

• Set up an Access Control Namespace (Access Control Service/ASC) in Azure
• Configuring the ASC to use Windows Azure Active Directory (WAAD)
• Configuring the WAAD to trust the ASC
• Adding an identity provider to your web role
• Configuring the ASC to trust the application

I’m not detailing all the background information for each step, but try to cover all the necessary steps to get it all up and running.

Set up an Access Control Service in Azure

Log into the Azure management portal (https://manage.windowsazure.com/) and choose “Active Directory” from the service menu. Next click the NEW button in the lower left corner.



Choose “Access Control”, give it a name and pick a region close to where you are located. Then hit “Create”.



Once created, select the new ASC and click manage. This will take you to the ACS management page, in my case: https://mikael.accesscontrol.windows.net/v2/mgmt/web

Configuring the ASC to use WAAD

On the Identity Provider page click Add in order to add a reference to the WAAD you want to integrate against.



Choose “WS-Federation”



Give the provider a descriptive display name and enter the URL for your WAAD or Office365 Directory (which is one and the same) and a login link text.

The URL for the WS-Federation metadata is on the format:

https://accounts.accesscontrol.windows.net/YOURDOMAIN.onmicrosoft.com/FederationMetadata/2007-06/FederationMetadata.xml

where you replace YOURDOMAIN with the name of your Office365 tenant or WAAD name.



Now you have set up the link between the ASC and WAAD. The next step is to tell WAAD to allow this ASC to access it.

Configuring the WAAD to trust the ASC

Unfortunately this step is not possible to set up via the admin pages and you have to resort to using PowerShell. Following the steps from http://www.cloudidentity.com/blog/2012/11/07/PROVISIONING-A-DIRECTORY-TENANT-AS-AN-IDENTITY-PROVIDER-IN-AN-ACS-NAMESPACE/ I managed to set this up.

First you have to download and install the Microsoft Online Services Sign-in Assistant, and secondly download and install the Windows Azure AD Module (32bit / 64bit).

Open a “Windows Azure Active Directory Module for Windows PowerShell” window and execute the following commands:

# This first line will prompt you to connect to your Office365/WAAD service
Connect-MsolService
# Load the extended module to support the right parameters needed
Import-Module MSOnlineExtended -Force
# Set up the address with the root access of your ACS
$replyUrl = New-MsolServicePrincipalAddresses –Address "https://mikael.accesscontrol.windows.net/"
# Create a new principal to allow the realm of your ASC to be used with WAAD
New-MsolServicePrincipal –ServicePrincipalNames @("https://mikael.accesscontrol.windows.net/") -DisplayName "Mikael ACS Namespace" -Addresses $replyUrl

You may add more parameters to the last line in order for the principal to live longer than the default of one year.

Adding an identity provider

I started out doing all of this in Visual Studio 2013, but I have yet to find a good way to add an identity provider to an existing web role in VS2013, so I went with using VS2012 for this.

In VS2012 make sure you have the “Identity and Access Tool” extension installed.



Next make sure the target platform is set to .NET 4.5 and not 4.5.1 as identity extension does not work above 4.5.



Right click your Web Role project in Visual Studio and choose “Identity and Access…”



Now you need to add a WAAD provider pointing it you the ASC created earlier as well as enter the URL of where your application will reside. For this test my application is run in the Azure Emulator at 127.0.0.1:82. The URL for the ASC may be retrieved from the Application Integration page of the ACS management portal.

(Note: The screenshots are using an ASC called madcow and not mikael which I used earlier in the post)






Hitting OK will add the necessary configuration entries in web.config which will redirect users to the ASC for login.

Once this is done you may open the project again in VS2013 and change the target to 4.5.1.

Remember to replace 127.0.0.1 with your production URL when deploying this with a live web.config. See http://msdn.microsoft.com/en-us/library/gg185906.aspx#BKMK_1 for more information on configuring realm and return URL’s.

Configuring the ASC to trust the application

The final step before putting it all together is to register the application with the ASC.

In the ASC management portal navigate to “Relying party application” and click Add.



Enter the name of your application, the URL/realm of where your application resides, which corresponds to the one used when adding the ASC in Visual Studio. Also provide the URL where you want to be redirected after the user is authenticated. On the Authentication Settings section check off for your WAAD provider (and any other you might want to support) as well as check off to create a new rule group.




In the ASC management portal head over to the “Rule groups” section and click the Default Rule Group you just had created.



Click the “Generate” link to generate new links.






Lastly fire up your application, in my case at http://127.0.0.1:82/Default.aspx and it should redirect you to a login page at login.microsoftonline.com. If you checked more than one provider, for example Windows Live ID you will be taken to an intermediate page on your ASC where you get to pick the provider you want to use first.