3

Background

I have a Web API registered in Azure AD and secured using WindowsAzureActiveDirectoryBearerAuthentication (OAuth2 bearer token). This is a B2B-type scenario where there are no interactive users - the applications calling the API are daemon-like background apps. As such, I don't need any consent experience - I just want trusted applications to be able to call the API, and other applications - even if they present a valid OAuth token - to be denied.

What I've tried

This sample seemed to describe my scenario almost exactly. However, the way it determines if a caller is a trusted app or not is by comparing the clientID presented via a claim by the caller to a hard-coded value. Obviously you could store the list of trusted clientIDs externally instead of hardcoding, but it seems like I should be able to accomplish this via configuration in the AAD portal so that a) I don't have to maintain a list of clientIDs, and b) I don't have to write my own authorization logic.

It seems like I should be able to define a permission for my API, grant that permission to each calling app in AAD (or a one-time admin consent), and then in my API just check for the presence of that permission in the scp claim.

From looking at the portal it seems like this is what Application Permissions are intended for: permissions

I can create a permission just fine via the application manifest. Unfortunately, I can't figure out how to specify that it's an Application Permission, not a Delegated Permission! I tried changing the type from User to Admin as described on MSDN, but that seemed to have no effect.

"oauth2Permissions": [
{
  ...
  "type": "Admin",
  ...
}

Question

Am I correct that Application Permissions are the best solution for my scenario? If so, how do I configure it? Or, as I fear, is this yet another feature that is On The Roadmap™ but not currently functional?

BenV
  • 12,052
  • 13
  • 64
  • 92

1 Answers1

4

Ben, Application Permissions are declared in the appRoles section of the manifest. Indeed, if you declare an appRole called say 'trusted' in your resource application's (storage broker demo) manifest - it will show up in the Application Permissions drop down there. Then, when you assign that Application Permission to the client app - the access token that the client app will receive using the client credentials OAuth flow will contain a roles claim with value 'trusted'. Other apps in the tenant will also be able to get an access token for your resource app - but they wont have the 'trusted' roles claim. See this blog post for details: http://www.dushyantgill.com/blog/2014/12/10/roles-based-access-control-in-cloud-applications-using-azure-ad/

Finally, the above way to assign an application permission to a client app only works when both the resource and client application are declared in the same directory - if however these apps are multi-tenant and a customer will install these apps separately - a global admin from customer's directory will need to consent to the client app - which will result in the application permission getting assigned to the instance of client app in the customer's tenant. (my blog post covers this too)

Hope this helps.

ps: if you're stuck - feel free to ping me on the contact page of http://www.dushyantgill.com/blog

Dushyant Gill
  • 3,966
  • 18
  • 14
  • Thanks for the speedy reply. I think this is exactly what I was looking for. I'll give it a shot tomorrow. – BenV Jan 09 '15 at 04:42
  • So does defining an `oauth2Permission` with `Type: Admin` mean it's still a delegated permission, but is consented to once by an admin instead of by each user? – BenV Jan 09 '15 at 04:43
  • 3
    How exactly does the admin consent in this case? I'm trying to see where as an admin I can click the 'consent' button. Any pointers would be appreicated. – The Senator Mar 31 '16 at 10:18
  • @TheSenator did you ever figure out how the admin consents? Thanks :-) – Joon Mar 13 '17 at 13:53
  • @Joon I totally gave up on this, I think that perhaps there was a technology gap or a brain gap at the time I was looking. For now I've dropped it in favour of a local auth service. But other services to look at include auth0 who seem to be quite good - if a little pricey. – The Senator Mar 14 '17 at 10:31
  • @TheSenator haha I feel your pain :-) I had a look in the new Azure portal and when you are a directory admin user there is a "Grant Permissios" button on the Required permissions blade of the app registration. I clicked that and the permissions worked. – Joon Mar 15 '17 at 08:17
  • @Joon good work! I'll take a look at that once I stop fighting with other changes in the latest and greatest of the coding world :) thanks for taking the time to tell me! – The Senator Mar 15 '17 at 08:40