RouteClaimsRequirement conundrum

[PostImpatica]

Expected Behavior / New Feature

RouteClaimsRequirement should work with IdentityServer4 + AddJwtBearer
or
IdentityServer4 + Action should have token validated event

Actual Behavior

Currently, when using IdentityServer4 you have to choose whether you want to use multiple roles along with RouteClaimsRequirement, or if you want to be able to capture additional properties like the username for logging, but you can't do both.

Steps to Reproduce the Problem

If you use a scheme for IdentityServer4 with AddJwtBearer it does appear to work and I have the ability to listen to the token validation event so I can grab additional information for logging. Problem is, RouteClaimsRequirement doesn't work with roles. Here is the configuration of my scheme for this scenario:

services.AddAuthentication()
    .AddJwtBearer("IDP", jwtOptions =>
    {
    jwtOptions.Authority = $"{ Configuration["IDP:Authority"]}";
    jwtOptions.Audience = Configuration["IDP:Audience"];                     
    jwtOptions.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateIssuerSigningKey = true,
        ValidateIssuer = false
    };
    jwtOptions.Events = new JwtBearerEvents
    {
        OnAuthenticationFailed = context =>
        {
            return myRemoteFailure(context);
        },
        OnTokenValidated = context =>
        {
            // this is where I grab username for logging purposes
            return myIDPUserValidationLogic(context);
        }
    };
})

If you use a scheme for IdentityServer4 like the documentation suggests using Action, RouteClaimsRequirement now works with multiple roles no problem, but there is no way for me to listen to the token validation event. I need this so I can grab the username for logging purposes. Here is my other custom scheme:

var authenticationProviderKey = "IDP2";
        Action<IdentityServerAuthenticationOptions> isoptions = o =>
        {
            o.Authority = $"{ Configuration["IDP:Authority"]}";
            o.ApiName = Configuration["IDP:ClientId"];
            o.SupportedTokens = SupportedTokens.Both;
            o.ApiSecret = Configuration["IDP:Secret"];
            // how can I grab the username for logging?
        };
services.AddAuthentication()
.AddIdentityServerAuthentication(authenticationProviderKey, isoptions)

Specifications

• Version: 12.0.1
• Platform: .Net Core 2.1

[PostImpatica]

I can add the following to the bottom scheme shown above ("IDP2") but the events never get raised:

Action<IdentityServerAuthenticationOptions> isoptions = o =>
        {
            o.Authority = $"{ Configuration["IDP:Authority"]}";
            o.ApiName = Configuration["IDP:ClientId"];
            o.SupportedTokens = SupportedTokens.Both;
            o.ApiSecret = Configuration["IDP:Secret"];
            o.Events = new JwtBearerEvents
            {
                OnAuthenticationFailed = context =>
                {
                    return myRemoteFailure(context);
                },
                OnTokenValidated = context =>
                {
                    return myIDPUserValidationLogic(context);
                }

            };
        };

[raman-m]

Do you think that Ocelot is responsible for library object events in run-time?
Why do you think so?

[raman-m]

Hi Clay!

You've described rare user scenario.
Ocelot is not responsible for any user security models.

Also, Authorization Middleware can be overridden! Based on your user scenario, I would say, you need to override PreAuthorizationMiddleware with the following responsibilities:

• Analyze token roles or any other auth-properties including claims

---

Currently, when using IdentityServer4 you have to choose whether you want to use multiple roles along with RouteClaimsRequirement, or if you want to be able to capture additional properties like the username for logging, but you can't do both.

That's wrong! If you override Auth middlewares then "you will be able to capture additional properties like the username for logging".
Just start development of custom middleware and override Auth middlewares.
Hope it helps!

[raman-m]

Problem is, RouteClaimsRequirement doesn't work with roles.

LoL! Yes, because it processes claims, not roles!
Roles processor should have name like RouteRolesRequirement 😉
But this is not implemented for now.