Configure app permissions in Azure AD
Background
I have a Web API registered with Azure AD and secured with WindowsAzureActiveDirectoryBearerAuthentication (OAuth2 Token Token). This is a B2B scenario where there are no interactive users - the applications that call the API are background applications like daemons. This way I don't need any experience of consent - I just want trusted apps to be able to call the API, and other apps - even if they present a valid OAuth token - should be stripped.
What i tried
This example seemed to accurately describe my scenario. However, a method of determining whether a caller is a trusted application or not is by comparing the client identifier presented at the request of the caller to a hard-coded value. Obviously, you could store a list of trusted client IDs externally instead of hardcoding, but it seems to me that I can accomplish this through the configuration in the AAD portal so that: a) I don't have to maintain a list of client IDs, and b) I don't need to write my own own authorization logic.
It looks like I would have to define a permission for my API, grant that permission to every calling application in AAD (or one-time admin consent), and then in my API just check for that permission in the formula scp
.
From looking at the portal, it looks like this is exactly the application permission intended:
I can create permission just fine through the app manifest. Unfortunately, I can't figure out how to indicate that this is an application permission and not a delegated permission! I tried changing type
from User to Admin as described on MSDN , but that didn't seem to have any effect.
"oauth2Permissions": [
{
...
"type": "Admin",
...
}
Question
Will I fix that app permissions are the best solution for my scenario? If so, how do you set it up? Or, as I fear, is this another feature that is included in the Roadmap, but not currently functional?
source to share
Ben, Application Permissions are declared in the appRoles section of the manifest. Indeed, if you declare an appRole called "trusted" in your resource app manifest (firewall demonstrator), it will appear in the Permissions dropdown. Then, when you assign this application permission to the client application - an access token that the client application will receive using the client's credentials, the OAuth flow will contain a role claim with the value "trusted". Other applications in the tenant will also be able to obtain an access token for your resource application - but they will not have "trusted" roles. See this blog post for more details: http://www.dushyantgill.com/blog/2014/12/10/roles-based-access-control-in-cloud-applications-using-azure-ad/
Finally, the aforementioned way of assigning an app permission to a client app only works when both the resource and the client app are declared in the same directory - if these apps are multi-user and the client will install these apps separately - the global admin from the client directory will have to agree with client application, which will cause the get application permission to be assigned to the client application instance in the client client. (my blog post also covers this)
Hope this helps.
ps: if you get stuck - feel free to ping me on the contact page http://www.dushyantgill.com/blog
source to share