ProfileDataRequestContext not setup with IdentityResource claims types!

[the-black-wolf]

I wanted to add a custom identity resource instead of a really large profile one and with the claim I need:

        public class BillingAccountResource : IdentityResource
        {
            public BillingAccountResource()
            {
                Name = "billing";
                DisplayName = "Billing system information";
                UserClaims.Add("billing_account_number");
                UserClaims.Add(JwtClaimTypes.Name);
            }
        }

I added it to resources and to the applicable client:

    public static IEnumerable<IdentityResource> IdentityResources => new IdentityResource[]
        {
            new IdentityResources.OpenId(),
            new BillingAccountResource()
        };
...
        // inside client setup
        AllowedScopes = { IdentityServerConstants.StandardScopes.OpenId, "billing" },

I've setup my IProfileService implementation, however, when the token is requested and the code enters GetProfileDataAsync, the context.RequestedClaimsType is empty. Enduser logged in with requested billing scope and the database entry in grant storage reflects this.

I've debug this a little and found this code here:

https://github.com/IdentityServer/IdentityServer4/blob/3ff3b46698f48f164ab1b54d124125d63439f9d0/src/IdentityServer4/src/Services/Default/DefaultClaimsService.cs#L113-L217

Apparently, the additionalClaimTypes, which is later filtered before passing to GetProfileDataAsync, is only constructed from ApiResources and ApiScopes. Identity resources are completely ignored.

Is this a bug or a desired functionality (why skip custom identity claims?), and if so how do I dynamically adjust profile service to detect if I should set 'name' and billing_account_number claims. I see the billing scope name listed in context.RequestedResources, but its just there by name, I fear the future moment where this might change and cause a disconnect between client setup and a profile service, I would much rather like to dynamically respond to requested claims rather than assume things. In the samples on the internet, people mostly just have one client and an always-requested scope so they just blindly force claims into result. We will only need billing for clients which deal with user's billing.

[leastprivilege]

Important update

This organization is not maintained anymore besides critical security bugfixes (if feasible). This organization will be archived when .NET Core 3.1 end of support is reached (3rd Dec 2022). All new development is happening in the new Duende Software organization.

The new Duende IdentityServer comes with a commercial license but is free for dev/testing/personal projects and companies or individuals making less than 1M USD gross annnual revenue. Please get in touch with us if you have any question.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Questions are community supported only and the authors/maintainers may or may not have time to reply. If you or your company would like commercial support, please see here for more information.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.