General Roles-Based Access Control in the .NET backend

Lately, I’ve received a lot of questions related to roles-based access control (RBAC). It’s a great, clean way to define which users have which permissions, where a user is assigned to one or many “roles,” and your resources are protected by specifying which roles are allowed to access them. I recently wrote a post on basic RBAC for AAD using the Node.js backend, but today I’ll tackle a more generalized case, and I’ll do it using the new .NET backend preview.

Let’s assume I’m building a simple consumer forums application, in which I want an option to mark posts as “sticky.” This means it will always appear at the top of the posts list. My forum would likely end up in a bad state if I let all users do this, so I want to restrict the action to moderators only. All of my users will be authenticated via Facebook, and I’ll be keeping track of their roles (moderator or not) within a database table in my application.

So the question arises: how do I make it so that only moderators can mark a post as “sticky?”

To start things off, let’s take a look at the target programming model. I’ll be working with a ForumPost object and its associated controller. Since we’re making a change to an existing post we’ll be protecting the HTTP PATCH method. Here’s the controller, with just the PATCH method:

Looks nice and simple, right? We just decorate the method with an attribute specifying the allowed roles. It’s pretty similar to the AuthorizeLevel attribute that Mobile Services provides by default with the .NET backend. In fact, we’ll be replicating a bit of that attribute’s functionality as we go through this process.

Creating a custom authorization attribute

So first, let’s address the creation of an attribute. The basic premise is that you need to derive from the abstract class Attribute. In our case, we’ll be using the concrete subclass AuthorizationFilterAttribute, which will make things a bit simpler for us. There are basically two parts needed here: a constructor which turns the annotation into usable data, and an OnAuthorization() method which will get called when a user attempts to access the endpoint.

As you can see, I’m actually accepting an arbitrary number of roles, which would be separated by commas in the annotation. I’m then storing these in a HashSet for easy lookup when we get to OnAuthorization(). Everything is being handled as strings here, but you could certainly work with enums, which would make the experience a little cleaner when you go to protect your endpoints.

The other important thing to note is the AttributeUsage section, where I’ve said that the attribute can decorate both full controllers or just individual methods. Also, since I accept a variable number of arguments, I’ve gone ahead and restricted developers to using one instance of this attribute per method/controller.

Authorizing the user

Now we can focus on the OnAuthorization() method, which is where we will make the decision about whether or not the decorated method/controller can be accessed. We need to get a notion of the currently logged-in user and their roles, so first we need to make sure that someone is actually logged in. In doing so, we’re technically replicating the behavior of AuthorizeLevel attribute, as if we’ve set the value to “User.” After we’ve cleared that hurdle, we can check for roles.

One option is to, if applicable, use the associated identity provider’s graph. However, many cases will look similar to today’s scenario, where the role is completely application-level, perhaps stored in the database. You can see that I’m just querying my table to get the roles held by the user. Regardless of what method you choose, once you have your roles, you can just cross-check against the list specified by the attribute.

And that’s pretty much all you need to do! Just place this class in a location accessible to your backend project, and you have all you need to get started protecting your APIs at fine granularity. The approach should work across identity providers – in fact, you may have noticed that while I mentioned Facebook in the scenario description, nowhere in my code did I care where the user came from.

As a next step for the enterprise-inclined: you can take my post on RBAC with AAD (in Node) and combine those concepts with this solution pretty easily. I should hopefully have a post out soon covering more of the cool things you can do with AAD and the .NET backend, so keep an eye out for that.


Mobile Services Forums – In keeping with today’s theme, and because it’s a great place to turn if you have questions about anything Mobile Services.
Mobile Services UserVoice – While we’re at it, we’re always looking for feedback, so please make yourself heard here!
Getting Started with the .NET backend – There’s a lot of cool new things you can do with the new .NET backend. It should feel familiar to ASP.NET WebAPI developers, but even if you’re new to that stack, it’s easy to get started. Try it out!
Getting Started with Authentication in the .NET Backend – This shows you how to work with social providers. For AAD, see below.
Getting started with AAD in the .NET Backend – AAD for the .NET runtime is only available via a client flow right now. This tutorial will get you started.

Roles-Based Access Control in Mobile Services and Azure Active Directory

This post originally appeared on the Azure blog on 3/11/2014. I am posting it again here for convenience.

