I want to create service two principals using "az ad sp create-for-rbac" and assign custom roles to them using "az role definition create" and "az role assignment create". Then I want to log in as each service principal and create an authentication token that contains these roles I have created. Then I want to make a REST call (using curl) that indirectly calls my azure function via my APIM where the authentication token is in the header. Finally, I want the APIM policy to reject the REST call from the first service principal and accept the REST call from the second service principal (and call the azure function). The APIM policy needs to reject the first REST call on the bases of missing or wrong roles in the JWT and accept the second REST call on the bases if having the required roles in the JWT. Please help me write the APIM the policy and the (powershell or bash az cli) script to do this. I'm not sure what (custom?) roles to assign to my service principal. I think it would use <validate-jwt>. It might use <authentication-managed-identity/>, I'm not sure. I've already done a similar exercise using Azure AD authentication tokens that I get when the user logs into a web site (for example) and that is not what I want. I want to use the RBAC feature of service principals to restrict access to my azure function. Thanks! Siegfried

How to write APIM (Azure API Mgt Svc) Policy to implement RBAC (Role Based Access Control) to restrict access to my Azure Func?

Siegfried Heintze 1,861

I want to create service two principals using "az ad sp create-for-rbac" and assign custom roles to them using "az role definition create" and "az role assignment create".
Then I want to log in as each service principal and create an authentication token that contains these roles I have created.
Then I want to make a REST call (using curl) that indirectly calls my azure function via my APIM where the authentication token is in the header.
Finally, I want the APIM policy to reject the REST call from the first service principal and accept the REST call from the second service principal (and call the azure function). The APIM policy needs to reject the first REST call on the bases of missing or wrong roles in the JWT and accept the second REST call on the bases if having the required roles in the JWT.

Please help me write the APIM the policy and the (powershell or bash az cli) script to do this. I'm not sure what (custom?) roles to assign to my service principal. I think it would use <validate-jwt>. It might use <authentication-managed-identity/>, I'm not sure.

I've already done a similar exercise using Azure AD authentication tokens that I get when the user logs into a web site (for example) and that is not what I want. I want to use the RBAC feature of service principals to restrict access to my azure function.

Thanks!

Siegfried

Ben Gimblett 3,410 Reputation points Microsoft Employee

2024-03-28T09:40:26.2933333+00:00

Hey @Siegfried Heintze hope you are good.... Another great question!

Let me see if I understand - ultimately you want an API (represented by an Az function) which will expose roles for one or more client applications to utilise. The client apps will use their own identities (app to app) they could be daemon apps or their could be a logged in user but either way it's the app identity (service principal) that will have the permissions implied by the roles assignment

A key principle here is that Scopes are for users and Roles are for Apps AND users.

I think my colleague Jelle already has a pretty neat and complete starting point for you, it's not a perfect example, it is using PS1 (not CLI) for the object creation and it's demonstrating users scopes and roles AS WELL AS app roles - but nevertheless I think it's more or less answering your question: https://github.com/jelledruyts/IdentitySamplesV2

Can you have a read through this and let me know; the "payment processor daemon" - which is given the "Expenses.ReadWrite.All" role exposed by the Expenses API - is the bit to focus on , as this is an "app role" (not a user-role) scenario.

If this sample is demonstrating what you need I'd be happy to help you explore how to move the PS1 to CLI and extending it.

APIM is almost incidental here because (if I understand from your question) it's a façade to your API and simply pre-validating the role claims in the token - in other-words it is performing the same checks the function will do anyway if the call reaches it.
Ben Gimblett 3,410 Reputation points Microsoft Employee

2024-03-28T09:45:07.15+00:00

If I'm misunderstanding any points in the question please could you add further comments to correct :)
Siegfried Heintze 1,861 Reputation points

2024-03-28T14:16:13.1033333+00:00

This sample looks very interesting. Thank you.

Please correct me if I am wrong, but I cannot find any references to APIMs (azure API management services) in your example (and more specifically I cannot find any APIM policies). Please help me understand how to write the APIM policies to reject REST calls with missing or wrong RBAC roles in their JWT headers.
Ben Gimblett 3,410 Reputation points Microsoft Employee

2024-03-28T14:37:32.91+00:00
The hard part is setting up the apps and permissions etc.

