AddHeadersToRequest with Claims[sub] and Claims[roles]

[jnormen]

Expected Behavior / New Feature

When pass this:

"AddHeadersToRequest": {
   "tenantId": "Claims[tenantId] > value",
    "caller": "Claims[sub] > value",
    "roles": "Claims[roles] > value"
}

with this token:

"sub": "8723c40a-0b57-4447-b1a5-d3c15f7ca9ea",
"typ": "Bearer",
"roles": ["Admin","User"]

Expect to have 3 header values.

Actual Behavior / Motivation for New Feature

  "tenantId": "Claims[tenantId] > value",

This works no problem. If I type typ it also works. if I type other claims from token it all works.

But when I use sub it says: Cannot find a claim for key: sub errors found in ResponderMiddleware.

If roles, the same: Cannot find a claim for key: roles errors found in ResponderMiddleware.

This they are all there in the token. And I can use most of the other claim names.

Is sub and roles somewhat reserved or ignored?

Steps to Reproduce the Problem

1. add:

"AddHeadersToRequest": {
  "tenantId": "Claims[tenantId] > value",
  "caller": "Claims[sub] > value"
}

"AuthenticationOptions": {
  "AuthenticationProviderKey": "myKey",
  "AllowedScopes": []
}

3. call API with valid bearer token.

[jnormen]

I see now that JwtBearer settings in ASP .Net with the Jwt Schema change sub and roles to namespaces like this: {http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier: 8723c40a-0b57-4447-b1a5-d3c15f7ca9ea}

so my sub I pass in is transformed to "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"

To fix this I need to do:
var claimValues = claims.Where(c => c.Type == ClaimTypes.NameIdentifier).Select(c => c.Value).ToArray();

in the ClaimsParser if key is sub.
Or use:
"caller" : "Claims[http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier]

[raman-m]

@jnormen
Do you still see an issue or not? I don't!
We can discuss it more, if you don't like your hacky fix... 😉

[jnormen]

This is long time ago and I do no use Ocelot any more.
2024 now :) 2019 was long time ago in software world :)

[raman-m]

I know, long time ago...
But it was your feature request, right? Or it uncovers a bug in Ocelot or in ASP.NET framework...
I guess the issue is still actual...

[EasyMilos]

Or you use
JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();
in Startup and claims are back normal.

[raman-m]

Well... Could we create complete list of reserved claim names somehow?
And how to detect wrong claim name during run-time?

[Navaladi2019]

if the claim name is nameid, it is not getting forwarded. On other names it is working fine

[raman-m]

Please, prove that fact by a link to ASP.NET official repository!