Windows Azure Active Directory: Using Group Memberships for Authorization

This is the fifth installation in my series on WAAD. So far, we’ve managed to create a WAAD tenant domain, set up an application to use WAAD for Single-Sign On authentication and read the current user’s group memberships using the Active Directory Graph API. Oh, and let’s not forget fixing a problem where the current user’s name is null. Now that we’re here, let’s complete the picture by converting our group memberships to roles and using those roles for authorization.

Staking a claim

One of the interesting changes in .NET 4.5 that hasn’t received much attention is the fact that under the covers, all authentication providers are now claims-based. Of course, Windows Identity Foundation has been claims-based from the start – the real change is that all the common infrastructure supports claims as well. For ASP.NET MVC development, this means that all we need to do to support roles using the [Authorize(Roles = "RoleName")] attribute syntax is get role claims from somewhere. The bad news is that WAAD authentication only gives us an identity claim. The good news is we can make up our own role claims pretty easily. Our enabler is a class called System.Security.Claims.ClaimsAuthenticationManager:

Defines the base implementation for a claims authentication manager. The claims authentication manager provides a place in the claims processing pipeline for applying processing logic (filtering, validation, extension) to the claims collection in the incoming principal before execution reaches your application code.

Let’s put that to use. Create a new class and call it GroupToRoleClaimAuthenticationManager. Paste in this code:

Then configure the application to use the manager by adding this under system.identityModel/identityConfiguration in Web.config:

<claimsAuthenticationManager type="WAADDemo.GroupToRoleClaimAuthenticationManager, WAADDemo" />

Create groups

Log in to the WAAD administration portal, open up “users & groups” and switch to the “security groups” view:


Create a group called “Administrators” and add your WAAD administrator user to that group. Then, create a new user:


You don’t have to specify any additional details if you don’t want to. Click on “next” and you’ll get a page asking about user roles. Notably, you most likely don’t want to specify any roles here, as the roles are fixed and specific to WAAD:


The next page in the wizard will ask about assigning licenses. This is a feature that is specific to Office 365, so you can skip it and click “next”. Finally, the wizard will ask whether you want the generated password for your new user to be sent to someone via email. Whether you do that or not, the password will be displayed to you on the next page, so note the password down somewhere and complete the wizard.

Restricting access

Now we’ve got groups and our groups have members in them. We also have a bunch of code in our application that converts those memberships into role claims. The last thing we need to do is use that to restrict access within our application. Add a new controller action – for example, in the HomeController of the Internet Application app template:

[Authorize(Roles = "Administrators")]
public ActionResult AdminOnly() {
 return View();

Create a matching view, and run the application. When the application asks for you to log in, do that with the credentials of the user you just created. Since this is the first time you are logging in, instead of immediately directing you back to the application, WAAD will ask you to change the user’s password:


Change the password and log in again with the new password. Navigate to https://localhost:44302/Home/AdminOnly (substituting the port and protocol you’re actually using) and you should be greeted with a 401:


To verify that administrators can see the admin features, log out of your session by closing the browser session, re-launch the browser and log in again – this time, using your admin credentials – and the application will let you through:


You’ll probably also want to hide links to administrative features from users that don’t have the required privileges – that’s easily done with IPrincipal.IsInRole().

Phew! We’ve covered a lot of ground and come pretty far. I hope you found all this useful. As usual, questions and comments are welcome!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.