Essentials Of Azure AD Application Roles

The basics

One could do some simple guesswork here and understand that the roles required in the application may be called application roles, and this is correct! When we speak of roles, roles are always associated with users and when we say users, then these are the people using the software or the application. Roles could be anything specific to the application; i.e. Administrator, User, Approver, Reviewer etc.

Let us take a moment and go back in the time when ASP.NET forms development was at its peak. People who have worked with it might remember that we used to have something called as ASPNET membership provider database which used to store the user’s credentials and that’s how we used to implement the forms based authentication right? Now extend that database and we had roles of the users sitting at the same table.

The concept remains the same, however with the evolution of distributed and disconnected systems identity and user roles have become the core of the entire ecosystem. In the world of Microsoft Azure, the Azure Active Directory has become one of the most mature identity management solutions and has lots to offer apart from identity management of users; i.e., domain services, but that’s something for later. For this article let’s keep ourselves focused on understanding application roles.

Let’s take out the old buddy --  ASPNET membership provider -- out of the picture for now and focus on the web application which uses Azure Active Directory for user authentication. So essentially, we are speaking of the user credentials store and now try asking yourself a question – hey like we used to have various roles to application users in classic forms authentication, so can I have the same here in this user credentials store too (Azure AD)? The answer is yes and Azure AD caters to this requirement by providing you the application roles.

One of the crucial points to note here in Azure AD application roles is that we are not only restricted to assign these roles to application users from AD but we can also assign these roles to Azure AD groups however for AD group assignments, it needs to have Azure AD premium.

What about Multi-tenancy?

Well, nothing needs to be changed when we decide to open our App for multiple Azure AD tenants.

Simple fact is, as the name suggests these roles are associated with the Azure AD app so in multi-tenant scenario, all the roles which are created and enabled inside the home tenant (the root tenant where Azure AD app is provisioned) are available for the users from different Azure AD tenants and hence customer tenant administrators would easily be able to assign their tenant users or groups to the application roles.

Let’s try and visualize it for simplicity

Well, we have tried to keep things too simple and if you are still following, then let us go and see how application role behaves in the real-world scenario and to understand it, let us go ahead and see how can we create these application roles inside Azure AD application. For beginners, this probably would start from the point of locating application settings in Azure AD

This article assumes that you know the procedure to create the Azure AD application inside your Azure AD tenant so we will not go through the detail procedure to do it but in case you are not aware of it, then before proceeding, it is highly recommended that you look at this comprehensive documentation of doing it step by step – Azure AD application registration

Seeing it all in action

Consider that we have already created an Azure AD application. Let’s navigate to it using new Azure portal, once there click on Manifest option as shown in image below



This essentially opens an editor where you will be shown a Json file, this file is called as Manifest of your application and contains almost all the settings which you see on the UI to configure your AD application e.g. reply urls or app permissions.

For creating application roles, we are interested in a node which you will find right below app Id node and it is empty array by default.



Let’s initialize this empty array with values and these values will be our different application roles. The application role object consists of a number of properties e.g. Role Id, name, description, display name etc.

Assume that our application needs to have three different user roles i.e. Admin, Reviewer, and Approver.

So, we are going to create three appRole nodes and add it to app Roles array which is currently empty.

After edit, manifest should look like this.



Few important points to note about these properties,

• allowedMemberTypes could be User or Application.
• Value field appears in the role claim returned by the identity provider.

Now that we have created the app roles for our application, let’s learn about how we can assign these roles to users.

Let’s go back to the Azure portal and navigate to the enterprise applications section. Select "Manage Applications" and list of all applications registered with Azure AD will be shown. Search for our application and select it.

Once the application is selected, click on Users and groups and select Add User.



Select the user and proceed with role selection.



And that’s it, you have successfully set up the application roles and ready to use them.

Integration with web applications

Now the next and important part, i.e. how do I consume these application roles inside my application?

Let's take a look at it using an example - suppose we are developing a web application say using ASP.NET MVC which needs to have the above roles integrated into it. Since the application is going to leverage Azure AD as it's identity provider using OAuth, so OWIN comes to the rescue and can make things quite easy for developers.

If you are not familiar with OWIN then it is highly recommended to go through this article Jump before moving ahead, however, in a nutshell, OWIN is a component which sits in front of your web application and takes care of all the authentication/redirection magic. The best part of it is, the component is highly configurable so that it can cater as a solution for multiple use cases.

Let's take a look at the piece which tells Azure AD that hey look, give me application role details in claims for the user who is logging in. This is just a one-liner configuration which we will be doing in the ConfigureAuth method in Startup.Auth class file. Note that, value field mentioned while creating the application roles will be returned in the claims.



Once it is configured, it is almost all done. We now will be able to get all the role names assigned to the user as a claim.

There could be multiple ways using which now you will be able to consume the roles in your application, however, in ASP.NET MVC the typical ways to do it using the Authorize attribute which can be applied to classes or action method and User class. Let's take a quick look how it is done

[Authorize(Roles = "Admin")]
public class AdminController : Controller
{
      public ActionResult Index()
      {
          return View();
      }
}

In the example above, the Admin controller and all the action methods inside it would be accessible to the users who are in the Admin role. Roles parameter can accept the comma-separated string of role names.

Another option is to make use of User class as below, say in a scenario where we want to render the content conditionally on the page

@if (User.IsInRole("Admin"))
{
     @Html.ActionLink("Administrator", "Index", "Admin")
}

Conclusion

That's a wrap, folks! The Azure AD application roles are truly powerful and open up numerous opportunities for us to leverage them in our applications and can really come handy when it comes to the user and their role management.