Today I want to tell you about some a new set of developer preview features we've recently added to Windows Azure AD. With these updates, you can now use Windows Azure AD to secure access between smart client apps and the backend web API's they access running in Azure (or other cloud services).
To try it out now, sign in to the Windows Azure Management Portal. Then open your directory, click on the list of applications, and add a new application.
If you're writing a Windows Store application or a smart phone application for an organization and your application accesses a set of web API's, you'll probably want that web API to run securely in the cloud. Using Windows Azure AD you can secure that web API t so that only authorized users in your organization can access it from the client apps you've built for them.
Creating this type of modern client application generally involves three components:
For a more detailed end-to-end scenario, check out Vittorio Bertocci's presentation at the recent Build conference: Securing Windows Store Applications and REST Services with Active Directory
Adding your web API and integrating it with Windows Azure AD
Obviously the first step is to write you web API and your native client application. Click here for instructions on how to do that using ASP.NET, including code samples. Once you've done that you're ready to try out the new experience in the Windows Azure Management Portal.
The next step is add the web API to your Windows Azure AD tenant. To do this, go to the Windows Azure Management Portal and click on Active Directory from the left menu. Click on the name of the directory to open it. Then, navigate to the Applications tab and click the Add button in the command bar. On the first page of the Add Application wizard, enter the friendly name for your application in the Name field.
Fig 1: Adding a Web API to Windows Azure AD
On the second step of the wizard, enter the URL to access the web API in the App URL. Then, enter the App ID URI for the web API. The App ID URI is an identifier which uniquely identifies your app in your Windows Azure AD directory, and must be in the form of a URI.
Fig 2: Setting the properties of a web API
On the third step of the wizard, specify the type of access that your application needs to directory data in Windows Azure AD. If you only need to secure user data in your web API using Windows Azure AD accounts, choose the default option: Single Sign-On. If your web API also needs to read or write data from the Windows Azure AD Graph API, choose the radio button that corresponds to your requirements.
Fig 3: Specifying the access that a web API needs to data in Windows Azure AD
Click the checkmark button to complete the wizard. Your web API will be added to your Windows Azure AD directory, and you'll be taken to the Quick Start page for your newly added web API.
Fig 4: The Quick Start for a web API, showing values that need to be included in the code for the web API
Adding your native client application and integrating it with Windows Azure AD
At this point, you have a web API registered in AD. It will respond to requests from authorized native client applications that present the correct OAuth access token.
The next step is to add your native client application to Windows Azure AD, after which you'll authorize its access to your web API. To do that navigate to the list of applications in your directory and click the Add button in the command bar at the bottom of the screen. On the first step of the Add Application wizard, enter the friendly name for your native client application in the Name field.
Fig 5: Adding a native client application to Windows Azure AD
On the second step of the wizard, enter the redirect URI, which is the URI to which Windows Azure AD will redirect in response to an OAuth 2.0 request. The value does not need to be a physical endpoint, but must be a valid URI.
Fig 6: Setting the redirect URI for a native client application
Click the checkmark button to complete the wizard. Your native client application will be created in your Windows Azure AD directory, and you'll see the Quick Start page for the native client application.
Then, follow the instructions on the Quick Start page for the native client application. First you will need to copy the Redirect URI and the Client ID from the Quick Start page and add these values in the code for your native client application.
Fig 7: The Quick Start page for a native client application, showing the values that need to be included in the code for the native client application
Configuring Access to Your Web API
The next step is to authorize the newly added native client to access the web API. Begin this by clicking on the Configure tab of the native client application, and then locate the web APIs section at the bottom of the page. Click on the dropdown control labeled Choose web APIs and select the web API that provides resources to your native client application.
If your client needs access to additional APIs, you can select them by clicking the dropdown again. The dropdown shows all of the web APIs in your directory, including the Windows Azure AD Graph API. Once you've selected all the APIs accessed by your native client application, click Save in the command bar.
Fig 8: Configuring access by the native client application to the web API
Once your changes have been saved, you've completed the required configuration: a user who installs your native client application can use it to call the web API that is now secured using Windows Azure AD.
A full walkthrough of the scenario including code samples is available here: Securing a Windows Store Application and REST Web Service Using Windows Azure AD (Preview).
More on the way!
For this release, the native client application, the web API, and the user accounts must be in the same Windows Azure AD directory and thus are best suited for company specific line-of-business apps. Over the coming months we'll expand this functionality to enable native client applications to access multi-tenant web APIs, including APIs for Microsoft Services, that secure resources for users in multiple Windows Azure AD directories.
And as always, we'd love to hear your feedback on these new capabilities!
Alex (Twitter: @Alex_A_Simons)
Director of Program Management