IClaimsTransformation do not automagically compose

[arontsang]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Multiple registrations on IClaimsTransformation should compose. For pete's sake, the signature for IClaimsTransformation is literally an async reduce function.

Describe the solution you'd like

A ReducerClaimsTransformer should be injected into AuthenticationService.Transform

public class ReducerClaimsTransformation : IClaimsTransformation
{
    public async Task<ClaimsPrincipal> TransformAsync(ClaimsPrincipal principal)
    {
        foreach (var transformation in _transformations)
        {
            principal = await transformation.TransformAsync(principal);
        }

        return principal;
    }
}

Additional context

No response

[pinkfloydx33]

I remember being surprised that you could only register one IClaimsTransformation. At the time (a few years ago) we had multiple distinct use-cases for the transformation and had to combine it all into one. Not useful either if the transformer is provided by third parties (though no idea how common that is).

We no longer need the transformation as our entire Auth flow has changed, just throwing out my 2cp that at the very least it was surprising and hard to reason about without looking at the source that you could only have one.

[davidfowl]

I think this is a reasonable change to make. @HaoK do you see any problems with this? It is a breaking change that we should document though (if we do make it).

[arontsang]

@pinkfloydx33 You could have raised this issue back then...

[HaoK]

The breaking change aspect is probably the biggest deal, but since we don't do any claims transformation by default, this is just providing new behavior when multiple IClaimsTransformations have been registered. That said, given that historically claims transformation is not a side effect free operation, and in the past we've had a lot of historical issues merging ClaimsPrincipals with multiple auth schemes, and this scenario already has a straight forward workaround, how about we keep this issue open in the backlog and see how much desire there is for this behavior before making any decisions?

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.