Azure AD ASP .NET Web Application

Hi all. Before I complete my series on Azure AD Provisioning with a look at how provisioning works with the Graph API, I want to take a detour and cover some Microsoft Visual Studio. Over the past month I’ve been spending some time building very basic applications.

As I’ve covered previously in my blog, integration is going to the primary responsibility of IT Professionals as more infrastructure shifts to the cloud. Our success at integration will largely depend on how well we understand the technologies, our ability to communicate what business problems these technologies can solve, and our understanding of how to help developers build applications to consume these technologies. In my own career, I’ve spent a significant time on all of the above except the last piece. That is where I’m focusing now.

Recently I built a small.NET forms application that integrated with the new Azure AD B2B API. Over the past few days I’ve been spending time diving with to ASP .NET Web Applications built with an MVC architecture. I decided to build an small MVC application that performed queries against the Graph API, and wow was it easy. There was little to no code that I had to provide myself and “it just worked”. You can follow these instructions if you’d like to play with it as well. If you’ve read this blog, you know I don’t do well with things that just work. I need to know how it works.

If you follow the instructions in the above link you will have a ASP .NET Web Application that is integrated with your Azure AD tenant, uses Azure AD for authentication via the Open ID Connect protocol, and is capable of reading directory data from the Graph API uses OAuth 2.0. So how is all this accomplished? What actually happened? What protocol is being used for authentication, how does the application query for directory data? Those are the questions I’ll focus on answering in this blog post.

Let’s first answer the question as to what Visual Studio did behind the scenes to integrate the application with Azure AD. In the explanation below I’ll be using the technology terms (OAuth 2.0 and Open ID Connect) in parentheses to translate the Microsoft lingo. During the initialization process Visual Studio communicated with Azure AD (Authorization Server) and registered (registration) the application (confidential client) with Azure AD as a Web App and gave it the delegated permissions (scopes) of “Sign in and read user profile” and “Read directory data”.

In addition to the registration of the application in Azure AD, a number of libraries and code have been added to the project that make the authentication and queries to the Graph API “out of the box”. All of the variables specific to the application such as Client ID, Azure AD Instance GUID, application secret key are stored in the web.config. The Startup.cs has the simple code that adds Open ID Connect authentication. Microsoft does a great job explaining the Open ID Connect code here. In addition to the code to request the Open ID Connect authentication, there is code to exchange the authorization code for an access token and refresh token for the Graph API as seen below with my comments.

AuthorizationCodeReceived = (context) =>
var code = context.Code;
// MF -> Create a client credential object with the Client ID and Application key
ClientCredential credential = new ClientCredential(clientId, appKey);
// MF -> Extract the access token from cache and generate an authentication context from it
string signedInUserID = context.AuthenticationTicket.Identity.FindFirst(ClaimTypes.NameIdentifier).Value;
AuthenticationContext authContext = new AuthenticationContext(Authority, new ADALTokenCache(signedInUserID));
// MF -> Acquire a token by submitting the authorization code, providing the URI that is registered for the application, the application secret key, and the resource (in this scenario the Graph API)
AuthenticationResult result = authContext.AcquireTokenByAuthorizationCode(
code, new Uri(HttpContext.Current.Request.Url.GetLeftPart(UriPartial.Path)), credential, graphResourceId);
return Task.FromResult(0);

Now that the user has authenticated and the application has a Graph API access token, I’ll hop over to the UserProfileController.cs. The code we’re concerned about in here is below with my comments.

Uri servicePointUri = new Uri(graphResourceID);
Uri serviceRoot = new Uri(servicePointUri, tenantID);
ActiveDirectoryClient activeDirectoryClient = new ActiveDirectoryClient(serviceRoot, async () => await GetTokenForApplication());
// MF -> Use the access token previous obtained to query the Graph API
var result = await activeDirectoryClient.Users.Where(u => u.ObjectId.Equals(userObjectID)).ExecuteAsync();
IUser user = result.CurrentPage.ToList().First();
return View(user);

Next I’ll hop over to the UserProfile view to look at the Index.cshtml. In this file a simple table is constructed that returns information about the user from the Graph API. I’ve removed some of the pesky HTML and replaced it with the actions.

@using Microsoft.Azure.ActiveDirectory.GraphClient
@model User
ViewBag.Title = "User Profile";
Display Name
First Name
Last Name
Email Address

