Azure App Service ClaimsIdentity.RoleClaimType wrong if using Microsoft Identity Provider

[mr-sven]

Microsoft.Identity.Web Library

Microsoft.Identity.Web

Microsoft.Identity.Web version

1.25.9

Web app

Sign-in users

Web API

Protected web APIs (validating scopes/roles)

Token cache serialization

In-memory caches

Description

I'm using an Azure App Service with .NET Core 7.

As soon as I enable App Service authentication with Microsoft Identity Provider, the property ClaimsIdentity.RoleClaimType is http://schemas.microsoft.com/ws/2008/06/identity/claims/role what causes User role checking is failing.
In case the App Service authentication is disabled, the property ClaimsIdentity.RoleClaimType is roles so the role checking is working.

I tried the sample: https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/tree/master/5-WebApp-AuthZ/5-1-Roles it is se same.

I've striped down the code to a simple app: https://github.com/mr-sven/AzureAppRoleTest
Page run without App Service Auth:

Page with App Service Auth:

I've found varous issues:

• ClaimsPrincipal.IsInRole doesn't work with AAD application roles Azure/azure-functions-host#3898
• Documentation: How to use EasyAuth with Azure AppService and Roles? #881

At the moment I'm using this Middleware to get around the issue: https://blog.johnnyreilly.com/2021/01/17/azure-easy-auth-and-roles-with-net-and-microsoft-identity-web/

Reproduction steps

1. Create Azure App Service
2. Register App
3. Enable App Service authentication using the registered app
4. Checkout https://github.com/mr-sven/AzureAppRoleTest
5. Deploy Code
6. Open index page,

Error message

No response

Id Web logs

No response

Relevant code snippets

WebApplicationBuilder builder = WebApplication.CreateBuilder(args);

JwtSecurityTokenHandler.DefaultMapInboundClaims = false;

builder.Services.AddMicrosoftIdentityWebAppAuthentication(builder.Configuration)
        .EnableTokenAcquisitionToCallDownstreamApi(new string[] { "user.read" })
        .AddInMemoryTokenCaches();

// configure Open ID claims
builder.Services.Configure<OpenIdConnectOptions>(OpenIdConnectDefaults.AuthenticationScheme, options =>
{
    options.TokenValidationParameters.RoleClaimType = "roles";
});

Regression

No response

Expected behavior

ClaimsIdentity.RoleClaimType shoud also be roles if using App Service authentication.

[mr-sven]

I've did some investigations on the .Net code, I looked at System.IdentityModel.Tokens.Jwt.JwtSecurityTokenHandler, Microsoft.IdentityModel.Tokens.TokenValidationParameters and System.Security.Claims.ClaimsIdentity.
At the moment I've no clue how the ClaimsIdentity is passed from the Microsoft Identity Provider to the App. Is there some kind of background cache used?

[jmprieur]

@mr-sven : thanks for this clear repro, this helps a lot.

Setting the claims principal happens here:

microsoft-identity-web/src/Microsoft.Identity.Web/AppServicesAuth/AppServicesAuthenticationHandler.cs

Line 43 in c0d8346

AuthenticationTicket ticket = new AuthenticationTicket(claimsPrincipal, AppServicesAuthenticationDefaults.AuthenticationScheme);

.
It's not coming from the IDP directly, but from AppServices.

The bug is here:

microsoft-identity-web/src/Microsoft.Identity.Web/AppServicesAuth/AppServicesAuthenticationInformation.cs

Line 198 in c0d8346

ClaimsIdentity.DefaultRoleClaimType));

We need to take into account somehow the fact that the claim representing the role can be different.

[mr-sven]

I don't know if the RoleClaimType is also bound to the version claim, because there is aleady a check for Version 1 and if the role claim is changed in version 2 it could check for 2.0 and use roles instead of the default type name.

Or add a static field to AppServicesAuthenticationHandler where the type name can be changed.

[mr-sven]

I added a PR but I'm not shure if it is the right way, I oriented my way on other handlers options.

[mr-sven]

Ahm, one question, you moved the master now to Version 2, should I upgrade the PR also to V2 or to a V1 branch?

[jmprieur]

@mr-sven you could update your branch from the current master (which is v2 indeed).
But I'd like to spend some time providing the right design (we can probably do a bit simpler)

[berglie]

@mr-sven @jmprieur Any update on this issue? Great work btw.

[mr-sven]

I updated the PR to the v2 master, but I do not know of this is the correct approach for this. It could be a bit simpler as @jmprieur said.

[jmprieur]

@jennyf19. I added this to the project (let's discuss)