Why Aren't Multiple Identities Allowed on the ClaimsPrincipal?

[msaldaco]

Hi,

I was working on tenant impersonation (where the all user information stays the same except for their tenant information) and attempted to enhance the current ClaimsPrincipal by adding a new identity to it with the impersonated tenant data. I chose that approach because I thought it might be cleaner, made it easier to avoid polluting the original ClaimsIdentity, and would make it easier to more easily separate identity data between client apps making use of the same user session from the server. I then discovered that multiple identities aren't allowed by the Duende framework.

Is there a reason for not allowing more than one identity? I only found two places it checks for this, one in GrantValidationResult and the other in IdentityServerAuthenticationService but all the comment said was:

for now, we don't allow more than one identity in the principal/cookie

Is it due to potentially causing side effects in identity's logic regarding how it uses the ClaimsIdentity?

[RolandGuijt]

ClaimsPrincipal has a number of functionalities, methods and properties that assume one identity. To avoid problems we only allow one.
From our viewpoint the possibility to add multiple is almost never used in practice. But if customers reading this need this please let us know why.
For now the best direction would be to create a new ClaimsPrincipal if possible. In the OAuth spec there is the idea of an actor claim that points to the original identity. Maybe that would be a good solution here too.

[msaldaco]

Gotcha. A few additional details then:

We use a custom prompt to trigger redirecting to a page the user can use to select the tenant to impersonate. Once selected, the current user principal gets updated with the new claims.

We are currently using an actor claim which gets set in the custom IProfileService based on the claims set in the previous statement. We only allow the actor claim to be set for the client that initiated the request. To ensure this, the new claim includes the client ID, like this new Claim("type", $"{clientId},value"). This way the actor claim doesn't get set for a different client that isn't allowed to do impersonation, and there's no cross contamination between different clients.

I think part of what made this difficult for us to figure out is we don't currently store this impersonation data in the database. A lot of it was initial prototyping and we didn't know if storing it in the database would be of any actual benefit because of how we restrict the impersonation between clients. It exists ephemerally in the cookie. Because of this, the only way we were able to get this information to use in our custom IProfileService was by setting it on the user principal so it could get passed in on the Subject property of the ProfileDataRequestContext object. So, I don't know if multiple ClaimsPrincipals would be feasible in our case.

[AndersAbel]

This is an example of a "session claim", i.e. a claim that describes the properties of the session and that should not apply to other sessions by the same user. It makes perfect sense to not store these in the database. The information in the user store (which is what the profile service expose) should be the properties of the user that are the same regardless of session. Some example of session claims are sid, auth_time, amr and acr.

I don't see that you mentioned where you want these claims to be made available to the client: In the id_token? In access_tokens? Or on the user info endpoint for that particular client? If you could share some more information, I can provide some hints on extension points in IdentityServer.

[msaldaco]

Thank you for explaining that about session claims.

This is currently only exposed in the access token at the moment since many of our APIs are required to depend on the tenant in order to manage data properly.

The access token looks something like this:

{
    "iss": "https://myissuer.issuer",
    "...": "...",
    "tenant": "impersonated_tenant",
    "act": {
        "tenant": "home_tenant"
    }
}

And then these are set from new Claim("tenant", "home_tenant") and new Claim("imp_tenant", "client1,impersonated_tenant") from the principal.

[AndersAbel]

Just following up here. It looks like you have a working solution now? Or do you need any more assistance?

[msaldaco]

We already had a working solution when I posted this. I apologize for the misunderstanding, my ask was not for help with our work, but to spark a conversation around why multiple identities could not be added when I found out they were explicitly blocked by the Duende framework.

In our case, an option to disable that validation would be nice, though it'd be more difficult to implement something like that for the GrantValidationResult vs something like IdentityServerAuthenticationService which we can probably override ourselves. I heard y'all are working on improving extensibility points for the framework. If you could consider adding GrantValidationResult to that, then my side could implement our own solution to allow the multiple identities.