Automatic Cookies challenge overridden by Windows Authentication since 1.1.0

[c-s-n]

Background

I use the IISIntegration with IISOptions.AutomaticAuthentication = true and IISOptions.ForwardWindowsAuthentication = true. Furthermore I use the Cookie Authentication (without Identity) with CookieAuthenticationOptions.AutomaticAuthenticate = true and CookieAuthenticationOptions.AutomaticChallenge = true. This should be fine in combination (see e.g. also this comment). Since ASP.NET Core 1.1.0, most likely down to #930 and #982, this doesn't challenge any more as expected.

Functional impact

When a not yet authenticated user accesses a controller with an authorization policy applied that requires an authenticated user, but no explicit authentication schemes, since 1.1.0 the Windows Authentication always ignores the challenge from the Cookies Authentication. Thus a 401 is returned instead of the user being redirected to the login page.

Minimal repro steps

I haven't setup yet a small project for reproduction, but in our project that used to work like expected (see below) with ASP.NET Core 1.0.0/1.0.1, and which was now upgraded to 1.1.0 (all dependencies and tools), the expected and actual result can be switched by changing only the "Microsoft.AspNetCore.Authentication.Cookies" package (with its dependent "Microsoft.AspNetCore.Authentication") from/to version 1.1.0 resp. 1.0.0.

Expected result

Following - actually expected behavior - used to happen pre 1.1.0:

• Authorization failed for user: (null).
• Executing ChallengeResult with authentication schemes ().
• AuthenticationScheme: Cookies was challenged.
• CookieAuthenticationEvents.OnRedirectToLogin gets called once and redirects to the CookieAuthenticationOptions.LoginPath
• Response is 302
• Login page is shown

Actual result

What does happen since 1.1.0:

• Authorization failed for user: (null).
• Executing ChallengeResult with authentication schemes ().
• AuthenticationScheme: Cookies was challenged.
• CookieAuthenticationEvents.OnRedirectToLogin gets called and calls context.Response.Redirect
• Response is 401 though
• Same page/path is requested again by the browser
• Above sequence happens again!
• After 401 is returned the second time, the browser's Windows Auth popup is shown

[Tratcher]

Needs investigation. We have tests for this scenario in MusicStore and nobody else has reported this yet. Something this fundamental would have broken anyone using Cookies on IIS.

Please share your project.json and Startup.cs, or a whole repro app pushed to github.

[c-s-n]

Essential information I actually missed to mention in the issue is that we use a hybrid approach of self-hosting and IIS-hosting, selectable via a configuration option. In the one case the standalone WebListener is used, in the other IISIntegration with Kestrel.

The issue at least occured in the self-hosting/WebListener scenario - and maybe I mixed it up and it didn't even occur in the IIS-hosting... Sorry, need to recheck that (would take me some more time, as stuff has changed in our environment)

The WebListener settings are

options.ListenerSettings.Authentication.Schemes = Microsoft.Net.Http.Server.AuthenticationSchemes.NTLM;
options.ListenerSettings.Authentication.AllowAnonymous = true;

As the WebListener's AuthenticationHandler does not have any options regarding AutomaticAuthentication, it always runs and thus causes this changed behavior, right?

How would we be able to influence it - except explicitly specifying AuthenticationSchemes?

[Tratcher]

Interesting, WebListener Auth + Cookies is probobly not a scenario we have test coverage for. You're right, WebListener does not have a switch to disable AutomaticChallenge. If you want to use the two together you'd have to disable automatic challenge on CookieAuth only challenge it by name. Though I have to wonder why you have windows auth and cookie auth enabled together.

I'm going to move this issue to WebListener.

[Tratcher]

This issue was moved to aspnet/HttpSysServer#284