Windows Azure Pack: Active Directory Authentication – Part 2

Welcome back to this series about Windows Azure Pack – Active Directory Authentication. Now that we sync our on premise Active Directory with Azure Active Directory, we will focus on the configuration of Azure Active Directory to use it as an Identity Provider.

In order to be able to use Azure Active Directory as an Identity Provider, we first have to create a new Access Control in Azure. For start, in the Azure interface, we have to click on New > App Services > Active Directory > Access Control.

There, we select quick create and we have to space a unique namespace and location for our Access Control application.

When done, on the Azure Active Directory page, we have to click on the ACCESS CONTROL NAMESPACES. There, we could see that the ACCESS CONTROL has been well created. Select the ACCESS CONTROL NAMESPACE and click on the manage button at the bottom of the page.

This will open the ACCESS CONTROL SERVICE (ACS) website for your namespace.

As we want to use ACS with our Windows Azure Pack portal, we first have to create a new RELYING PARTY APPLICATION. Just click on ADD.

We have now to fill in the settings for our application (WAP Portal). In the WS-Federation metadata section, we need to provide the FederationMetadata.xml file used by our WAP Tenant Portal. This file is located at the following URL: https://YourWAPTenantPortal/federationmetadata/2007-06/federationmetadata.xml

We also have to change the TOKEN FORMAT to JWT.

As we will create a new Identity Provider later on, in the Authentication Settings, we have to uncheck Windows Live ID. Also ensure that X.509 Certificate is selected as Token Signing Type.

When done, click on the SAVE button and we are redirected the Relying Party Applications page where we could confirm that everything has been created correctly.

The tricky part now is that we have to let our Active Directory tenant know about the existence of our ACS namespace. The Authentication Web Page (WS-Federation) endpoints won’t issue tokens for any recipient, only for the ones represented by a service principal object will be eligible.

As of today, the Windows Azure Active Directory portal does not yet offer commands for creating service principal object. The option here is to use the Office365 PowerShell Cmdlets, we have to download it from here: http://go.microsoft.com/fwlink/p/?linkid=236297

The installation process is straightforward, just a next/next setup, when done, start an Office365 PowerShell shell. We have to adapt the ACS URL from to PowerShell script below to match with our ACS url. Replace the vnextlab namespace value by your own ACS namespace value and run the script.

Connect-MsolService
Import-Module MSOnlineExtended –Force
  
$replyUrl = New-MsolServicePrincipalAddresses –Address https://vnextlab.accesscontrol.windows.net/
New-MsolServicePrincipal –ServicePrincipalNames @("https://vnextlab.accesscontrol.windows.net/") `
 -DisplayName "mywap ACS Namespace" `
 -Addresses $replyUrl 

 

We are prompted to enter our Microsoft Azure Credentials

We could confirm that our Service Principal object has been created successfully.

We have now to go back to the ACCESS CONTROL SERVICE website, select the IDENTITY PROVIDERS in the right menu and finally click on ADD.

There we have to select WS-Federation identity Provider.

There we have to provide the WS-Federation metada URL. Replace the yellow part of the URL below by your Azure Subscription information.
https://accounts.accesscontrol.windows.net/christophervnext.onmicrosoft.com/FederationMetadata/2007-06/FederationMetadata.xml

As option we could enter the email prefix and finally, we have to select the relaying party application that we created earlier.

We now have our Relying Party and our Identity Providers set up. We should now tell ACS how to transform the incoming Claims from the Identity provider so that the Relying Party can understand it. We do that using Rule Groups which are a set of rules that govern Claim Transformation. We have to click on RULE GROUPS and click on the DEFAULT RULE GROUP FOR your application.

There we need to click on ADD

We have to:
– Select the Identity Provider we created earlier
– Select HTTP://SCHEMAS.XMLSOAP.ORG/WS/2005/05/identity/CLAIMS/NAME as Input Claim Type.
– Enter UPN as Output Claim Type.

When done, click on SAVE.

We are now all set with the ACCESS CONTROL SERVICE configuration. In the last part of this series, we will configure Windows Azure Pack Portal our new Federation Service.

Christopher

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Email this to someoneShare on TumblrPin on PinterestDigg thisShare on RedditFlattr the authorBuffer this pageShare on StumbleUpon

About Christopher Keyaert

Christopher Keyaert is a Consultant, focused on helping partners to leverage the System Center and Microsoft Azure cloud platform. He is also a Microsoft Most Valuable Professional (MVP) for Cloud and Data Center Management and a Microsoft Certified Trainer (MCT).
This entry was posted in Uncategorized. Bookmark the permalink.

One Response to Windows Azure Pack: Active Directory Authentication – Part 2

  1. Pingback: Windows Azure Pack: Active Directory Authentication – Part 3 | vNext.be

Leave a Reply

Your email address will not be published. Required fields are marked *