Simple right? I can expand that table to include any attribute exposed via the Graph API. As you can see in the above, I’ve added email address to the display. Now that we’ve reviewed the code, let’s cover the steps the application takes and what happens in each step:

  1. App accesses
    • Get OpenID configuration for Azure AD
  2. App accesses
    • Retrieve public-keys used to verify signature of open id connect tokens
  3. User’s browser directed to
    • Request an open id connect id token and authorization code for user’s profile information
  4. User’s browser directed to
    • User provides credentials to AAD and receives back
      1. id token
      2. access code for graph API with Directory.Read, User.Read scope
  5. User’s browser directed back to application
    • Return id token and access code to application
      1. id token authenticates user to application
      2. Access code for graph API with Directory.Read, User.Read scope temporarily stored
  6. Application accesses
    • Exchanges access code for bearer token
  7. Application sends OData query to Graph API and attaches bearer token.

That’s it folks! In my next post I will complete the Azure AD Provisioning series with a simple ASP .NET Web app that provisions new users into Azure AD.

Azure AD User Provisioning – Part 2

Hello again. Today I will continue this series by examining the GUI options available within Microsoft’s Azure offerings to provision new user accounts. I am going to focus on member user objects and not guests for this series.

There are four native GUI options available that can be used to provision new user accounts in Azure Active Directory.

  1. Office 365 Administration Center
  2. Azure Management Portal
  3. Azure Portal
  4. ADUC/ADAC then synchronization to Azure AD

I’ll start with the Office 365 Admin Center. The Office 365 Administration Center is where most business will find themselves provisioning user accounts due to the popularity of the products under the Office 365 umbrella. The Admin Center provides an interface that is sleek and simple to navigate. The simplicity comes with a price. Administration of many aspects of Azure AD must be done outside of the Admin Center. This registering custom applications and applications from the application gallery, creation of additional directories such as B2C directories, B2B imports, and much more. Microsoft seemingly intends this interface to be business friendly administration endpoint for the Office 365 suite and rightfully assumes the consumers of this endpoint need simplicity.

I’ll now create a new user account. We first need navigate and login to the Office 365 portal. After the user authenticates the Office 365 home page that lists out the various applications the user has access to. I’ll next click on the Admin icon to enter the Admin Center. Next I will navigate to the Users section and select the Active Users section. This will bring us up a listing of the users currently in the Azure AD tenant associated with the Office 365 subscription.


When I hit the Add User button a new blade opens where the key components of the user’s account can be configured. This includes the first name, last name, user name and the like as seen in the screenshot below.


Let’s take some time to dig through the remaining sections.

First up is the contact information section. On-premise Active Directory administrators will recognize these fields from the various tabs in ADUC.


Next up is the password section. Here I have the option of creating a password or auto-generating a password and turning on or off the enforcement of a password change at first sign-in. I don’t recall there being an option to create a password a few months back when I was playing with the Admin Center, but that is one of the many lovely aspects of SaaS, continuous change and improvement.


Next up is the Roles section. Here there is an option to assign the user to the standard Azure AD roles or Office 365 roles. You can read more about these roles here.


Finally, the Licenses section allows for assignment of Azure AD and Office 365 licenses to the user account.


After the user is created it can be modified by clicking on the user object. Contact information about the user, membership into Azure AD groups, MFA enforcement, and product specific settings for the user can be modified in this blade.


The restoration of deleted users is simple and quick via the Deleted Users section. If only Microsoft had made it this easy in the old days of on-premises Active Directory prior to the Active Directory Administration Center.


Users can also be added in bulk by uploading a CSV file by hitting the More button in the Active Users section.


The Office 365 Admin Center interface is sleek and simple, perfect for a business user or Tier 1 support staff. So what’s the problem? No matter how simple the interface, it’s another process and interface staff need to learn. There is also no way to technically enforce standards for data input. What if what user puts MA and another puts Massachusetts? What about a user who misspells accountant in the job title field? Human error and lack of standardization can make for some nasty operational headaches, not to mention security risks. If an organization wants to limit the new processes and interfaces its staff needs to learn (because really, where is the business value in that?) as well as making sure the data about a user is standardized and correct, making these changes programmatically is the way to go.

In my next post I’ll cover both the Azure Management Portal and the Azure Portal.

Azure AD User Provisioning – Part 1

