ASP.NET Core 2.0 HttpSys Windows Authentication fails with Authorize attribute (InvalidOperationException: No authenticationScheme was specified)

Question

I am trying to migrate an ASP.NET Core 1.1 application to ASP.NET Core 2.0.

The application is fairly simple and involves the following:

• Hosted on HttpSys (formerly WebListener)
• Using Windows authentication: options.Authentication.Schemes = AuthenticationSchemes.NTLM
• Allowing anonymous authentication: options.Authentication.AllowAnonymous = true (because there are some controllers that do not require authentication)
• Controllers that require authentication are decorated with the [Authorize] attribute.

The project compiles and starts up just fine. It also serves actions of controllers that do not require authentication.

However, as soon as I hit a controller with the [Authorize] attribute, I get the following exception:

System.InvalidOperationException: No authenticationScheme was specified,
and there was no DefaultChallengeScheme found.
   at Microsoft.AspNetCore.Authentication.AuthenticationService.<ChallengeAsync>d__11.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Mvc.ChallengeResult.<ExecuteResultAsync>d__14.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.<InvokeResultAsync>d__19.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.<InvokeFilterPipelineAsync>d__17.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.<InvokeAsync>d__15.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Builder.RouterMiddleware.<Invoke>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.<Invoke>d__7.MoveNext()

I started fiddling around with the project templates and noticed that I could reproduce this easily using the standard template ASP.NET Core Web Application (Model-View-Controller) with Windows Authentication.

The Program.cs file was changed as follows:

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseHttpSys(options =>
            {
                options.Authentication.Schemes = AuthenticationSchemes.NTLM;
                options.Authentication.AllowAnonymous = true;
                options.MaxConnections = 100;
                options.MaxRequestBodySize = 30000000;
                options.UrlPrefixes.Add("http://localhost:5000");
            })
            .UseStartup<Startup>()
            .Build();

This comes straight from the HttpSys documentation. Also I added the [Authorize] attribute to the HomeController class. Now, it will produce exactly the same exception as shown.

I found some related Stack Overflow posts (here, here and here), but none of them deals with plain Windows Authentication (and the answers do not seem to generalize).

Answer 1

While writing up the post, I remembered coming across this subsection of the migration guide. It says to add

services.AddAuthentication(Microsoft.AspNetCore.Server.IISIntegration.IISDefaults.AuthenticationScheme);

to the ConfigureServices function.

I initially thought that this wouldn't apply to HttpSys, given the full name of the constant (especially the IISIntegration threw me off). Moreover, as of this writing, the HttpSys documentation completely fails to mention this.

For those targeting the full .NET Framework, this requires installing the Microsoft.AspNetCore.Authentication NuGet Package.

EDIT

As Tratcher points out, there is a similar constant from the HttpSys namespace you should rather use:

Microsoft.AspNetCore.Server.HttpSys.HttpSysDefaults.AuthenticationScheme

Answer 2

Andreas' answer got me on the right path but this is what worked for me:

Added package reference to Microsoft.AspNetCore.Authentication

and then for Startup.cs

using Microsoft.AspNetCore.Server.IISIntegration;

public void ConfigureServices(IServiceCollection services)
{
    ...
    services.AddAuthentication(IISDefaults.AuthenticationScheme);
    ...
}

Answer 3

Another thing, if you've already added services.AddAuthentication(IISDefaults.AuthenticationScheme); make sure to turn on an authentication type (windows, forms) in IIS under the app → authentication.

Mine were all disabled and was getting this error even with the code in place.