APIM is the easy part - there's a few examples , this is one https://techcommunity.microsoft.com/t5/azure-paas-blog/restricting-api-management-access-to-users-through-aad/ba-p/2116259

App and user roles should both be represented in the "roles" claim

The syntax for validate-jwt is

<required-claims> <claim name="roles" match="any"> <value>MyRole</value> </claim> </required-claims>
Ben Gimblett 3,410 Reputation points Microsoft Employee

2024-03-28T14:40:36.2333333+00:00

Here's the ref for role claims in an AAD Access token https://learn.microsoft.com/en-us/entra/identity-platform/access-token-claims-reference#payload-claims
Siegfried Heintze 1,861 Reputation points

2024-03-29T16:04:59.9266667+00:00

Thanks for another prompt response!

(5) Regarding https://techcommunity.microsoft.com/t5/azure-paas-blog/restricting-api-management-access-to-users-through-aad/ba-p/2116259: It says

If you use the OpenID config URI property in the policy and set it to your AAD tenant's OpenID Connect metadata document endpoint, the token would be validated for anyone in your tenant.

Since I'm trying to accommodate the scenario where there might be no authenticated humans (such as an app service web app or timer triggered azure function or github workflow or devops pipeline), is this link applicable? I'm think it is not applicable but I could be wrong.

(6) Will this command give me the authentication token I need to make the REST call? $token=$(az account get-access-token --tenant <tenantid> --query accessToken --output tsv)

(7) I'm looking at the results of "az role definition list --query "[].{name:name, roleType:roleType, roleName:roleName, description:description}" --output tsv" and it looks like I can only choose from

API Management Developer Portal Content Editor

API Management Service Contributor

API Management Service Operator Role

API Management Service Reader Role

API Management Service Workspace API Developer

API Management Service Workspace API Product Manager

API Management Workspace API Developer

API Management Workspace API Product Manager

API Management Workspace Contributor

API Management Workspace Reader

Which one(s) do you recommend? Since my goal is to reject REST calls from service principals that don't have the specified role assigned for the scope of my APIM, I'm guessing any one would do.

(8) I believe I must choose from the above list because it must match the scope when I specify the scope as the APIM. Correct? And I do want to specify the scope as the APIM when I execute "az role assignment create". Correct?

(9) Can validate-jwt handle my scenario of no humans begin authenticated by Azure AD?

(10) I'm looking at your second link (https://learn.microsoft.com/en-us/entra/identity-platform/access-token-claims-reference#payload-claims) and wondering about the "roles" field. Is this the field used by the <claim name="roles">?
Ben Gimblett 3,410 Reputation points Microsoft Employee

2024-04-02T08:47:44.4333333+00:00

(5) The metadata endpoint, content is per tenant, is where you can find the public signing keys (amongst other things) so if you are declaratively pointing to a given tenant it makes sense for the implementation to accept only tokens from that tenant

The validate-jwt implementation does not require you provide this explicitly because the endpoint can be inferred. It would be required if this was not the case (for example validate JWT can be used with other IDP)

(6)Yes if you logged in as a service principal "az login --service-principal ..."
You would almost always require a "--resource" argument when obtaining the token , this would most likely be the app id of the app registration representing the backend. if you were using the same method to generate an access token from a service principal toward an Az service the resource id would be the app id (guid) for that service

(7) those are built-in roles of API Management (they are control plane roles for interacting with the API management resource directly - for example you would require that for a devops service principal or a operations user)
My understanding from the original question above; your actual backend API that APIM facades would expose a role - as per Jelle's sample - and this is what you would be validating

(8) linked to (7) again I dont think so based on your intent , from the original question, which was: Client app acquires an access token with the audience for actual backend API and permissions / role claims for the things it wants to achieve using the backend API

(9) Yes, an access token can be represent the claims for an app or a user

(10) yes related to my comment for (8) this is where the role claims that the client makes will be . these represent the actions (or work) the client is requesting from the backend API
Siegfried Heintze (ARTECH CONSULTING LLC) 0 Reputation points Microsoft Vendor

2024-04-05T18:36:54.1+00:00

Ben: I wanted you to know that I've been working on this every day. I've been experiencing some issues specific to our Azure AD tenant's policies and I might have a work around. I'll let you know if have some more questions. Siegfried