In November, we announced a preview of Azure Active Directory (AAD) as an identity provider for Mobile Services. The mission was to give enterprise developers an easy solution for building employee-facing mobile apps. Basic authentication is a great start, but in many cases our current preview customers have needed to distinguish between types of users in order to make authorization decisions. Roles-based access control (RBAC) is the idea of assigning permissions to roles that your users can hold, nicely defining boundaries on what certain classes of users can and cannot do. Luckily, it is very easy to add basic RBAC to Azure Mobile Services, and this post will walk you through how to accomplish that.

In order to follow along with the rest of this post, you’ll need to be enrolled in the Mobile Services preview for Azure Active Directory integration. If you would like access, please email


Let’s imagine that I want to develop an application just for my sales team. In order to access the app, a user not only has to be a member of my company’s directory, but also assigned to the sales group.  Let’s take a look at the logic you’d need to add on the server-side to ensure that only authenticated members of the sales team can access the app. (If you’re just getting started with Azure Active Directory Authentication in Mobile Services, you may find this getting started tutorial helpful.)

The basic approach we’ll be taking is to leverage security group membership for users in our Azure AD tenant. AAD has the concepts of both roles and groups, but in today’s scenario we’re working with an existing group that already has the correct user membership. We’ll be managing our group from an on-premises AD tenant that is synced with our Azure AD tenant. Customers of O365 and Windows Intune can attest that you get a lot of power by setting up a directory sync with on-premises Active Directory (and you can even use those tenants to build Mobile Services).


Today, I’m going to be using the “Password Sync” option, but there are multiple scenarios supported. You can actually set up AAD to point to ADFS for a great hybrid scenario. If you want to play with these options, spin up an Azure VM running Windows Server 2012 R2 Datacenter and install the Active Directory Domain Services role. Then follow the directory sync instructions.

Creating Groups

Within my directory, you can see that I’ve created some users (Alice, Bob, Carol, and Dave) as well as a “Sales” domain security group. I’ve made Alice and Bob members of this group, but Carol and Dave remain outside it and should not have access to my app. Everything else is default.


Connecting to Azure Mobile Services

So I’m now ready to start building my app backend. In an Azure mobile service, we want to protect each of our scripts and APIs with additional authorization logic on top of what is provided. For some extra sanity, I’m going ahead and setting permissions to “Only Authenticated Users” for each protected endpoint.


Because I’m building logic that I want executed in multiple scripts, I’m putting my code in the shared scripts section of my mobile service’s Git repository. I’m naming the script rbac.js.

The first step to determining group membership is to gain access to the AAD graph API. Setting this up is covered in this blog post as well as in this sample. The following will get you started:

Once we have the graph access token, we need to call the isMemberOf graph endpoint. This will check if the specified user is a member of a given group, including transitive membership. We can get the user ID from the script being checked – all table scripts explicitly receive a user object, and you can get one from a Custom API by accessing request.user. We’ll need to obtain a group ID, which is conveniently available in the management portal. Head into your Azure AD tenant, open the groups tab, select the group, and copy the Object ID from under the configure tab.


For ease of use, we’ll export the value from our shared script with a friendly name.

We’ll now want to write a function to wrap our call to the AAD isMemberOf endpoint. As mentioned before, we’ll need both the userID and the groupID we just obtained. The request also needs to include the access token that we obtained.

We’ll simplify the programming model a bit and just require the Mobile Services user object (from which we can get the objectID), as well as the group ID. We’ll wrap it up nicely to get the graph token for us and make the call. Note that in production, you’ll really want to cache this token instead of fetching it every time. The token contains an expiration value that you can use to determine when you should fetch a new one.

That’s all for the shared script. Now, for each script that I want to protect with RBAC, I just have to add a few lines and perform the script’s work in my callback. Here’s an example for a table read:

Wrapping Up

And that’s it. We’ve successfully restricted our app usage to the subset of our employees that needs it. From here, you can start building for a variety of RBAC scenarios. If you find that you want to differentiate the client UI for certain users, one simple way to do this is to expose the membership check as a Custom API, which you can invoke immediately after login.

Azure Active Directory is doing some cool things with their group support, and a lot can be accomplished straight from the management portal. AAD Premium users should be sure to check out the new self-service group management support.

If you are interested in enterprise mobile app development, I encourage you to also check out the new Mobile Services .NET backend preview. It does not currently have built-in AAD support, but don’t worry! We will have it available soon.

And again, if you’re interested in joining the AAD preview or have any questions, please reach out to us at

If there are additional features or scenarios you’d like to see covered, please submit your feedback to our uservoice.

Accessing AAD Graph Information from Azure Mobile Services

