Ocelot doesn't handle correctly RouteClaimsRequirement with a key as an Url

[dmitriifilonenko]

While creating JWT for a user in my authentication service I use System.Security.Claims.ClaimTypes static class with defined string constants for various claims. So, ClaimTypes.Role == "http://schemas.microsoft.com/ws/2008/06/identity/claims/role":

var claims = new List<Claim>
{
    new Claim("ID", user.Id.ToString()),
    new Claim(ClaimTypes.Name, user.Username)
};
claims.AddRange(user.Roles.Select(role => new Claim(ClaimTypes.Role, role)));

Then, when for some Route in RouteClaimsRequirement I write: "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" : "Admin"

"RouteClaimsRequirement": {
        "http://schemas.microsoft.com/ws/2008/06/identity/claims/role": "Admin"
}

Such Route just disappears somewhere in the guts of middleware (I didn't manage to track down where this happens) and a request results in 404 because a route is not found:

Error Code: UnableToFindDownstreamRouteError Message: Unable to find downstream route for path: /api/entities/, verb: POST errors found in ResponderMiddleware. Setting error response for request path:/api/entities/, request method: POST

When I use my own claim type like "Role", this works fine. So I assume there are some issues with (de)serialization of a string containing colons or slashes, basically as any URL.

Specifications

• Version: 12.0.1 - 19.0.2

[Stians92]

I'm having this problem as well and was about to open a new issue before I found this one. I am using ClaimsIdentity.DefaultRoleClaimType.

claims.AddRange((await this.userManager.GetRolesAsync(user)).Select(o => new Claim(ClaimsIdentity.DefaultRoleClaimType, o)));

I have verified that my claim is working as intended by inspecting my token with https://jwt.io/.

Commenting to bring attention to this issue.

[Stians92]

After doing a lot of digging in the Ocelot code it looks like this isn't caused by Ocelot, but is a limitation in how Microsoft parses json files.

I also found this relevant issue on Stackoverflow: https://stackoverflow.com/questions/50788190/is-there-a-way-to-escape-colon-in-appsetting-json-dictionary-key-in-aspnetcore-c

[natiox]

Our authentication system has colons in all claim keys due to its naming scheme, so it looks like we can't use claims with Ocelot.

[vantm]

If we configure RouteClaimsRequirement like this:

"RouteClaimsRequirement": {
  "http://schemas.microsoft.com/ws/2008/06/identity/claims/role": "Admin"
}

The real result looks like:

"RouteClaimsRequirement": {
  "http": {
    "//schemas.microsoft.com/ws/2008/06/identity/claims/role": "Admin"
  }
}

That why claims checking is failed. So my solution is do not use colons. Here is my explain:

1. Create a decorator of ClaimsAuthoriser. In the method Authorise, we have to preprocess routeClaimsRequirement before pass it to real authorizer. For safety, I suggest to clone it and transforming on the copy.
2. Decorate the IClaimsAuthoriser is registered in container.
3. Edit in configuration, replace colon to your own define character.

Here is pseudocode that I use / to replace :

Decorator

public class ClaimAuthorizerDecorator : IClaimsAuthoriser
{
    private readonly ClaimsAuthoriser _authoriser;

    public ClaimAuthorizerDecorator(ClaimsAuthoriser authoriser)
    {
        _authoriser = authoriser;
    }

    public Response<bool> Authorise(ClaimsPrincipal claimsPrincipal,
                                    Dictionary<string, string> routeClaimsRequirement,
                                    List<PlaceholderNameAndValue> urlPathPlaceholderNameAndValues)
    {
        var newRouteClaimsRequirement = new Dictionary<string, string>();
        foreach (var kvp in routeClaimsRequirement)
        {
            if (kvp.Key.StartsWith("http///"))
            {
                var key = kvp.Key.Replace("http///", "http://");
                newRouteClaimsRequirement.Add(key, kvp.Value);
            }
            else
            {
                newRouteClaimsRequirement.Add(kvp.Key, kvp.Value);
            }
        }

        return _authoriser.Authorise(claimsPrincipal, newRouteClaimsRequirement, urlPathPlaceholderNameAndValues);
    }
}

Decorate IClaimsAuthoriser service

public static class ServiceCollectionExtensions
{
    public static IServiceCollection DecorateClaimAuthoriser(this IServiceCollection services)
    {
        var serviceDescriptor = services.First(x => x.ServiceType == typeof(IClaimsAuthoriser));
        services.Remove(serviceDescriptor);

        var newServiceDescriptor = new ServiceDescriptor(serviceDescriptor.ImplementationType, serviceDescriptor.ImplementationType, serviceDescriptor.Lifetime);
        services.Add(newServiceDescriptor);

        services.AddTransient<IClaimsAuthoriser, ClaimAuthorizerDecorator>();

        return services;
    }
}

// then add it to service

services.AddOcelot();
services.DecorateClaimAuthoriser(); // put it right after registering Ocelot

Update ocelot config

"RouteClaimsRequirement": {
  "http///schemas.microsoft.com/ws/2008/06/identity/claims/role": "Admin"
}

Ocelot.16.0.1

[mybirthname]

Big thanks @tmvan I started on your path and find your solution midway. Great approach and thanks for your sharing !

[tugrulelmas]

I have a similar issue. Even if I don't use ClaimTypes.Role and just try to add claims with the type role as string, Ocelot can't find the role in the user's claims and returns 403 forbidden response.

After debugging, I found out that the problem is not about Ocelot. The problem occurs becasue of the behavior of System.IdentityModel.Tokens.Jwt. When the ClaimsIdentity is creating, claim types is checked and if it's a well-known type then it is replaced with it's URI. You can find it here. So if I create a token that has a claim with the type role, HttpContext.User will has a claim with the type http://schemas.microsoft.com/ws/2008/06/identity/claims/role.

In order to change this behavior and stop the type replacing I added following line in ConfigureServices on my Startup.cs.
JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();

After that, I create JWT token with the following ClaimsIdentity;

new ClaimsIdentity(new Claim[] {
     new Claim("role", "admin"),
});

Then, I can check this claim in ocelot.json as following;

"RouteClaimsRequirement": {
  "role": "admin"
}

Clearing DefaultInboundClaimTypeMap may create some bugs but I'm not sure that. The first thing that I noticed is IsInRole method returns always false because it checks the claims with the URI http://schemas.microsoft.com/ws/2008/06/identity/claims/role

[sahilmankar]

Big thanks @tmvan I started on your path and find your solution midway. Great approach and thanks for your sharing !
The Solution that worked for me is just replacing role with Roles like

new ClaimsIdentity(new Claim[] {
     new Claim("Roles", "admin"),
});

And inocelot.json

"RouteClaimsRequirement": {
  "Roles": "admin"
}

And It didn't require to use JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();

[hakanaltindis]

@vantm commented on Jul 23, 2020:

That why claims checking is failed. So my solution is do not use colons. Here is my explain:

1. Create a decorator of ClaimsAuthoriser. In the method Authorise, we have to preprocess routeClaimsRequirement before pass it to real authorizer. For safety, I suggest to clone it and transforming on the copy.
2. Decorate the IClaimsAuthoriser is registered in container.
3. Edit in configuration, replace colon to your own define character.
   ...

Thank you so much, @vantm! This solution is very helpful for us.

[raman-m]

@vantm commented on Jul 23, 2020

What about a PR to close this issue finally?

---

@dmitriifilonenko FYI