{"id":249,"date":"2013-01-22T08:34:00","date_gmt":"2013-01-22T17:34:00","guid":{"rendered":"http:\/\/www.cloudidentity.com\/blog\/2013\/01\/22\/group-role-claims-use-the-graph-api-to-get-back-isinrole-and-authorize-in-windows-azure-ad-apps-4\/"},"modified":"2013-03-14T19:58:49","modified_gmt":"2013-03-15T04:58:49","slug":"group-amp-role-claims-use-the-graph-api-to-get-back-isinrole-and-authorize-in-windows-azure-ad-apps","status":"publish","type":"post","link":"https:\/\/www.cloudidentity.com\/blog\/2013\/01\/22\/group-amp-role-claims-use-the-graph-api-to-get-back-isinrole-and-authorize-in-windows-azure-ad-apps\/","title":{"rendered":"Group & Role Claims: Use the Graph API to Get Back IsInRole() and [Authorize] in Windows Azure AD Apps"},"content":{"rendered":"

Welcome to a new installment of the \u201caddressing the most common questions about Windows Azure AD development\u201d series! This time I am going to tackle one question that I know is very pressing for many of you guys:<\/p>\n

How do I get role and group membership claims for users signing in via Windows Azure AD?<\/em>  <\/p>\n

Right now the tokens issued by Windows Azure AD in Web sign-on flows do not contain groups or role claims. In this post I will show you how to leverage the Graph API and the WIF extensibility model to work around the limitation; I will also take advantage of this opportunity to go a bit deeper in the use of the Graph API, which means that the post will be longer (and at times more abstract) than a simple code walkthrough. As usual, those are my personal musings and my own opinions. I am writing this on a Saturday night (morning?) hence I plan to have fun with this \ud83d\ude42 For the ones among you who are in a hurry or have low tolerance for logorrhea, please feel free to head to the product documentation on MSDN. <\/p>\n

Bird\u2019s Eye View of the Solution<\/h1>\n

Most pre-claims authorization constructs in ASP.NET are based on the idea of roles baked in IPrincipal: namely, I am thinking of the <authorization> config element, the [Authorize] attribute and of course the IsInRole() method. There\u2019s an enormous amount of existing code based on those primitives, and abundant literature using those as the backbone of authorization enforcement in .NET applications.
This state of affair was well known to the designer of the original WIF 1.0, who provided mechanisms for projecting claims with the appropriate semantic (and specifically http:\/\/schemas.microsoft.com\/ws\/2008\/06\/identity\/claims\/role<\/a>) as roles in IPrincipal. We even have a mechanism<\/a> which allows you to specify in config a different, arbitrary claim type  to be interpreted as role, should your STS use a different claim type to express roles.<\/p>\n

As mentioned in the opening, right now Windows Azure AD does not send anything that can be interpreted as a role claim. The good news, however, is that Windows Azure AD offers the Graph API, a complete API for querying the directory and retrieve any information stored there, for any user; that includes the signed-in user, of course, and the roles he\/she belongs to. If you need to know what roles your user is in, all you need to do (over-simplifying a bit, for now) is to perform a GET on a resource of the form https:\/\/graph.windows.net\/yourtenant.onmicrosoft.com\/Users(‘guido@yourtenantname.onmicrosoft.com’)\/MemberOf<\/a>. That is pretty sweet, and in fact is just a ridiculously tiny sliver of all the great things you can do with the Graph API; however, if you\u2019d do this from your application code that would not help you to leverage the user\u2019s role information from <authorization> and the like. When you are in your application\u2019s code is kind of too late, as the ClaimsPrincipal representing the caller has already been assembled and that\u2019s where the info should be for those lower-level mechanisms to kick in. True, you could do something to the ClaimsPrincipal retroactively, but that\u2019s kind of brittle and messy.<\/p>\n

There is another solution here, which can save both goat and cabbage (can you really say this in English?:-)). The WIF processing pipeline offers plenty of opportunities for you to insert custom logic for influencing how the token validation and ClaimsPrincipal creation takes place: details in Chapter 3 of Programming WIF<\/a>. Namely, there is one processing stage that is dedicated to incoming claims processing. Say that you have logic for filtering incoming claims, modifying them or extending the claims set you are getting from the STS with data from other sources. All you need to do is to derive from the ClaimsAuthenticationManager class, override the Authenticate method and add a reference to your custom class in the application\u2019s config.
So, the solution I propose is simple: we can create a custom ClaimsAuthenticationManager that at sign-in time reaches back to the Graph, retrieves the roles information, creates roles claims accordingly and adds them to the ClaimsPrincipal. Everything else downstream from that will be able to see the roles information just like if they would have been originally issued by the STS.<\/p>\n

\"image\"<\/a> <\/p>\n

The code of custom ClaimsAuthenticationManager is going to be pretty simple, also thanks to the use of AAL for obtaining the necessary access token: just a tad more than 30 lines, and most of it string manipulation. In my experience, the thing that people often find tricky is the work that is necessary for enabling your Web application to invoke the Graph; furthermore, even if AAL reduces to a mere 3 the lines of code necessary for obtaining an access token, the structure of the parameters you need to pass is not always immediately clear to everybody. Here I\u2019ll do my best to explain both: they are not especially hard and I am confident you\u2019ll grok it right away. That said, I do hope we\u2019ll manage to automate A LOT of this so that in the future you won\u2019t be exposed to this complexity unless you want to change the defaults. We kind of already do this for the Web SSO part, if you use the MVC tool<\/a> you can get a functioning MVC4 app which uses Windows Azure AD for Web SSO in no time. In fact, in this post I\u2019ll use such an app as starting point.<\/p>\n

Ready? Let\u2019s dive.<\/p>\n

Prepping the GraphClaimsAuthenticationManager Wireframe<\/h1>\n

Let\u2019s get this immediately out of the way; also, it will provide structure for the rest of the work.<\/p>\n

As mentioned, I assume you already have an MVC4 app that you configured with the MVC tool to integrate with your Windows Azure AD tenant for sign-in. If you didn\u2019t do it yet, please head to this page<\/a> now and follow the instructions for configuring your application. You can skip the publication to Windows Azure Web Sites, for this post we\u2019ll be able to do everything on the local box. If you want to see the tool in action, check out this BUILD talk<\/a>.
Create a new class library (though you could just add a class to your web project) and call it something meaningful: I called mine GraphClaimsAuthenticationManager<\/strong>.
Add a reference to System.IdentityModel, rename the class1.cs file to GraphClaimsAuthenticationManager.cs, then change the code as follows:<\/p>\n

\n
   1:  <\/span>public<\/span> class<\/span> GraphClaimsAuthenticationManager : ClaimsAuthenticationManager<\/pre>\n
   2:  <\/span>{<\/pre>\n
   3:  <\/span>   public<\/span> override<\/span> ClaimsPrincipal <\/pre>\n
            Authenticate(string<\/span> resourceName, ClaimsPrincipal incomingPrincipal)<\/pre>\n
   4:  <\/span>   {<\/pre>\n
   5:  <\/span>      if<\/span> (incomingPrincipal != null<\/span> && <\/pre>\n
                 incomingPrincipal.Identity.IsAuthenticated == true<\/span>)<\/pre>\n
   6:  <\/span>      {                              <\/pre>\n
   7:  <\/span>          \/\/ get a token for calling the Graph<\/span><\/pre>\n
   8:  <\/span>                      <\/pre>\n
   9:  <\/span>          \/\/ query the Graph for the current user's memberships<\/span><\/pre>\n
  10:  <\/span>             <\/pre>\n
  11:  <\/span>          \/\/ add a role claim for every membership found<\/span><\/pre>\n
  12:  <\/span> <\/pre>\n
  13:  <\/span>       }<\/pre>\n
  14:  <\/span>       return<\/span> incomingPrincipal;<\/pre>\n
  15:  <\/span>   }        <\/pre>\n
  16:  <\/span>}<\/pre>\n<\/div>\n
This is pretty much the default ClaimsAuthenticationManager implementation: it passes through all the incoming claims to the next stage undisturbed. Our job will be to fill in the method\u2019s body following the comment placeholders I wrote there. You can make your application pick up and execute your class by adding a reference to the class library project and inseriting the proper config element to the web.config, as shown below (sci-fi formatting, you would not break strings IRL).<\/p>\n
 <<\/span>system.identityModel<\/span>><\/span>\n    <<\/span>identityConfiguration<\/span>><\/span>\n      <<\/span>claimsAuthenticationManager<\/span> 
        type<\/span>="GraphClaimsAuthenticationManager.GraphClaimsAuthenticationManager, 
              GraphClaimsAuthenticationManager"<\/span> \/><\/span><\/pre>\n
I\u2019d suggest hitting F5 and see if everything still works, often something silly like misspelled namespaces in the type attribute will create stumble points and you want to catch that before there will be more moving parts later on.<\/p>\n
Enabling An MVC App to Invoke the Graph API<\/h1>\n
Alrighty, now for the first interesting part.<\/p>\n
The next thing we need to do is enabling your MVC application to call back into the Graph and inquiry about the user\u2019s roles. But in order to do that, we first need to understand how our MVC application is represented in Windows Azure AD and what do we need to change.<\/p>\n
When you run the MVC tool<\/a> for enabling Windows Azure authentication you are basically getting lots of the steps I described here<\/a> done for you. As a quick recap, the tool<\/p>\n