Issue with Token Authentication and User Login Information after Upgrading to Abp Framework Version 8

[abdullahshaqaliah]

Dear Support Team,

I trust this message finds you well. I am reaching out to you again regarding the issue I reported earlier after upgrading from Abp Framework version 7 to version 8. To provide more clarity and assist in the investigation, I have attached a screenshot that illustrates the problem.

In the attached image, you'll notice that when sending a token to the API, only the user's name and some additional data are being transmitted. However, there is no indication of the login status or user ID, which was a part of the expected behavior before the upgrade.

I believe that this visual representation will help in better understanding the issue at hand. Please review the attached screenshot and let me know if there are any specific details or logs you require for a more in-depth analysis.

Thank you for your attention to this matter. I appreciate your prompt assistance in resolving this critical issue.

[abdullahshaqaliah]

@maliming ???

[maliming]

hi

Steps needed to reproduce the problem.

[abdullahshaqaliah]

@maliming Did you see the picture ??? why other information like Id and roles not sent with the access token with Abp 7 it's working after just upgrading to 8 if face the problem Please see the picture

[maliming]

Hi

I can't figure out the problem by a picture.

[abdullahshaqaliah]

I already login by Swager then I make request by API

[abdullahshaqaliah]

@maliming See the picture why the current user is not login and not hold IsAuthenticated and id and user roles??

[abdullahshaqaliah]

I used this PackageReferences with microservices `

    <PackageReference Include="Microsoft.AspNetCore.Authentication.JwtBearer" Version="8.0.1" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc.Versioning.ApiExplorer" Version="5.1.0" />
    <PackageReference Include="System.IdentityModel.Tokens.Jwt" Version="7.3.0" />
    <PackageReference Include="TenTime.AdministrationService.EntityFrameworkCore" Version="4.0.0" />
    <PackageReference Include="TenTime.Redis.OM.Repository" Version="3.0.0" />
    <PackageReference Include="Volo.Abp.EventBus.RabbitMQ" Version="8.0.2" />
    <PackageReference Include="Volo.Abp.BackgroundJobs.RabbitMQ" Version="8.0.2" />
    <PackageReference Include="TenTime.Shared.Hosting.Settings" Version="6.0.0" />
    <PackageReference Include="Volo.Abp.Http.Client.IdentityModel.Web" Version="8.0.2" />
    <PackageReference Include="Volo.Abp.Identity.AspNetCore" Version="8.0.2" />
    <PackageReference Include="Volo.Abp.DistributedLocking" Version="8.0.2" />  
    <PackageReference Include="DistributedLock.Redis" Version="1.0.2" />
    <PackageReference Include="AspNetCore.HealthChecks.NpgSql" Version="8.0.0" />
    <PackageReference Include="AspNetCore.HealthChecks.UI.Client" Version="8.0.0" />
</ItemGroup>`

[abdullahshaqaliah]

If you see the user token already have user information

[abdullahshaqaliah]

@maliming See the claims already hold all user information the problem with ICurrentUser is not hold all user information

[abdullahshaqaliah]

@maliming ???

[maliming]

I don't know your code. But you can try:

AbpClaimTypes.UserId = JwtClaimTypes.Subject;
AbpClaimTypes.Email = JwtClaimTypes.Email;

You can share your jwtbearer authentication code.

[abdullahshaqaliah]

[DependsOn( typeof(AccountServiceHttpApiModule), typeof(TenTimeSharedHostingSettingsModule), typeof(AccountServiceApplicationModule), typeof(AdministrationServiceEntityFrameworkCoreModule), typeof(AccountServiceEntityFrameworkCoreModule), typeof(AbpIdentityAspNetCoreModule), typeof(AbpBackgroundJobsRabbitMqModule), typeof(AbpEventBusRabbitMqModule), typeof(AbpDistributedLockingModule), typeof(AbpHttpClientIdentityModelWebModule), typeof(TenTimeRedisOMRepositoryModule), typeof(AbpSecurityModule), typeof(TenTimeSecurityModule))] `

private void ConfigureAuthentication(ServiceConfigurationContext context, IConfiguration configuration)
{

    context.Services.AddAuthentication("Bearer").AddJwtBearer(delegate (JwtBearerOptions options)
    {
        options.Authority = configuration["AuthServer:Authority"];
        options.RequireHttpsMetadata = Convert.ToBoolean(configuration["AuthServer:RequireHttpsMetadata"]);
        options.Audience = configuration["AuthServer:ApiName"];
    });
}

`