Welcome back! Over the past year I’ve done a number of deep dives into Azure AD authentication, but what is authentication without an identity? They have to get there somehow, right? Gone are the days of legacy protocols such as LDAP or executing a command to a database to provision a local user. Identity as a service offerings such as Azure AD introduce whole new ways to provision users, both manually through the GUI and through programmatic methods such as PowerShell or the Graph API. For this upcoming series of blogs I’m going to cover the many options available with Azure AD and the plusses and minuses of each.

Let’s begin this series by talking about “legacy” tools versus “modern” tools. What do I mean by legacy? Well I mean administrative graphical user interface (GUI) options. Why are administrative GUIs legacy? Well, cloud is primarily about automation, scale, and simplicity. To achieve those ideals, “cloud” services (whether they are IaaS, PaaS, SaaS, or IDaaS) must be capable of integrating well with other solutions, whether they be COTS or custom. Pay attention to the word “integration” people. It is more important than ever.

Administrative GUIs represent the old IT where the business had to depend on IT to administer and support its technologies. This was costly in the ways of labor, time, and complexity. The focus on standardized application programming interfaces (APIs) that is happening in the cloud is attempting to streamline this process for the business. These APIs provide a programmatic method of integration with the cloud solutions to take the middle man (IT) out of the equation and put the business users in the driver’s seat. Existing COTs or custom applications can be integrated directly with these APIs to simplify and automate a number of processes that typically fell into IT’s realm.

So what are some examples?

  • Scenario: Business user needs to share a document with a partner company

    In the “old” days, the business would have to rely on IT to setup complicated VPN solutions to allow for connectivity and either provision users directly in the identity data store or configure Active Directory trusts. With the standardized APIs emerging in the cloud, an existing identity management system can be directly integrated with an IDaaS API.

    If the business takes advantage of the programmatic access, the business user clicks a button of the person or persons he or she wishes to share the document with, the request goes to an approver such as the data owner, and the provisioning is done automatically by the application. No service requests or multiple day turnarounds from IT required here. The value presented by IT in here was the initial integration, not much else.

  • Scenario: Business focuses on application development and a developer requires a new web instance to test code

    In “legacy” IT the developer would need to submit a request to IT to provision a server, install and configure the appropriate middleware, and have security staff verify the server and applications have been configured for compliance. The developer would then need to wait to be provisioned for access as well as deal with the continued maintenance of the web instance. All of this took time and this was time the developer wasn’t developing, which impacts the businesses ability to deliver the product and service they’re in business to deliver.

    We know the value that PaaS provides here, but what about the APIs? Well, envision a service catalog where a developer requests an instance of a web platform that is automatically provisioned and configured to the businesses baseline. Where was IT in this scenario? They setup the initial integration and keep the baselines up to date, and that’s it. Not only does the business save money by needing less IT support staff but its key assets (developers) are able to do what they’ve been hired to do, develop, not submit requests and wait.

In the above two scenarios (and there are oh so many more), we see that IT professionals can no longer focus on a single puzzle piece (server, OS, networking, identity, virtualization, etc), but rather how all of those puzzle pieces fit or “integrate” together to form the solution. Cloud as-a-service offerings made the coffin and simple APIs are the nails sealing the coffin finally putting the “legacy” IT professional to rest.

So why did I spend a blog entry talking about the end of the legacy IT professional? I want you to think about the above as I cover the legacy and modern provisioning methods available in Azure AD. As we explore the methods, you’ll begin to see the importance programmatic access to cloud solutions will play in this cloud evolution and the opportunities that exist for those IT professionals that are willing to evolve along with it.

In my next post to this series I will cover the various GUI methods available for user provisioning in Azure AD.

Experimenting with the Azure B2B API

Hello all!

On October 31st Microsoft announced the public preview of the Azure B2B Invitation API. Prior to the introduction of the API, the only way to leverage the B2B feature was through the GUI. Given that B2B is Microsoft’s solution to collaboration with trusted partners in Office 365, the lack of the capability to programmatically interact with the feature was very limiting. The feature is now exposed through Azure’s Graph API as documented here.

A friend challenged me to write a script or small application that would leverage the API (Yes we are that nerdy.) Over the past year I’ve written a number of PowerShell scripts that query for information from OneDrive and Azure AD so I felt I would challenge myself by writing a small .NET Forms application. Now I have not done anything significant in the programming realm since freshman year of college so I thought this would be painful. Thankfully I have a copy of Visual Studio that comes with my MSDN subscription. All I can say is wow, development solutions have evolved since the 90s.

