Add basic RBAC functionality to Windows Azure Mobile services

Last November, we released the Azure Active Directory (AAD) preview as a mobile service identity provider. This is designed to provide enterprise developers with Easy-to-use solutions to build mobile applications for employees. As a starting point, using Basic authentication is a good choice. In many cases, however, current preview customers need to differentiate between different types of users in order to make appropriate authorization decisions. The idea of role-based access control (RBAC) is to assign permissions to the roles that a user can play, thus defining the boundaries appropriately to limit what a class of users can and cannot do. Fortunately, adding basic RBAC functionality to Azure Mobile services is simple. This article will show you how to achieve this.

Let's say I want to develop an application that is available only to the sales team. To access the application, the user must not only be a member of the company directory, but also be assigned to a sales group. Let's see, to make sure that only authenticated sales team members can access the application, what logic needs to be added to the server side. (If you've just started using Azure Active Directory authentication with mobile services, you'll find this introductory tutorial helpful.) ）

The basic approach we will take is to take advantage of the security group memberships of the users in the Azure AD tenant. AAD also has the concept of roles and groups, but in today's scenario we are using an existing group that already has the correct user membership. We will manage this group through an in-house ad tenant that is synchronized with the Azure AD tenant. Customers using O365 and Windows Intune have confirmed that by setting up and deploying a synchronization of the Active directory directory, you will have powerful features (you can even use these tenants to build mobile services).

Today, I'm going to use the Password Sync option, but there are a number of scenarios that actually support it. In fact, you can set AAD to point to ADFS to support large hybrid scenarios. To try these options, you can start the Azure VM running Windows Server R2 Datacenter and install the Active directory Domain Services role, and then follow the directory synchronization instructions.

Creating groups

As you can see, I've created some users (Alice, Bob, Carol, and Dave) and a "Sales" domain security group in my own directory. Alice and Bob are already members of the group, but Carol and Dave have not joined the group, so they should not have permission to access my application. Everything else is the default value.

Connect to Azure Mobile service

Now I'm ready to start building my application backend. In Azure mobile services, we want to protect each script and API with additional authorization logic on top of the provided mechanism. To further enhance security, I set the permissions for each protected endpoint to "only authenticated Users."

I want the logic built to be executed in multiple scripts, so I put the code in the shared script section of the Git repository for mobile services. I named the script Rbac.js.

To determine group membership, the first step is to gain access to the AAD graph API. This blog post and this sample describes how to do this. You can start with the following code snippet:

After we get the graph access token, we need to call the Ismemberof graph endpoint. This action checks whether the specified user is a member of a given group, including transitive memberships. We can get the user ID from the script we're checking-all table scripts explicitly receive the user object, and you can get a user object from the custom API by accessing Request.user. In addition, we need to obtain a group ID that can be easily obtained in the admin portal. You can go to an Azure AD tenant, open the Group tab and select a group, and then copy the OBJECT ID from the CONFIGURE tab.

For ease of use, we use a friendly name to export the value from a shared script.

Next, we'll write a function to wrap the call to the AAD ismemberof endpoint. As mentioned earlier, we need the user ID (UserID) and group ID (GroupID) that we just obtained. The request also needs to include the access token previously obtained.

Next, we're going to simplify the programming model a little bit, and only need to move the user object of the service (through it to get ObjectID) and the group ID. It is then packaged correctly to obtain the graph token and invoke it. Note that in practical applications, you have the option of caching the token without having to extract it every time. The token contains an expiration value that allows you to determine when a new token should be fetched.

This is what you need to do with shared scripts. Next, for each script to be protected with RBAC, I just add a few lines of code and then execute the script in the callback. The following is an example of a table read operation:

Summary

It's done. We have successfully restricted only some of the employees in need to use the application. Now you can start building a variety of RBAC schemes. If you need to differentiate some users ' client UI from other users, a simple implementation is to advertise the membership check as a custom API that you can perform immediately after the user logs on.

Azure Active Directory is leveraging group support for some great features, and many can be done directly in the admin portal. AAD advanced users should have an in-depth understanding of the new Self-Service group management support.

If you are interested in enterprise mobile application development, it is recommended that you take a look at the new mobile services. NET back-end preview. The preview is not currently built with AAD support, but don't worry, we will soon provide this support.