[maliming]

Does this work?

AbpClaimTypes.UserId = ClaimTypes.NameIdentifier;
AbpClaimTypes.Email = ClaimTypes.Email;

[abdullahshaqaliah]

@maliming its working Where is the problem there need any module to load??

[maliming]

I'm not sure unless I can see the complete code.

[abdullahshaqaliah]

@maliming What is the module name responsible for assigning the AbpClaimTypes??

[abdullahshaqaliah]

@maliming The problem happen just when upgrade from 7 to 8 before its working we are not change the our code

[maliming]

I'm not sure unless I can see the complete code.

[agustinsilvano]

@maliming @abdullahshaqaliah Not sure if we are using the same setup but I'm using the old Auth Server (Identity Server 4, we are planning to migrate to OpenIdDict shortly). I made the upgrade from v7 (where the application was working fine) to v8 and faced the same issue that Abdullah.

Seems like the there is a miss match on the naming of the claims that abp uses to establish the current user and roles. I also found that the application-configuration endpoint was missing the permissions assigned to the logged user because it was not able to resolve properly the roles stored on the JWT token.

What I did?

I had to add the following mapping to the module definition of my web api projects.

AbpClaimTypes.UserId = ClaimTypes.NameIdentifier;
AbpClaimTypes.Email = ClaimTypes.Email;
AbpClaimTypes.Role = ClaimTypes.Role;
AbpClaimTypes.UserName = ClaimTypes.Name;

By adding that the role key called "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" instead of the regular role, it does the trick. I tried to create a JWT token using OpenIdDict but I found that you are using the role key instead of the url-wise key.

If I decode my token using jwt.io I see

I want to know if that is expected, worried about having a clunky setup.

By having the default values it didnt work, could be possible that something overrode the value of these AbpClaimTypes class in the v8?

[agustinsilvano]

In addition to my last comment, digging into the source code I found this AbpClaimsMapOptions class that is being used in AbpClaimsMapMiddleware class.

So seems like the old sub and role claims must be mapped to the appropiate AbpClaimTypes, isn't it?

Don't fully understand why we need to set the values of the static properties of the AbpClaimTypes class.

[maliming]

hi @agustinsilvano

Can you share a simple project?

[agustinsilvano]

@maliming sadly I cant share the code given that it has sensitive information.

I'll try to do a sample with a blank solution.

Actually, let me ask you something, should the AbpClaimsMapMiddleware be involved on this process of establishing the current user and all that info?

I tried to override it but it was never called on the request flow.

[agustinsilvano]

@maliming I migrated a project that I had in v7.3 (with OpenIdDict) and the upgrade worked fine. So, seems like is related to the Identity Server setup.

Let me ask you, what's the class that does that mapping?

For example, If I decode the JWT token the user id "sub" property is transformed into "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier".

[maliming]

hi

So, seems like is related to the Identity Server setup.

It depends on your project, that's why I've asked many times for a reproduction project

[agustinsilvano]

@maliming here you have a sample vanilla project with the same issue.

There is a TestAppService that checks for the roles of the current user, I was able to reproduce the same issue with that project.

I started from v4.3.3 and upgraded to v8.0.4.

Hopefully it helps to find the root cause.

[maliming]

hi

Thanks. I will check your project.

[maliming]

hi

There are two solutions in your HttpApi.Host project:

1 UpdateAbpClaimTypes

public override void PreConfigureServices(ServiceConfigurationContext context)
{
    context.Services.PreConfigure<AbpIdentityServerBuilderOptions>(options =>
    {
        options.UpdateAbpClaimTypes = false;
    });
}

2 MapInboundClaims.

context.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.Authority = configuration["AuthServer:Authority"];
        options.RequireHttpsMetadata = Convert.ToBoolean(configuration["AuthServer:RequireHttpsMetadata"]);
        options.Audience = "BookStore2";
        options.MapInboundClaims = false;
    });

[agustinsilvano]

@maliming thanks for the quick response!

It worked like a charm! 👏🏽👏🏽👏🏽

[antonGritsenko]

@maliming which one is better? What side effect of setting UpdateAbpClaimTypes to false? PS IMO this information must be added to the migration guide, this case 100% reproducible when upgrading from 7 to 8 with old IdentityServer.

[maliming]

hi @antonGritsenko

Both are fine. It depends on your actual project.

I have posted an article about claim type. https://community.abp.io/posts/how-claim-type-works-in-asp-net-core-and-abp-framework-km5dw6g1