7.0 upgrade 8.0.1 CurrentUser Id is null

[myall200]

Is there an existing issue for this?

• [X] I have searched the existing issues

Description

Upgrade after ,Claims sub change to http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier

Reproduction Steps

No response

Expected behavior

No response

Actual behavior

No response

Regression?

No response

Known Workarounds

No response

Version

8.0.1

User Interface

Common (Default)

Database Provider

EF Core (Default)

Tiered or separate authentication server

Separate Auth Server

Operation System

macOS

Other information

No response

[myall200]

The same code, in version 7.0, is normal with the value sub

[OxOld]

IDS4 Temporary solution PreConfigure<AbpIdentityServerBuilderOptions>(builder => { builder.UpdateAbpClaimTypes = false; builder.UpdateJwtSecurityTokenHandlerDefaultInboundClaimTypeMap = false; }); AbpClaimTypes.UserName = JwtClaimTypes.Name;

[gterdem]

How to reproduce this? Are you using IdentityServer module? Where do you check the CurrentUser? HttpApi or MVC/BlazorServer side?

[bodeg]

Hi. My multi-layer solution uses Angular as the UI framework. I upgraded the solution from version 6 to version 8 following the documented migration guides.

After upgrading the solution:

• The Swagger works fine for all the API that requires authorization.
• The Angular fails on any authorization check.

As described above, one issue that I found was that IdentityUserManager.GetUserAsync(ClaimsPrincipal principal) - returns null

that method checks for the ID at _identityUserManager.Options.ClaimsIdentity.UserIdClaimType (= "sub")

while it is in ClaimTypes.NameIdentifier (= "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier")

Thanks for any help

[bodeg]

IDS4 Temporary solution PreConfigure<AbpIdentityServerBuilderOptions>(builder => { builder.UpdateAbpClaimTypes = false; builder.UpdateJwtSecurityTokenHandlerDefaultInboundClaimTypeMap = false; }); AbpClaimTypes.UserName = JwtClaimTypes.Name;

Thanks for sharing. Can you elaborate on how to do that?

[younessiysa]

@bodeg I encountered the same issue when updating from ABP 6.0.3 to 8. The problem arises with CurrentTenant.Id being null when using Angular. Interestingly, the functionality works fine in Postman.

[maurobellati]

I also have the same issue.

We are using OpenIddict module and the temporary proposed solution

PreConfigure<AbpIdentityServerBuilderOptions>(builder => 
{
  builder.UpdateAbpClaimTypes = false;
  builder.UpdateJwtSecurityTokenHandlerDefaultInboundClaimTypeMap = false; 
});

does not work, because the validation done by OpenIddict

System.InvalidOperationException: The specified principal was rejected because the mandatory subject claim was missing.
   at OpenIddict.Server.OpenIddictServerHandlers.ValidateSignInDemand.HandleAsync(ProcessSignInContext context)
   at OpenIddict.Server.OpenIddictServerDispatcher.DispatchAsync[TContext](TContext context)
   at OpenIddict.Server.OpenIddictServerDispatcher.DispatchAsync[TContext](TContext context)
   at OpenIddict.Server.AspNetCore.OpenIddictServerAspNetCoreHandler.SignInAsync(ClaimsPrincipal user, AuthenticationProperties properties)
   at Microsoft.AspNetCore.Authentication.AuthenticationService.SignInAsync(HttpContext context, String scheme, ClaimsPrincipal principal, AuthenticationProperties properties)

More info

The generated access_token contains the correct claims (sub) as we can see from /connect/introspect endpoint.

{
  "active": true,
  "sub": "3a0e2758-dd83-a31f-6caf-a147fd6e548e",
  "token_type": "Bearer",
  "token_usage": "access_token",
  ...
}

But when using the same token in any other endpoint, the sub changes to http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier as mentioned by @myall200

Fro the investigation done so far, it seems the ClaimsIdentityOptions.UserNameClaimType is updated properly, so there must be some misconfigured moddleware that renames claims back to the defaults.

@gterdem can you please point us in the right direction so we can help to investigate or solve (even temporary) the issue? Thank you

[maurobellati]

In case someone is looking for a workaround or a partial solution. @myall200

We explicitly set JwtBearerOptions.MapInboundClaims = false as:

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
  .AddJwtBearer(
      options => {
        options.MapInboundClaims = false;
        // other config

[bodeg]

@maurobellati, you are a lifesaver ))

Thanks for sharing.

[maurobellati]

@bodeg you are welcome. Happy it works for you too!

[gterdem]

@maliming Can this be related to dynamic claims?

[maliming]

@maliming Can this be related to dynamic claims?

I don't think so.

Can anyone share a simple project that reproduces the problem?

Or you can download a new 8.x template project to compare the code.

[maliming]

See https://github.com/abpframework/abp/issues/18895#issuecomment-1993588224