Role-based authorisation with Windows Azure Active Directory

Using Window Azure Active Directory (WaaD) to provide authentication for web applications hosted anywhere is dead simple. Indeed in Visual Studio 2013 it is a couple of steps in the project creation wizard.

This provides means of authentication but not authorisation, so what does it take to support authorisation is the [Authorise(Role=xxx)] approach?

Conceptually, what’s needed is means to convert information from claims to role information about the logged-on user.

WaaD supports creating Groups and assigning users to them, which is what’s needed to drive role-based authorisation, the problem is that, somewhat surprising perhaps, group membership is not reflected in the claim-set delivered to the application as part of the ws-federation authentication.

Fortunately, getting around this is very straight forward. Microsoft actually published a good example here but I found it a little bit confusing and wanted to simplify the steps somewhat to explain the process more clearly, hopefully I’ve succeeded –

The process involves extracting the claims principal from the request and, from the provided claims,  find the WaaD tenant.

With that and with prior knowledge of the clientId and key for the tenant (exchanged out of band and kept securely, of course) the WaaD GraphAPI can be used to query the group membership of the user

Finally – the groups can be used to add role claims to the claim-set, which WIF would automatically populate as roles allowing the program to use IsInRole and the [Authorise] attribute as it would normally.

So – how is all of this done? –

The key is to add a ClaimsAuthenticationManager, which will get invoked when an authentication response is detected, and in it perform the steps described.

A slightly simplified (as opposed to better!) version of the sample code is as follows 

 public override ClaimsPrincipal Authenticate(string resourceName, ClaimsPrincipal incomingPrincipal)
            //only act if a principal exists and is authenticated
            if (incomingPrincipal != null && incomingPrincipal.Identity.IsAuthenticated == true)
                //get the Windows Azure Active Directory tenantId
                string tenantId = incomingPrincipal.FindFirst("").Value;

                // Use the DirectoryDataServiceAuthorizationHelper graph helper API
                // to get a token to access the Windows Azure AD Graph
                string clientId = ConfigurationManager.AppSettings["ida:ClientID"];
                string password = ConfigurationManager.AppSettings["ida:Password"];

                //get a JWT authorisation token for the application from the directory 
                AADJWTToken token = DirectoryDataServiceAuthorizationHelper.GetAuthorizationToken(tenantId, clientId, password);

                // initialize a graphService instance. Use the JWT token acquired in the previous step.
                DirectoryDataService graphService = new DirectoryDataService(tenantId, token);

                // get the user's ObjectId
                String currentUserObjectId = incomingPrincipal.FindFirst("").Value;

                // Get the User object by querying Windows Azure AD Graph
                User currentUser = graphService.directoryObjects.OfType<User>().Where(it => (it.objectId == currentUserObjectId)).SingleOrDefault();

                // load the memberOf property of the current user
                graphService.LoadProperty(currentUser, "memberOf");
                //read the values of the memberOf property
                List<Group> currentRoles = currentUser.memberOf.OfType<Group>().ToList();

                //take each group the user is a member of and add it as a role
                foreach (Group role in currentRoles)
                    ((ClaimsIdentity)incomingPrincipal.Identity).AddClaim(new Claim(ClaimTypes.Role, role.displayName, ClaimValueTypes.String, "SampleApplication"));
            return base.Authenticate(resourceName, incomingPrincipal);

You can follow the comments to pick up the actions in the code; in broad terms the identity and the tenant id are extracted from the token, the clientid and key are read from the web.config (VS 2013 puts them there automatically, which is very handy!), an authorisation token is retrieved to support calls to the graph API and the graph service is then used to query the user and its group membership from WaaD before converting, in this case, all groups to role claims.

To use the graph API I used the Graph API helper source code as pointed out here. in Visual Studio 2013 I updated the references to Microsoft.Data.Services.Client and Microsoft.Data.OData to

Finally, to plug in my ClaimsAuthenticationManager to the WIF pipeline I added this bit of configuration –

type="WebApplication5.GraphClaimsAuthenticationManager,WebApplication5" />

With this done the ClaimsAuthenticationManager kicks in after the authentication and injects the role claims, WIF’s default behaviour then does its magic and in my controller I can use, for example –

        public ActionResult About()
            ViewBag.Message = "Your application description page.";

            return View();

Cross posted on the Solidsoft blog

About Yossi Dahan
I work as a cloud solutions architect in the Azure team at Microsoft UK. I spend my days working with customers helping be successful in the cloud with Microsoft Azure.

6 Responses to Role-based authorisation with Windows Azure Active Directory

  1. Pingback: Friday, November 29, 2013 on #WindowsAzure | Alexandre Brisebois

  2. Akinzekeel says:

    Thanks for sharing, but where can I find the client ID and password for my Azure AD?

    • Yossi Dahan says:

      It is part of the application definition in WaaD although it is not possible to retrieve the password for an existing key after its creation.

      You could go to the configure tab of your application in WaaD and add a new key. upon saving the configuration the generated password will appear and you would be able to copy it but once closed you will never be able to read this password again.

  3. Thibaut says:

    Hi, I got a “{“The context is not currently tracking the entity.”}” exception while trying to load the graphService.LoadProperty(currentUser, “memberOf”), am I missing something?


    • Thibaut says:

      Interesting fact:
      It works when I load the user like you do:
      User user = graphInteractionUtility.GraphService.directoryObjects.OfType().Where(it => (it.objectId == userPrincipalName)).SingleOrDefault();

      It doesn’t when I load the user via a query option like that:
      string queryOptions = “userPrincipalName eq ‘” + userPrincipalName + “‘”;
      var users = graphInteractionUtility.GraphService.users.AddQueryOption(“$filter”, queryOptions);
      var response = users.Execute() as QueryOperationResponse;

      if (response != null)
      return response.FirstOrDefault();

      Anyway thanks for the good article🙂

  4. Marcel says:

    Interesting article. Do you know why we can’t determine the claimset issued by WAAD? Now each service in a call-chain will have to talk to the Graph API to get the roles. Having a claims issuance language like ADFS is certainly more efficient, not?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: