Azure APIM Validate JWT based on two different claims - azure

I am trying to create a policy in Azure APIM to validate JWT Tokens (Azure AD tokens) based on two different claims.
My API may be consumed by either other applications or users - it may be called from an user context or an application context. As such, the token might contain either the "scp" claim e.g. user_impersonation or "roles" claim like [ "CallApiAsAnApp" ].
From the documentation, I have not found any way to do this. Is this possible or do I have to implement custom code to do this at the API level? Any claims added to "required-claims" in the policy become mandatory. There doesn't seem to be any "match-any" option at the claims level, only values level.

In the end, the only way I could find to fix the issue is to use the choose element instead of validate-jwt, with custom code (which is what I was hoping to avoid any way). Basically I am saving the validated JWT Token to a variable and then using if / elseif to determine if the token is acceptable. Working relevant configuration below
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" require-scheme="Bearer" output-token-variable-name="valid-jwt">
<openid-config url="https://login.microsoftonline.com/tenantid/v2.0/.well-known/openid-configuration" />
<issuers>
<issuer>https://sts.windows.net/tenantid/</issuer>
</issuers>
</validate-jwt>
<choose>
<when condition="#{
var jwt = (Jwt)context.Variables["valid-jwt"];
if(jwt.Claims.ContainsKey("roles")){
var roles = jwt.Claims["roles"];
return !Array.Exists(roles, element => element == "MyRoleName");
} else if (jwt.Claims.ContainsKey("scp")){
var scp = jwt.Claims["scp"];
return !Array.Exists(scp, element => element == "user_impersonation");
} else { return true; }
}">
<return-response>
<set-status code="401" reason="Unauthorized" />
</return-response>
</when>
<otherwise />
</choose>

As you mentioned the token may contain either the scp cllaim or roles claim, it seems your token sometimes generated in "Delegated" type and sometimes generated in "Application" type. You just need to configure the <validate-jwt> policy like below screenshot, add both of the claims in it and choose "Any claim".
After that, the token can be validated if it just contain one claim.
By the way, please check if your tokens in two situations have same "Audiences", otherwise your requirement may not be implemented by the configuration above.

Related

Azure APIM policy with dynamic claims in token validation

I am using APIM to expose multiple endpoints from a range of different Azure Functions as operations in the same API. Different operations in this API might have different audiences (aud) in the token based on which function is behind that particular operation.
What might differ though, is that the authorized party (azp) is not always the same. According to the OIDC documentation, this should then also be verified. In some cases, requests originate from a single page application where the token is issued on behalf of a user that signed in. In other cases, the request originates from someone integrating towards my APIs using a principal instead and a client_credentials grant type.
What I want to achieve is to have as simple a policy as possible, and still allow a range of different azp claims for a single aud claim. This is how I'm currently doing this:
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
<openid-config url="https://login.microsoftonline.com/{{tenantId}}/v2.0/.well-known/openid-configuration" />
<required-claims>
<claim name="aud" match="all">
<value>{{target-api-clientId}}</value>
</claim>
<claim name="azp" match="any">
<value>{{spa-clientId}}</value>
<value>{{integrator-clientId1}}</value>
<value>{{integrator-clientId2}}</value>
</claim>
</required-claims>
</validate-jwt>
However, this doesn't scale very well and forces me to keep duplicate policies between environments and for each new allowed authorized party I must add a new row in the azp claim section as a well as new named values.
The documentation specifies that there is a separator attribute for the claim element, but as far as I can tell, this only splits the claim in the incoming token on that separator character and I always only have a single aud and azp claim in the incoming tokens.
Is there any way for me to achieve a single API baseline policy, where each operation could set its expected required parameters? Something along these lines:
API base policy
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
<openid-config url="https://login.microsoftonline.com/{{tenantId}}/v2.0/.well-known/openid-configuration" />
<required-claims>
<claim name="aud" match="all">
<value>#((string)context.Variables["aud"])</value>
</claim>
<claim name="azp" match="any">
#((List<string>)context.Variables["azp"])
</claim>
</required-claims>
</validate-jwt>
Operation specific policy
<set-variable name="aud" value="{{allowed-aud-for-this-operation}}" />
<set-variable name="azp" value="{{list-of-allowed-authorized-parties-for-this-operation}}" />
<base />
To further clarify what the infrastructure looks like and where requests might originate from, this might shine some light:
Is there any way to achieve dynamic token evaluation like this? If not, what are my other options? Am I approaching this problem the right way, or should I rethink?

