Ocelot: Api doesn't seem to recieve any claims from Ocelot for authenticated route

[wayne-o]

Expected Behavior / New Feature

User ClaimsPrinciple is populated with claims

Actual Behavior / Motivation for New Feautre

Although the user seems to get through the controller with [Authorize(AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)] - it actually doesn't look like it is authenticated and definitely doesn't have any claims associated with it - for instance no SUB claim - I have no idea how this is possible so i must be doing something wrong!

In my api startup I call into an extension method to configure auth:

services.ConfigureIdentity(Configuration, "FrontendBff");

The code for that extension method looks like this:

public static IServiceCollection ConfigureSonatribeIdentity(this IServiceCollection services, IConfiguration configuration, string scheme = null)
        {
            JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();

            var identityUrl = configuration.GetSection("IdentityServer")["Url"];
            var audience = configuration.GetSection("IdentityServer")["Audience"];

            services.AddAuthentication(options =>
            {
                options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
                options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;

            }).AddJwtBearer(scheme, options =>
            {
                options.Authority = identityUrl;
                options.RequireHttpsMetadata = false;
                options.Audience = audience;
            });

            return services;
        }

On the Ocelot side the code for the auth setup looks like this:

s.ConfigureSonatribeIdentity(Configuration, "SonatribeFrontendBff");

Which uses the same extension method

And the config for the route that's being investigated is:

{
      "DownstreamPathTemplate": "/api/v1/draft-orders",
      "UpstreamPathTemplate": "/api/v1/draft-orders",
      "UpstreamHttpMethod": [ "Get", "Post" ],
      "AuthenticationOptions": {
        "AuthenticationProviderKey": "FrontendBff"
      },
      "DownstreamScheme": "http",
      "DownstreamHostAndPorts": [
        {
          "Host": "ticketreservations.api",
          "Port": 80
        }
      ]
    }

Is there anything glaringly wrong with what I am doing?

Steps to Reproduce the Problem

1.
1.
1.

Specifications

• Version:
• Platform:
• Subsystem:

[TomPallister]

@wayne-o the first thing I notice is your key in Ocelot.json is FrontendBff and in your ConfigureSonatribeIdentity method it is SonatribeFrontendBff. But Ocelot should not start up if you specify a key in the config and it doesn't exist in the container so I assume this is just a mistake.

I just want to clarify that you are expecting in your downstream service to be able to look at the identity in a controller and see the claims?

If this is the case the only way to do this is pass the authorization header to the downstream service and have it parse the token and perform the usual authentication etc so Ocelot isn't really involved unless it isn't forwarding the header!

Or....Ocelot allows you to add values from claims as headers or query string and forward them to the downstream service see the docs here please note the claims to claims transformation is just for a use case where you have a claim and want to transform it for another purpose in Ocelot so that won't do anything.

Does that help?

[wayne-o]

So, my downstream controllers need to know the identity of the user making the request. How do I pass the claims along? Would this mean removing the auth stuff from the BFF?

The key was a mistake :p

[TomPallister]

You don't really pass the claims along, they are lifted out of the bearer token or whatever mechanism asp.net is configured to use for authentication / authorization. If you pass a bearer token to a service and that service has a controller with authorize attribute over it and you register some authentication provider the claims should be available in the controller. I would suggest reading all of this before going any further.

[wayne-o]

Hmmm... that’s the setup I have... in fact I’ve replaced my hand coded gateway with Ocelot and the only auth related part I changed was the key. I’ll dig some more

[wayne-o]

Ahhhhhhh was a typo in my audiences!

Sorry for the noise :)

[TomPallister]

all good :)