[ASPNET Core 2.0]Authorization Policy ignoring Authentication

[blowdart]

From @allevyMS on April 11, 2018 17:10

I am trying to set up authentication and authorization but I am seeing unexpected behavior.
I am running an ASPNET Core 2.0 app on windows (tried this on windows 10 and in a docker container with the following image 2.0.6-sdk-2.1.104-nanoserver-sac2016) and I have my authentication and authorization set up like this:
using Nuget package: Microsoft.AspNetCore.All 2.0.0 and also tried with 2.0.6

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddAuthorization(options =>
        {
            options.AddPolicy("Test", policy =>
            {
                policy.Requirements.Add(new TestRequirement());
            });
        });

        services.AddSingleton<IAuthorizationHandler, TestAuthorizationHandler>();

        services.AddMvc();

        services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
            .AddJwtBearer();

        services.AddSingleton<IConfigureOptions<JwtBearerOptions>>(sp =>
        {
            return new ConfigureNamedOptions<JwtBearerOptions>(
                JwtBearerDefaults.AuthenticationScheme,
                options =>
                {
                    options.TokenValidationParameters = new TokenValidationParameters
                    {
                        RequireSignedTokens = true,
                        ValidateIssuer = false,
                        ValidateAudience = false,
                        ValidateLifetime = true,
                        IssuerSigningKey = rsaSecurityKey
                    };
                });
        });
    }

    public void Configure(IServiceProvider sp, IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
    {
        loggerFactory.AddConsole(Configuration.GetSection("Logging"));

        app.UseAuthentication();

        app.UseMvc();
    }

My requirement is empty and this is my authorization handler:

public class TestAuthorizationHandler : AuthorizationHandler<TestRequirement>
{
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context,
                                                   TestRequirement requirement)
    {
        context.Succeed(requirement);
        return Task.CompletedTask;
    }
}

My Controller get method:

    [Authorize(Policy = "Test")]
    [HttpGet]
    [Route("Data")]
    public async Task<string> GetDataAsync()
    {
        return await Task.FromResult("data");
    }

The unexpected behavior:

Authentication is always ignored for that controller method, my authorization handler and controller are always reached, even if I don't supply an Authentication header or supply an invalid token.

Expected behavior:

Authorization should use the supplied default scheme in AddAuthentication to challenge the Authentication and not allow these calls through unless Authentication was successful.

Workaround:

Add the default scheme directly to the policy and require the user to be authenticated

policy.AuthenticationSchemes.Add(JwtBearerDefaults.AuthenticationScheme);
policy.RequireAuthenticatedUser();

When these are added I see the behavior I expect.

Am I misunderstanding the expected flow? Is this the expected behavior and RequireAuthenticatedUser is needed explicitly to block unauthenticated requests to go through authorization?

Copied from original issue: #3046

[kevinchalet]

Am I misunderstanding the expected flow? Is this the expected behavior and RequireAuthenticatedUser is needed explicitly to block unauthenticated requests to go through authorization?

While not super convenient, it's the expected behavior (and it's a quite frequent question: https://stackoverflow.com/questions/49545706/adding-a-policy-based-authorization-skips-jwt-bearer-token-authentication-check/49545923#49545923).

In a better world (and IMHO), DenyAnonymousAuthorizationRequirement should always be added by default and RequireAuthenticatedUser() should be replaced by AllowAnonymousUser(). But hem... it's probably a breaking change 😅

[blowdart]

Oh heck, I moved it and never replied. As @PinpointTownes says it's expected, and yes it'd be a big breaking change, like major version number breaking change.

[kevinchalet]

@blowdart do you mind re-opening this thread and putting it in the 3.0.0 milestone so it has a chance to be discussed for the next major version?

[blowdart]

I can, but as it's turning things on its head, it's going to be a hard sell :)

[kevinchalet]

So, who can I bribe to make that happen? @DamianEdwards maybe?

The fact DenyAnonymousAuthorizationRequirement is not automatically added to new authorization policies (you have to explicitly call RequireAuthenticatedUser()) is a serious trap for too many people.

