Microsoftadrian_hall Great works. Thanks for this new policy. Quick question why did you guys decide to make client ID and audience, mandatory? What if somebody wants to check for different attributes at different levels. For example, at the API level I would like to do something like below policy and it doesn't let me do that (I have already validated client Ids and Audience at the Product Policy level)
<validate-azure-ad-token tenant-id="contoso.onmicrosoft.com" failed-validation-error-message="Invalid claims.">
<openid-config url="https://login.microsoftonline.com/contoso.onmicrosoft.com/v2.0/.well-known/openid-configuration" />
<claims-to-validate>
<claim name="roles" match="USA" />
</claims-to-validate>
<failed-validation-response>
<set-status code="401" reason="Unauthorized" />
<return-response>
{
"error": "The provided JWT token does not contain the required claim."
}
</return-response>
</failed-validation-response>
</validate-azure-ad-token>
This forced me to use the old validate-jwt policy to check for the existence of the claims I want to check which works just fine but obviously I want to use the new policy there too without having to repeat what I already checked at the Product level:
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Invalid calims">
<openid-config url="https://login.microsoftonline.com/contoso.onmicrosoft.com/.well-known/openid-configuration" />
<required-claims>
<claim name="roles" match="all">
<value>USA</value>
</claim>
</required-claims>
</validate-jwt>
How do we do chaining of token validation using this new policy?