I won’t bore you with the amount of Googling and reading on MSDN I did over the weekend. Suffice to say it was a lot. Very tedious but an awesome learning experience. I can see a ton of re-use of the code I came up with for future experiments (even though I’m sure any real developer would point and laugh).

Before I jump into the detail, I want to mention how incredibly helpful Fiddler was in getting this all working and getting a deep dive understanding of how this all works. If you’re interesting in learning the magic of how all this “modern” stuff works, a tool like Fiddler is a must.

First off we need to register the application in Azure AD as a Native App to obtain a Client ID per this article. Next we need to grant the application the delegated right to read and write directory data as described in the MS article introducing the API. Once the application is registered and the rights have been granted, we can hammer out the code.

Before I jump into the code and the Fiddler traces, one thing that caught my eye in the returned json object was an attribute named invitedToGroups. If you’re familiar with the Azure B2B functionality, you’ll recall that as part of the B2B provisioning process, you can add the user object to a group. This is very useful in saving you time from having to do this after the user accepts the invitation and their user objects populates in the Azure AD. What’s odd about this is this attribute isn’t documented in the Microsoft blog I linked above. Digging into the github documentation, it looks like the information about it was removed. Either way, I decided to play around it with, but regardless of whether or not I followed the schema mentioned in the removed Github documentation, I couldn’t get it to take. I am fairly sure I got the schema of the attribute/value pair correctly, so we’ll have to chalk this up to MS playing with feature while the functionality is in public preview.

So let’s take a look at the code of this simple Windows form application, shall we?

In this first section of code, I’m simply pulling some information from the input fields within the forms application.

// Pull data from user input fields
string tenantid = tenant.Text;
string emailaddress = email.Text;
string redirectsite = redirect.Text;
string group = GroupID.Text;

In this new section of code, I’m leveraging functions from the ADAL library to redirect the user to authenticate against Azure AD, obtain an authorization code for the graph API, and submit that code for an access token for the Graph API.

// Authenticate user and obtain access token
AuthenticationContext authcontext = new AuthenticationContext("" + tenantid);
AuthenticationResult token = authcontext.AcquireToken("", clientid, redirectURI, PromptBehavior.Always);

In this section of code I build an instance of the httpclient class that will be used to submit my web request. You’ll notice I’m attaching the bearer access token I obtained in the early step.

// Deliver the access token to the B2B endpoint along with the posting the JWT with the invite information
string URL = "";
HttpClient client = new HttpClient();
client.BaseAddress = new Uri(URL);
client.DefaultRequestHeaders.Authorization = new
System.Net.Http.Headers.AuthenticationHeaderValue("Bearer", token.AccessToken);

Here I issue my HTTP request to post to the invitation endpoint and include json object with the necessary information to create an invitation.

HttpRequestMessage request = new HttpRequestMessage(HttpMethod.Post,
request.Content = new StringContent("{"invitedUserEmailAddress":"" + emailaddress + "","inviteRedirectUrl":"" + redirectsite + "","sendInvitationMessage":true,"invitedToGroups":[{"group":"" + group + ""}]}", Encoding.UTF8, "application/json");
HttpResponseMessage response = await client.SendAsync(request);

Finally I parse the json object (using the Newtonsoft library) that is returned by the endpoint to check to see whether or not the operation was completed.

string content = await response.Content.ReadAsStringAsync();
Newtonsoft.Json.Linq.JToken json = Newtonsoft.Json.Linq.JObject.Parse(content);
string myresult = json.Value("status");

Quite simple right? It had to be for someone as terrible as developing as I am. Imagine the opportunities for an API like this in the hands of a good developer? The API could be leveraged to automate this whole process in an enterprise identity management tool allowing for self-service for company users who need to collaborate with trusted partners. Crazy cool.

This is the stuff I applaud Microsoft for. They’ve take a cumbersome process, leveraged modern authentication and authorization protocols, provided a very solid collection of libraries, and setup a simple to use API that leverages industry standard methodologies and data formats. Given the scale of cloud and the requirement for automation, simple and robust APIs based upon industry standards are hugely important to the success of a public cloud provider.

This whole process was an amazing learning experience where I had an opportunity to do something I’ve never done before and mess with technologies that are very much cutting edge. Opportunities like this to challenge myself and problem solve out of my comfort zone are exactly why I love IT.

I hope the above post has been helpful and I can’t wait to see how this feature pans out when it goes GA!

Feel free to reach out if you’re interested in a copy of my terrible app.