Remove MapIdentityApi's InfoResponse.Claims property

[halter73]

Description

This is a public API change to remove the InfoResponse.Claims property which was first made public in RC2. The API was approved last week during API review (Notes).

The API was already broken in common scenarios where a user has multiple roles causing multiple claims with the same type. This cause an ArgumentException in the /manage/info endpoint when it attempted to add duplicate Key in the now-deleted public IDictionary<string, string> Claims property.

We had considered trying to fix the Claims property by making it an array or a dictionary of arrays, but @mconnew brought up the possibility that developers would not always expect clients to read their own claims. With cookies and JWE tokens claims are encrypted and potentially secret even to the authenticated user. When we consulted @blowdart, he agreed that we should avoid exposing claims from MapIdentityApi<TUser>() to be safe even though he hadn't personally seen an example of a claim that needed to be kept secret from an authenticated client.
 
Fixes #50037

Customer Impact

Prior to this change, the /manage/info endpoint added by the new MapIdentityApi<TUser>() method introduced in .NET 8, would return an empty 500 response when the user making the request had a ClaimsPrincipal with multiple claims of the same type. This is very common when a user is in multiple roles and was reported by a customer shortly after the /manage/info endpoint was added in preview 7. This made the entire endpoint unusable for these users.

Regression?

• Yes
• No

[If yes, specify the version the behavior has regressed from]

Risk

• High
• Medium
• Low

This is simply removing new API that was first added in .NET 8 preview 7 and made public in RC 2.

Verification

• Manual (required)
• Automated

Packaging changes reviewed?

• Yes
• No
• N/A

[ghost]

Hi @halter73. Please make sure you've updated the PR description to use the Shiproom Template. Also, make sure this PR is not marked as a draft and is ready-to-merge.

To learn more about how to prepare a servicing PR click here.

[ghost]

Hi @halter73. This PR was just approved to be included in the upcoming servicing release. Somebody from the @dotnet/aspnet-build team will get it merged when the branches are open. Until then, please make sure all the CI checks pass and the PR is reviewed.

[augustevn]

I think you broke the Blazor WASM way of informing our AuthenticationStateProvider of our claims. At least you broke the seamless integration of that with the Identity Endpoints. So now we must expose the claims ourselves using a custom endpoint... What did you/we win?

More of my thoughts on this: #52142

I'm having doubts on how you test and validate these authentication flows from front to back.
I think it's time to pull your heads out of your back-ends.

[ghost]

Hi @augustevn. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.

[martincostello]

@augustevn Please follow the code of conduct and speak respectfully to the team.

[ghost]

Hi @martincostello. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.

[augustevn]

It's just a pun, I understand you may have a lot on your plates and have to support more than just the bearer token scenario.

[ghost]

Hi @augustevn. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.