Integrating AngularJS with Azure Active Directory Services and Office 365/SharePoint, Part 3

Adding AAD configuration and assemblies into an application

Dan Wahlin

by Dan Wahlin on 12/29/2014

Share this:

Article Details

Date Revised:

Applies to:
AAD, AngularJS, Azure Active Directory, Dan Wahlin, Office 365, SharePoint Online

Sponsored by

The Microsoft Office 365 team is the sponsor of this series.

You can choose from many different techniques to authenticate users in an application. You can build a custom solution using a file or database, you can use Active Directory, you can deploy a third-party solution, or you can use a cloud-based service, to name just a few. Every situation is unique so the authentication choice made really depends upon the requirements of the application. In cases where an application can be used from a variety of locations and devices, a cloud-based authentication solution can work quite well.

Part 2 of this article series showed the process for registering an application with the Azure Active Directory (AAD) cloud service. Once you’ve registered an application, you can configure the Client ID and key created in AAD in your custom application. You can then add AAD assemblies to provide authentication functionality.

In this article, I’ll discuss how to get the necessary configuration and assemblies in place to tie the AngularJS Expense Manager application discussed in Part 1 to AAD so that users can authenticate into Office 365 services. In Part 4 I will provide a walk-through of the code that needs to be added into the application to enable user authentication with AAD.

Let’s start by discussing the assemblies that need to be installed into the application and how you can simplify that process by using NuGet.

Installing the required assemblies using NuGet

Once an application has been registered with AAD (refer to the Part 2 article for step-by-step details on doing that) you can begin the process of integrating AAD authentication into the application. To get started, you’ll need to add several assemblies into your project including some AAD-specific assemblies as well as OWIN assemblies. The AAD assemblies will be used to communicate with AAD while the OWIN assemblies will be used to hook AAD authentication into the custom application. Here’s a step-by-step walkthrough of getting the assemblies into a project.

Create a new ASP.NET MVC application in Visual Studio (the sample application is named “ExpenseManager”). Now select Tools → NuGet Package Manager → Package Manager Console from the Visual Studio menu.

Once the Package Manager Console is open, run the following commands in it to get the necessary assemblies into place as shown in Figure 1.

Use NuGet to install the AAD assemblies to communicate with AAD and the OWIN assemblies to hook AAD authentication into the custom application

Figure 1. Installing NuGet packages using the Package Manager Console.

Type each of the following commands into the command-prompt area and press Enter to install the specific Nuget package:

  • Install-Package -Id Microsoft.Owin.Host.SystemWeb
  • Install-Package -Id Microsoft.Owin.Security.Cookies
  • Install-Package -Id Microsoft.Owin.Security.OpenIdConnect
  • Install-Package -Id Microsoft.IdentityModel.Clients.ActiveDirectory

After installing the Nuget packages, open the References node in the Solution Explorer and note that several new assemblies have been added that are related to AAD and authentication. Figures 2 and 3 show a few of the assemblies that are added:

AAD-specific assemblies used to communicate with AAD

Figure 2. Assemblies related to AAD.

OWIN assemblies used to hook AAD authentication into the custom application

Figure 3. OWIN assemblies.

Now that the essential assemblies are installed, it’s time to add the application’s AAD Client ID and Key into the application. These values are needed to “hook” the application to AAD.

Note that all of the code that follows is from the Expense Manager application that’s available on the OfficeDev GitHub site.

Configuring the Client ID, Key, and Tenant ID

When an application is registered with AAD, you’re provided with a Client ID, Key (which is your password), and Tenant ID. These values need to be added into your custom application to “hook” it to AAD during the authentication process. To get these values, login to the Azure portal, click on the Active Directory option and locate the directory where your custom application was registered.

Click on the target directory and then locate the Applications item in the menu. After clicking on Applications you can select the application that was previously registered with AAD. Next, click the Configure item in the menu to get to the Client ID and Key. An example of what these values looks like once you’re in the application’s configuration screen is shown in Figure 4.

Accessing the Client ID and Key in AAD for a registered application

Figure 4. Accessing the Client ID and Key in AAD for a registered application.

If you didn’t store the key value when you initially registered the application, it won’t be available to you now. In that case, you can delete the old key if it’s not already being used (be careful here!) and create a new one by selecting a value from the dropdown. Keys can have a duration of 1 or 2 years. After you save the application configuration changes, the key will be displayed. Make a note of the Client ID and Key before continuing.

