In my post “Add Azure Active Directory Support to Azure Mobile Services-Enabled Windows Phone Apps” I go through how to setup Azure Mobile Service to work with Azure Active Directory. Firstly I’m going to create a separate directory for this application. From the toolbar at the bottom of the Azure management portal I select App Service –> Active Directory –> Directory –> Custom Create
The Name of the Azure Active Directory (AAD) is a friendly name which you can use to identify the directory in the portal. The Domain Name has to be unique and will be the identifier, and default tenant, of the directory.
The next thing I’ll need is to create two Application entries within the AAD. You can think of applications as the glue that connects AAD to both the Mobile Service (the resource being protected) and the native client applications.
I’ll first create an application that will link AAD to the Mobile Service. From the Applications pane in the AAD, click Create, followed by the link to “Add an application my organisation is developing”.
Next I need to give the application a name (again this is for identification in the portal – as you’ll see the name I chose is quite long and gets truncated in some of the later views, so I’d suggest a shorter name), and select “Web Application and/or Web API” under the Type heading.
On the next pane I’m prompted to enter a App Id and Reply Url. On a separate pane I’ll open up the Mobile Service and go to the Identity pane. At the bottom under the Windows Azure Active Directory section I’ll copy out the App Url (ie https://realestateinspector.azure-mobile.net/login/aad). This value should be set for both App Id and Reply Url. After completing the creation process for the application, copy the Client Id value from the Configure pane and switch back to the Identity pane of the Mobile Service. Enter the Client Id into the Client Id field under the Windows Azure Active Directory section. I also need to specify the allowed tenant, which in this case is the default tenant from the AAD I created earlier.
Next I’ll create an application that will connect our native client applications to AAD. This time I’ll select Native Client Application under the Type heading.
On the next pane I’m prompted for a redirect url. For the timebeing I’m going to enter a placeholder value (eg http://tba.com)– we’ll come back to this when I start writing the code in the native applications to authenticate with AAD.
Now that I have applications that represent both the Mobile Service and the native client applications, I need to establish a trust relationship between them. From the Configure pane of the application for the native clients, select Add Application from the “permissions to other applications” section. Select Other in the Show dropbox and click the tick button to invoke the search. Select the application for the Mobile Service (ie in this case the Real Estate Inspector Mobile Service) and click the tick button at the bottom of the dialog.
From the Delegated Permissions dropdown, check the box next to “Access Real Estate Inspector Mobile Service” and click Save from the lower toolbar of the pane.
This completes the configuration of AAD to work with Mobile Service and Native Client applications. In the coming posts we’ll leverage this configuration to authenticate the mobile applications.