Using Roles in Azure Applications

I was spending some time today (finally) looking at how to get what I really consider the baseline functionality of claims – apps, users and roles – all working together with one of my Azure AD apps.  Azure has been pushing out pieces of an RBAC-based infrastructure for a few months now, and I wanted to see about integrating my old friend Roles into my app.  Alex Simmons posted a great overview and introduction to the concept here:  http://blogs.technet.com/b/ad/archive/2014/12/18/azure-active-directory-now-with-group-claims-and-application-roles.aspx.  As I began rolling out some code and testing some different scenarios, I wanted to capture a few notes about this process for those of you heading down this path as well:

  • It’s important to distinguish and understand that you can use two different types of “roles” – the Azure AD groups you belong to, as well as custom application roles you create for your application.  Technically you can also mix and match them, by adding AD groups to an application role, but that’s a little outside the scope of where I want to take this.
  • One of the big differences in using Azure AD groups instead of an application role is that your application has to also get consent for rights to Read the Directory.
  • Dushyant Gill put together a really excellent blog post on adding application roles to your Azure AD app here:  http://www.dushyantgill.com/blog/2014/12/10/roles-based-access-control-in-cloud-applications-using-azure-ad/.  You really should take a look at that before you start building this yourself.
  • One thing that is NOT obvious at all – if you only add one role, then you won’t get a role picker when you assign users to the role in your app.  Instead when you click on the Assign User link it will just “do it” without any other dialog.  The behavior is a little odd because you’re not really sure what happened when you first do it.  If you create more than one app role then you do get the picker to select which role.
  • You can only assign a person to one role unless you have Azure AD Premium.
  • You really MUST make the change to your Startup.Auth.cs file to configure what claim type should be considered the “Role” claim type.  If you don’t do this, none of the standard role checks work because the claim value is not contained in a standard role type – the type it uses is either “groups” (if using Azure AD groups) or “roles” (if using app roles).  The exact syntax for this change is at the end of Dushyant’s blog mentioned above, in the TokenValidationParameters code snippet (specifically the RoleClaimType attribute).
  • Once you have this all integrated you can use all my favorite role checking and demand options, like:
    • [PrincipalPermission(SecurityAction.Demand, Role = “yourRoleName”)]
    • [Authorize(Roles = “yourRoleName”)]
    • if (ClaimsPrincipal.Current.IsInRole(“yourRoleName”)) { //do something }

It’s good stuff, try it out!  :-)

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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