Multiple Authentication policies in Azure APIM

I have two scenarios where in first client will call the APIM with bearer token and other one is Function App will call our APIM with Managed identity. I have the code which will validate the jwt. but I want to know how can I skip the other one if either one is available(e.g I want to skip the jwt validation if its get called with managed Identity). From examples I can see I can do a choose and when but not sure what will be the headers for the managed identity. Here is what I am thinking I should be updating.
<choose>
<when condition="#(context.Request.Headers.GetValueOrDefault("Authorization","") != "")">
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Invalid or Expired token" require-expiration-time="true" require-signed-tokens="true">
<openid-config url=".well-known/openid-configuration" />
<audiences>
<audience>audience</audience>
</audiences>
<issuers>
<issuer>issuer</issuer>
</issuers>
</validate-jwt>
</when>
<when condition="to validate managed identity">
<authentication-managed-identity resource="resource" client-id="clientid of user-assigned identity" output-token-variable-name="token-variable" ignore-error="true|false"/>
</when>
</choose>
For this requirement, I think there isn't any difference between the two request(request APIM with bearer token directly and request APIM from function app by managed identity). Both of them will provide a bearer token in header(Authorization) of the request.
You can refer to this document about calling APIM from function app according to managed identity. You can find the lines of code shown as below in the document which are used to get access token and set the token in header when request APIM.
var azureServiceTokenProvider = new AzureServiceTokenProvider(identity);
string accessToken = await azureServiceTokenProvider.GetAccessTokenAsync(target,tenantID);
wc.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);
So the second request scenario is same with the first request scenario. We can not distinguish them in APIM policy before <validate-jwt>. To implement your requirement, I think you can add a property into the header of the two requests and then check the header in APIM policy. For example, in function app code, you can add a header like below:
httpClient.DefaultRequestHeaders.Add("comeFrom", "fromFunApp");
Then check the header in policy:
<choose>
<when condition="#(context.Request.Headers.GetValueOrDefault("comeFrom","") != "fromFunApp" && context.Request.Headers.GetValueOrDefault("Authorization","") != "")">
..............

Azure: How to retrieve issuer-signing-key for validate-jwt policy?

I'm working in Azure, where our Web App calls the APIM with the request, and then the APIM calls the WebApi to fulfill the request.
We're hitting a 500 error when we try to call one of the APIs set up, and when drilling down to the error in the browser (below is "Error message") (Inspect -> Network), it shows the error message coming from a validate-jwt policy set up for the apim (a product-public.policy.xml):
<policies>
<inbound>
<base />
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Error message" require-expiration-time="true" require-scheme="Bearer" require-signed-tokens="true">
<openid-config url="{{validauthorityissuer}}/.well-known/openid-configuration" />
<issuer-signing-keys>
<key>Base64 Encoded Key</key>
</issuer-signing-keys>
<audiences>
<audience>{{WebAppId}}</audience>
</audiences>
<issuers>
<issuer>{{validauthorityissuer}}</issuer>
</issuers>
</validate-jwt>
</inbound>
At first glance it looks like the issuer-signing-key is the problem, as it looks to be just a placeholder string.
To confirm it may be this causing the problem, I did a test in APIM, and got the following message:
{
"code": "401",
"type": "AAD Authorization",
"message": "No token provided to access the resource.",
"developerMessage": "Missing or badly formatted access token",
"moreInfo": null
}
This leads me to believe even more that the problem is the issuer-signing-keys.
My question is, where do I obtain the issuer-signing-key? Haven't been able to find much help online and through documentation.
Second question would be, assuming I get the key, would I have to convert it to base64, then paste it where it currently says "Base64 Encoded Key"?
you can get your issuer-signing-keys from your openID endpoint. I don't believe you have to worry about this. If you provide APIM with open-id endpoint (as you are doing) APIM will do this automatically. AD Samples below confirm this. You should remove the issuer related blocks. I would still experiment/validate.
https://learn.microsoft.com/en-us/azure/api-management/api-management-access-restriction-policies#ValidateJWT

