[Feature Request] (or Bug) - AccountID and CacheKey construction overrides

[michiproep]

Is your feature request related to a problem? Please describe.
Our B2C tenant/policy provides a feature where certain admin users can (e.g. for support reasons) impersonate another user.
After such an "Admin-Login" the ID and access token contain a special claim which identifies the admin user whereas the sub/oid stays as if the real user would login.
All our applications and APIs are aware of this feature there is one situation which they cannot handle:
Let's say the real user logs in first and the support person after. The tokens in the cache for the real user get overriden with the tokens of the support user which contain additional claims which in term causes serveral issues, starting from simple session logging/statistics up to more serious situations if the application provides addition features for a "alias-session".

We already tryed to override MsalDistributedTokenCacheAdapter.GetSuggestedCacheKey but this doesn't work (that's why I wrote bug in the caption) because TokenCacheNotificationArgs do not always contain the args.Account.GetTenantProfiles().FirstOrDefault()?.ClaimsPrincipal, e.g. when it is called from this library via TokenAcquisition.GetAuthenticationResultForWebAppWithAccountFromCacheAsync

The final goal is to have seperate cache entries for tokens which have the same oid/userflow but might contains a secondary account-relevant-claim.

Describe the solution you'd like
Make (Extension)methods in ClaimsPrincipalExtensions overrideable, especially GetMsalAccountId, GetHomeObjectId, GetNameIdentifierId. (Could be done via DI)

Describe alternatives you've considered
Since there a many places where this bubbles down through code which I haven't touched yet, e.g. via GetAuthenticationResultForWebAppWithAccountFromCacheAsync I don't really see another approach

[jmprieur]

@michiproep can you please tell us more about this scenario?
What claims enable you to detect this case?
]
The claims principal extension methods are static, so not overridable, but we could probably design an extensibility mechanism if we understand the scenario.

[michiproep]

Hi @jmprieur, thanks for asking.
Let me try to explain.
We have one - exactly one - user flow which supports normal login with a homeRealmDiscovery screen.
The feature we implemented is: A support/admin user with special permissions can use the hrd screen to input an email-adresse with an "=" prefix, e.g. "=[email protected]". This will ask the admin user to signIn with his company-AzureAdAccount + API callback for verifiying his admin rights. If everything is ok, he will get tokens for "[email protected]" including an extra claim "aliasAdminOid".
There are more security mechanisms to this flow but this would lead into too much details.

Not changing the orginial oid/sub but adding this extra claim will enure that in the first place they beviour within our (about 100) applications everything is completly transparent but the option for further detecting an alias-session is given.
But this leads to the fact that the same cache/tokens are used at the same time for the real user and the alias user.

I would need to contruct the accountID like (just an example)

var accountString = base.GetMsalAccountId(principlal);
if(claim.Exists(mySpecialClaim){
   accoutnString += $".{myClaim.Value}";
}

Since the "MsalAccountId"-extension method and also the other methods which are sometimes used in B2C case (and sometimes not!!!) within Microsoft.Identity.Web, I need to be able to override the AccountId-Contruction which propagetes everything down to L1/L2 cache, calling downstreamApi.AsUser with or without an explicit "userFlow".

By the way: "calling downstreamApi.AsUser with or without an explicit "userFlow"" will use "GetMsalAccountId" since in
"GetAuthenticationResultForWebAppWithAccountFromCacheAsync" the check "IsB2C and !string.IsNullOrEmpty(userFlow)" is wrong in my opinion since userFlow is optional => may-be use standard signInPolicy in this case.

Shall I provide more infos?