0
votes

Like demonstrated here, I want to secure an Azure Function app with AzureAD and only be able to call/invoke it from an Azure API Management instance (with system-assigned managed identity enabled). This works fine. However I really want to isolate access to the API (Functions app). As it stands now, ANY app in my tenant would be able to successfully authenticate and invoke the API. Therefore, I chose to enable user-assignment for that app registration.

So basically, there is 1 API (Azure Functions) that is AzureAD protected. Then there is 1 service calling the API (Azure API Management). Without a role-assignment there is the following error message I can understand.

AADSTS501051: Application '<appId>'(<name of APIM managed-identity>) is not assigned to a role for the application '<appId2>'(<name of app registration for the Azure Functions app's EasyAuth feature>).

So I created an app role in the API's app registration. The normal guidance on how to assign such a role to an application can be found here (EDIT: WRONG LINK SEE ANSWER). However this does only apply to the service principal manually created (read: not a MSI) because this requires the service principal can be found in the portal UI. This is not the case with anything related to a mangaged-identity.

Since the above link also states that assignment can also be done using the Graph API I tried this as a workaround.

POST https://graph.microsoft.com/v1.0/users/{id}/appRoleAssignments
Content-Type: application/json

{
  "principalId": "principalId-value",
  "resourceId": "resourceId-value",
  "appRoleId": "appRoleId-value"
}

This does not work yielding the following error response (I have tried appId and objectId for id/principalId/resourceId):

"Resource '<guid of principalId>' does not exist or one of its queried reference-property objects are not present."

Do you have any suggestions on what could be done? Any help is greatly appreciated.

1
Reading this answer, the correct way to dit is to use objectIds (which I also tried). The guy answering also blogged about this, which is exactly what I want to do.... so the approach appears to be valid, still it's not working in my specific case.baouss

1 Answers

0
votes

The MS-Graph link in the doc was false. It referred to the assignment of a role to a user, though an application in the linking text body was implied. This is the correct reference.

POST /servicePrincipals/{objectId}/appRoleAssignments

Also make sure, that in case you have created the Azure subscription with a personal account (eg. outlook.com, hotmail.com) to not use the bearer token of that user in the graph call. Instead create a user in AzureAD, assign proper permissions, and use that account's token.