Azure API Management: authorization with Oauth2 401 gives "Unauthorized. Access token is missing or invalid."

I have a few APIs (Logic Apps, Functions) that I want to expose through Azure API Management.
They work fine, so I decided to add OAuth2 autorization.
I followed step by step https://learn.microsoft.com/fr-fr/azure/api-management/api-management-howto-protect-backend-with-aad:
Register an application (backend-app) in Azure AD to represent the API.
Register another application (client-app) in Azure AD to represent a client application that needs to call the API.
In Azure AD, grant permissions to allow the client-app to call the backend-app.
Configure the Developer Console to call the API using OAuth 2.0 user authorization.
Add the validate-jwt policy to validate the OAuth token for every incoming request.
Also use Postman to test
Everything works until the "validate-jwt" policy step.
When I add it, I get a "401 - Unauthorized. Access token is missing or invalid."
I can get the token, in Developer Console and Postman, but as soon as I do the API call... 401!
When I used jwt.ms to check the content of the token, I noticed that the aud param has nothing to do with the backend Application ID.
The value in the token is "00000003-0000-0000-c000-000000000000", whereas the backend app ID is like "16caXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXc0".
I'm running out of ideas and need the help of some Azure gurus out there!
Help would be very much appreciated...
Here below the inbound policy as per the MS doc:
<policies>
<inbound>
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
<openid-config url="https://login.microsoftonline.com/MY_AD_TENANT_ID/.well-known/openid-configuration" />
<required-claims>
<claim name="aud">
<value>MY8BACKEND_APP_ID_GUID</value>
</claim>
</required-claims>
</validate-jwt>
</inbound>
<backend>
<forward-request />
</backend>
<outbound />
<on-error />
</policies>
Screen cap of the Postman screen where I get the token (this works, but then when I send the request --> 401)
Screen cap of aud param in jwt.ms
I had some problems with validating Azure AD tokens a couple of years back - see my write up.
I suspect the problem is the nonce in the JWT header.
You're not really required to check value of aud parameter. You could remove required-claims alltogether, this way token presence and signature would still be validated. If you want to make sure that token was issued for your app, just find the claim that contains app id and use it in name="..." to match against your app id value.
if using v2 version endpoint, go to -> azure ad -> app registration -> select backend-app -> manifest -> update property "accessTokenAcceptedVersion": 2,"

Forward requests to regional API based on a specific JWT claim

Is it possible to forward requests to regional API based on a specific JWT claim?
The platform I'm working on has one API per region, and our customers are required to know it in order to build the base request URL - e.g.: https://{region}.service.com
Unfortunately, the only reliable way to try and figure out which regional api to call automatically from Azure APIM (e.g.: calling a single endpoint at https://api.service.com), in our scenario, would be by analyzing a claim that always comes with the bearer token (which we already do at the APIM level.)
Has anybody had the need to do it this way? Thanks in advance!
APIM policy expressions along with "choose" policy allow you to create arbitrary processing logic: https://learn.microsoft.com/en-us/azure/api-management/api-management-policy-expressions.
Access to JWT is available as
context.Request.Headers.GetValueOrDefault("Authorization").AsJwt()
It returns Jwt object (look for it's properties on the same page above).
All this combined with "set-backend-service" policy should be sufficient to do the job.
Vitaly's answer was the key to figuring this one out. Here is the complete answer, in case anybody is looking for the same thing.
<policies>
<inbound>
<!-- Extract Token from Authorization header parameter -->
<set-variable name="token" value="#(context.Request.Headers.GetValueOrDefault("Authorization",string.Empty).Split(' ').Last().AsJwt())" />
<choose>
<when condition="#(context.Variables["token"] != null)">
<set-variable name="api_uri" value="#(((Jwt)context.Variables["token"]).Claims.GetValueOrDefault("api_uri", string.Empty))" />
<choose>
<when condition="#(context.Variables["api_uri"] != string.Empty)">
<set-backend-service base-url="#((string)context.Variables["api_uri"])" />
</when>
<otherwise />
</choose>
</when>
<otherwise />
</choose>
<base />
</inbound>
</policies>

Resources