@DamianEdwards would you be opposed to changing that to make the default behavior more secure in 3.0?

[DamascenoRafael]

Does anyone know if the workaround no longer works on .NET Core 2.2.0?
I configured the policy as follows:

        public void ConfigureServices(IServiceCollection services)
        {
            // ...
            JWTExtension.AddJwtAuthentication(services, Configuration);
            // ...
            services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);
            // ...
            {
                options.AddPolicy("AdminRole", policy =>
                {
                    policy.AuthenticationSchemes.Add(CookieAuthenticationDefaults.AuthenticationScheme);
                    policy.RequireAuthenticatedUser();
                    policy.Requirements.Add(new UserRoleRequirement(ProfileEnum.Admin));
                });
            });
            // ...
        }

But the policy is always called before checking the existence and validity of JWT. In my case the token is validated through the Cookie so I put the corresponding schema.

My Configure(IApplicationBuilder app, IHostingEnvironment env) is as follows:

        public void Configure(IApplicationBuilder app, IHostingEnvironment env)
        {
            RewriteOptions options = new RewriteOptions().AddRewrite(@"^(?!(swagger|token|api|.+[.])).*", "/", skipRemainingRules: true);

            app.UseRewriter(options);
            
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }
            else
            {
                app.UseHsts();
            }

            string[] allowedAppUrls = Configuration["AllowedAppUrls"].Split(','); 
            app.UseCorsAllow(allowedAppUrls);
            app.UseMiddleware(typeof(ExceptionHandlerMiddleware));
            app.UseAuthentication();
            app.UseMiddleware(typeof(TokenExpirationMiddleware));
            app.UseMvc(routes =>
            {
                routes.MapRoute
                (
                    name: "default",
                    template: "api/{controller=Home}/{action=Index}/{id?}" 
                );
            });
            app.UseDefaultFiles();
            app.UseStaticFiles();

            app.ConfigSwagger();

            app.UseHttpsRedirection();
        }

[MichaelHudgins]

I too would like to know if this workaround is still supported. I am having the same effect where my authorization policy is checked even when there is an invalid jwt. I am working around by checking the user again in the authorization policy, but it would be better if the authorization policy was never called given the failure of the authentication.

[dominicusmento]

Does anyone know if the workaround no longer works on .NET Core 2.2.0?
I configured the policy as follows:

        public void ConfigureServices(IServiceCollection services)
        {
            // ...
            JWTExtension.AddJwtAuthentication(services, Configuration);
            // ...
            services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);
            // ...
            {
                options.AddPolicy("AdminRole", policy =>
                {
                    policy.AuthenticationSchemes.Add(CookieAuthenticationDefaults.AuthenticationScheme);
                    policy.RequireAuthenticatedUser();
                    policy.Requirements.Add(new UserRoleRequirement(ProfileEnum.Admin));
                });
            });
            // ...
        }

But the policy is always called before checking the existence and validity of JWT. In my case the token is validated through the Cookie so I put the corresponding schema.

My Configure(IApplicationBuilder app, IHostingEnvironment env) is as follows:

I've had a same problem. My workaround was that I put controller under default [Authorize] attribute and then every action has it's own policy [Authorize(Policy = "FullAccess")]. To me it wasn't such a big deal because I had only one controller which action's was under the same policy. RequireAuthenticatedUser and similar wasn't necessary.

[HaoK]

Can you guys share a simple repro app so we can take a closer look at the behavior changes you are seeing?

In regards to "I am having the same effect where my authorization policy is checked even when there is an invalid jwt.". This is by design, all of the authorization logic is run always, the presence or lack of the .RequireAuthenticatedUser() requirement doesn't short circuit the rest of the authorization checks. So if you want to hard block that, you do need to have logic inside of your handlers to no-op if there's no user

[allevyMS]

@HaoK I am experiencing the same regression mentioned above

.RequireAuthenticatedUser() used to in fact short circuit the flow and block the authorization if the user was not authentication, now it no longer seems to do that.

What is the function of 'RequireAuthenticatedUser()' if it doesn't enforce authentication?