What is the use of IClaimsTransformer?

Question

In ASP.Net core lets you use an implementation of IClaimsTransformer.

You register it like this:

app.UseClaimsTransformation(o => o.Transformer = new MyClaimsTransformer());

Implementation

public class MyClaimsTransformer : IClaimsTransformer
{
    public Task<ClaimsPrincipal> TransformAsync(ClaimsTransformationContext context)
    {
        var identity = context.Principal.Identity as ClaimsIdentity;

        foreach (var claim in ci.Claims)
        {
           // you cannot modify claim.Type or claim.Value here
        }
    }
}

However ClaimsIdentity.Claims is read only property. Also Claim.Type, Claim.Value are readonly properties.

That means in the implementation of IClaimsTransformer you can only add new claims. You cannot remove or modify existing claims.

So whats the real use of IClaimsTransformer?

Islek

Answer 1

Did you notice the return type? It's ClaimsPrincipal.

You can construct a whole new ClaimsPrincipal, adding or changing whatever you like from the existing one and return it.

Eventide

Would this be a standard pattern? For example - I use IdentityServer4 as an OIDC provider to authenticate the user and provide an id_token back to my ASPNET core app. But my app needs the authenticated user to have claims from the business domain. I use the Claims Transformation to build a new ClaimsPrincipal after querying some business service to get the relevant info. Presumably I would need to cache this info as the transformation is going to run on every request. Are there any tutorials or guidance on this? Thanks in advance.. – Neisa

@Neisa did you go down this route? Did you find any guidance? – Boggess

@Boggess - still struggling with this concept. The claims transformer in aspnet core doesn't work well - seems to add duplicate claims. It seems quite a good way to separate concerns as the app can just rely on business claims and make authorisation decisions without having work too hard. Other issue with the IClaimsTransformer is that you cannot inject dependencies, e.g. a service or repository to get the business claims from. If you have any ideas or best practice I would interested to hear. github.com/aspnet/Security/issues/863 – Neisa

@Neisa Well, I'm also looking for some best practice. I added this question, it shows how my current implementaion is (no caching) #42668595 – Boggess

@Boggess - that is exactly the way I imagined it working, but I cannot find any guidance either - Google didn't turn up much. I'll keep an on your question and see if anyone else can help – Neisa

That ClaimsPrincipal that gets passed has no claims that I could interrogate. I was planning to look at the claims and modify if necessary, but there is nothing there. Any idea what that is – Burleson

Answer 2

the value of it is that you can supplement the claims beyond what is stored in the authentication cookie.

It is useful because only so much data can go into a cookie, if you try to put too much it will truncate.

So if you have a lot of claims or claims with a large payload you could maybe store that data in session and add it to the claimsprincipal using claims transformations. I don't think it is intended to remove claims that were stored in the cookie. If you want to add or control what claims go in the cookie you would do it in a custom IClaimsPrincipalFactory.

Unprecedented

If i store the data in session i can just directly read it from session since session is available on HttpContext. Why would i put in Claims and read it from Claims. – Islek

claims can be used for a variety of purposes. one common use is in satisfying requirements for an authorization policy. most cases claimstranformations are not needed because in most cases you can avoid lots of claims or large claim payloads, but it is there if you need it. you may not need it but it does have uses, perhaps mainly edge case uses. – Unprecedented

@Eventide has a better answer than mine for sure – Unprecedented

I use it to seed a claim for identities that originated from the app itself. I didn't want to put the claim into the actual user database. I also accept bearer tokens that didn't originate from the app. In the end, I only let in identities that have a specific claim, and local identities all get this claim. Problem though: The actual identity in the passed in principal has no claims yet, so my plan to interrogate the identity itself is still being investigated. So anything that DOES NOT come in via a bearer token gets my seed claim. – Burleson