ParameterizedScopeParser service not called in UserInfo

[ikirkpat]

Request:

Please update the scope treatment in user info to act the same as it does in access token fetching. If I have a parameterized identity resource scope, the argument should be handled so my profile service sees the parsed parts of the scope and the resource store doesn't have to parse the scopes manually.

Problem Statement:

I have a duende implementation that associates users with a list of school districts. When my client requests an openid token with a particular identity resource (call it userInfo), I need the client to somehow tell the end API that it's going to call which district we're authorizing the user in the context of. The only way I can think of to do this is to parameterize the scope for the identity resource (so scope would be something like userInfo:12345). This works great when I am fetching the token. However, when I see the user info endpoint called, the resource store get passed the raw scope (whereas the get token endpoint passes the parsed scope name).

I adjust for this to parse inside the resource store if not parsed already but then, when it gets to the profile service, the argument is dropped cause I returned the resource with it's base name (without the argument). So I restore the argument part on the identity resource but then the scope seems gets added (not by me so IDK what adds it) to parsed scopes by the time it gets to the profile service (IDK how if it's not parsing the scopes in the framework). The problem is that it gets added un-parsed with the argument still on the parsed name, not parsed parameter property.

I can work around this but only if I make my profile service account for parsed scopes having un-parsed values. This is very much undesirable.

My Own Research Findings:

I see this issue that was raised on what appears to be a legacy duende repository: DuendeArchive/Support#1424

I see this line in your source code:
https://github.com/DuendeSoftware/products/blob/main/identity-server/src/IdentityServer/ResponseHandling/Default/UserInfoResponseGenerator.cs#L123

This parsing is needed in order to facilitate client authorizing a user in the context of some larger context (like a teacher authorizing within a school district).

[wcabus]

We will discuss this with the engineering team to potentially improve this service or its extensibility for a future release. For now, the fastest way you can achieve the additional functionality you need, would be to create your own version of the UserInfoResponseGenerator class and adapt were necessary.

You can then register your implementation before registering IdentityServer:

builder.Services.AddTransient<IUserInfoResponseGenerator, CustomUserInfoResponseGenerator>();

builder.Services.AddIdentityServer(...);

[ikirkpat]

Thank you!

[ikirkpat]

Here is my adaptation. I hope this helps. I updated the unit tests as well.
Duende_380_Changes.zip

I wasn't sure about if ResourceIndicators need to be accounted for in the validator but it's not available in the scope of this class anyways so if it was accounted for, I think there would need to be changes to how this class is used in the rest of the codebase (like probably a change to the parameters in the public facing interface of this class).

[wcabus]

We are considering this, but we would also love to see input from additional folks needing this customization before considering changing this behavior.

[ikirkpat]

Thank you for considering it. But I would argue it's not really new customization but rather a bug to be patched. Custom scope parsing is already a feature that you guys support via overriding the scope parser (It's even documented as supported here: Parameterized Scopes).

This isn't simply more customization. It is a gap in the support for that feature that is already supported elsewhere. It's supported in the token endpoint out of the box because that logic actually calls the parser before passing the scopes around. So some places, the scope gets handed to us parsed, others, it gets handed to us un-parsed. The scope parsing is honored elsewhere in the app but not here.

All this is asking for is for the user info endpoint to also honor the overridden scope parser instead of ignoring the scope parser.

[AndersAbel]

I have recently implemented parameterized scope support for IdentityResources too in a project, so you're not the only one requesting it.