Azure Mobile Services recently announced a preview of Azure Active Directory (AAD) as an identity provider, opening up a lot of new opportunities for enterprise application building. Syncing with an on-premises Active Directory instance allows employees to sign in to your apps with their corporate credentials, but of course you can also use AAD’s built-in user management. If you are interested in trying out the preview, be sure to email the Mobile Services team.

Like the other identity providers we offer with Mobile Services, AAD offers a rich graph API which can be used to obtain information about a user. In this post, I’ll show you how to personalize a user’s app experience based on that information. On the server, we’ll write a custom API which will contact AAD and return basic graph data. The mobile client will call this API following each login and use the data to welcome the user to the app. This post assumes that you already know how to connect a Mobile Service to an AAD tenant for authentication.

The AAD Graph

The AAD team has some nice samples for the Graph API, but unfortunately none are for Node.js. There exist some third-party Node modules for AAD integration, but today we’ll be going straight to the AAD REST API. Our good friend the request module will help here. Go ahead and create the custom API now – I called mine “getIdentities” since we’re basically mimicking a server-side function that we’ll be using later. Set the permissions to “only authenticated users.”

The AAD graph operates a bit differently from that of other providers in that access tokens are scoped at the application level as opposed to a specific user. This means that I only need one token in order to access the information of every user in the directory. To get that token, we’ll need to collect some credentials from our directory application.

In the AAD tab of the Windows Azure Management Portal, select your directory. Copy your tenant domain name from the “Domains” tab and make a record of it. Under the “Application” tab, click on the application you set up for Mobile Services authentication, and select “Configure.” By default, tenant applications are SSO only, so we need to make sure that the application has permission to use the graph. Click “Manage Access” at the bottom of the screen, and follow the wizard to configure the app for read access at least.

Manage Access

Next, make note of the Client ID, and generate a new secret under “Keys.” Be sure that you save this value in a secure place; once you leave the page, there’s no way to get this value out of the portal again.

AAD Credentials

At this point you should have three values. Since we’ll be referencing them a lot, go ahead and store them in some variables at the top of the API script.

We can now write a function to obtain the access token for us. The following code hits the token endpoint for our domain with a POST containing the request and the credentials that we just obtained. The response has some metadata about the token, such as its expiration details, but for now we’ll just extract the token.

With the access token in hand, we can finally make calls to the AAD graph. For my app, all I care about is getting basic user info, but the API can do a lot more, such as looking up to whom a given user reports. In all cases, you just need to form the appropriate URL and shove the access token in the request header.

You might be wondering about that mysterious “objectId” field. This is how AAD identifies different kinds of objects (such as users) in the directory. Note that this is not the same as the user ID that is provided by the Mobile Services user object. We’ll get that by taking the user object passed to the custom API’s GET action and calling its getIdentities() function.

I return the whole set of user information that I get back, leaving the client to decide what it does and doesn’t need. Speaking of…

Application Personalization

Our API has everything it needs for getting information about the logged in user, so the next step is to access it from the client. Today I’m working with Windows Phone 8, but of course the same principles apply to the other clients. I’ll be modifying the authentication quickstart with AAD to show the user’s display name upon login.

This actually ends up being very straightforward. I first create a “UserDetails” class to help handle deserializing relevant data from the call. I then modify Authenticate() such that after a user logs in, I call InvokeApiAsync() with the parameter “getIdentities,” as this is what I named my API earlier. Once the task completes, I pull information out of the returned UserDetails and show it in a MessageBox.

Now let’s try it all out. I start the app, punch in my credentials, and…

AAD Graph

Closing Remarks

That’s it! Hopefully this helps make the AAD graph seem less daunting. There is a lot of power there, and you can quickly tune your mobile apps to leverage your organization’s structure, or to just make a nicer experience for your users.

You probably noticed that the API requests the access token every time it is called, and I mentioned at the start that the token is shared by all users. Best practice is certainly to cache the token in your database, making a new request only when the old token expires. For simplicity of the walkthrough I have omitted this step and leave it as an exercise for the reader.

The completed server code for the walkthrough can be found here. Once again, if you are interested in enrolling in the private preview for AAD integration, let us know at


The AAD Graph REST API Reference – Reference material for the different operations you can perform on the AAD Graph
AAD Graph Samples – Samples for .NET, Java, and PHP
AAD Directory Sync – How to set up AAD for sync with on-premises Active Directory
Getting User Information on Azure Mobile Services – Carlos Figueira’s blog post on accessing graphs for other identity providers
Azure Mobile Services – Documentation for Azure Mobile Services
Changes to getIdentities() – We recently changed the getIdentities() function, and the details are discussed here