Look up at the URL in your browser and find the GUID value that follows /Directory in the URL (it’ll be in the TENANTID_GOES_HERE section of the URL below):

This GUID value is your Tenant ID and is required as well, so make a note of it.

Now that the Client ID, Key, and Tenant ID are available, open your application’s web.config file in Visual Studio and add the following code into the <appSettings> section to configure the AAD values:

<!-- Update your Tenant, TenantID, ClientID and Key/Password values
    from Azure Active Directory -->
<add key="ida:Tenant" value="YOUR TENANT NAME" />
<add key="ida:TenantID" value="YOUR TENANT ID" />
<add key="ida:ClientID" value="YOUR CLIENT ID" />
<add key="ida:Password" value="YOUR KEY/PASSWORD" />
<add key="SharePointDomainUri" value="https://{0}" />
<add key="SharePointApiServiceUri" value="https://{0}" />
<add key="ida:AuthorizationUri" value="" />

Listing 1. Configuring AAD application settings.

The ida:Tenant value will be the tenant value you signed up with while the ida:TenantID, ida:ClientID, and ida:Password values are the ones you noted previously while in the AAD application configuration screen.

Now that you have the application values in place, let’s create a helper class to simplify getting to the settings in web.config. This class will be used throughout the application to retrieve configuration values that are needed to setup AAD authentication as well as handle calls into Office 365 APIs.

Creating a SettingsHelper class

Although .NET classes such as ConfigurationManager and WebConfigurationManager can be used to access web.config values, the Expense Manager application relies on a SettingsHelper class to handle this task. By using a helper class, the other classes included in the application can rely on a central object to retrieve values and even access URLs that are dynamically generated based upon the web.config values as you’ll see next.

Create a new folder in your ASP.NET MVC project named Utils and add a class into it named SettingsHelper.cs. This class will be responsible for looking up the values configured in web.config and making them easier to access throughout the application. Add the following code into the SettingsHelper class:

using System;
using System.Collections.Generic;
using System.Configuration;
using System.Linq;
using System.Web;

namespace ExpenseManager.Utils
   internal class SettingsHelper
       static string _AzureADUri = "";
       static string _GraphResourceId = "";
       static string _O365DiscoveryServiceEndpoint = 
       static string _O365DiscoveryResourceId = "";
       static string _ClaimsObjectIdentifier = 
       static string _ContactsCapability = "Contacts";

       public static string Tenant
           get { return ConfigurationManager.AppSettings["ida:Tenant"]; }
       public static string TenantId
           get { return ConfigurationManager.AppSettings["ida:TenantID"]; }
       public static string ClientId
           get { return ConfigurationManager.AppSettings["ida:ClientID"]; }
       public static string ClientSecret
           get { return ConfigurationManager.AppSettings["ida:Password"]; }
       public static string O365DiscoveryResourceId
           get { return _O365DiscoveryResourceId; }
       public static string O365DiscoveryServiceEndpoint
           get { return _O365DiscoveryServiceEndpoint; }
       public static string GraphResourceId
           get { return _GraphResourceId; }
       public static string AzureADAuthority
           get { return string.Format(_AzureADUri + "/{0}/", TenantId); }
       public static string ClaimsObjectIdentifier
           get { return _ClaimsObjectIdentifier; }
       public static string ContactsCapability
           get { return _ContactsCapability; }
       public static string SharePointDomainUri
           get { return String.Format(ConfigurationManager
                  .AppSettings["SharePointDomainUri"], Tenant); }
       public static string SharePointApiServiceUri
           get { return String.Format(ConfigurationManager
                  .AppSettings["SharePointApiServiceUri"], Tenant); }

Listing 2. The SettingsHelper code handles looking up configuration values needed to communicate with AAD.

Looking through the code you can see that SettingsHelper wraps the ConfigurationManager class. It provides properties such as AzureADAuthority, TenantId, ClientId, and ClientSecret. These properties provide a convenient way for the application to access the values configured in web.config. In some cases, the values are formatted into URLs that are required by the application. The other properties such as SharePointDomainUri and SharePointApiServiceUri are used to define Office 365 API information that will be discussed in future articles in this series.


Now that the AAD values have been configured and a SettingsHelper class is in place, it’s time to plug AAD-specific code that enables authentication into the application. That is the subject of the next article in this series.

Topic: Development

Sign in with

Or register