Automatic Cookies challenge overridden by Windows Authentication since 1.1.0

[Tratcher]

From @c-s-n on December 1, 2016 10:31

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

Copied from original issue: aspnet/Security#1057

[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.

[Tratcher]

From @c-s-n on December 7, 2016 12:40

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.

[c-s-n]

Thanks for moving it appropriately.

Apparently we have the need to login a user via Windows or Forms Auth. There we have two ways of achieving this, depending on the customer's requirements:

• Allowing the user to login with Windows Auth, not setting a cookie at all and populating missing claims on every request using a middleware. The controllers require an authenticated user and both Cookies and Windows Authentication are set to run automatically. Or alternatively, both Cookies and NTLM schemes are specified explicitly.
  Note: This requires the browser (and web server) to persist the authentication (underlying TCP session). Only works reliably in Microsoft browsers.
• Allowing the user to login with Windows Auth, directly populating the missing claims and setting a cookie with session lifetime. Only the controller that triggers the Windows Authentication challenge has the NTLM scheme and all others just have cookies scheme.

[Tratcher]

See aspnet/Security#1062 for general guidance on mixing auth types

[Tratcher]

This should be addressed by #325

[muratg]

@HaoK assigning to you, as we think your mega-auth-change will cover this.

[HaoK]

Host changes for Auth 2.0 should go in this week (but for preview 2)

[HaoK]

PRs: #354
aspnet/IISIntegration#338

[HaoK]

merged bff13c7