Can't get authorization with NTLM and IIS Express to work

[afroewis]

Hello,

I spent a lot of time on this issue and I don't seem to find a solution. I'm hosting my app using IIS Express and I want to use NTLM authentication, using my windows user. I followed the guide Introducing ASP.NET Core Authorization support and modernization of legacy WCF Authentication and Authorization APis. This is my server code.

internal class Program {
    private static void Main(string[] args) {
        var builder = WebApplication.CreateBuilder(args);

        builder.Services
            .AddServiceModelServices()
            .AddServiceModelMetadata()
            .AddSingleton<IServiceBehavior, UseRequestHeadersForMetadataAddressBehavior>();


        builder.Logging.AddConsole();
        builder.Logging.AddDebug();

        builder.Services.AddScoped<MyService>();
        builder.Services.AddHttpContextAccessor();

        builder.Services.AddAuthentication(IISDefaults.AuthenticationScheme);
       
        builder.Services.AddAuthorization(options => {
            options.AddPolicy("Deny", p => {
                p.RequireAssertion(_ => false).Build();
            });
        });

        var app = builder.Build();

        app.UseServiceModel(builder => {
            builder.AddService<MyService>(serviceOptions => {
            });
            var ep = builder.AddServiceEndpoint<MyService, IMyService>(
                new BasicHttpBinding {
                    Security = new BasicHttpSecurity {
                        Mode = BasicHttpSecurityMode.TransportCredentialOnly,
                        Transport = new HttpTransportSecurity {
                            ClientCredentialType = HttpClientCredentialType.InheritedFromHost,
                            AlwaysUseAuthorizationPolicySupport = true
                        }
                    }
                },
                "/basichttp"
            );

        });
        app.UseAuthentication();
        app.UseAuthorization();

        // Enable ?wsdl
        var smb = app.Services.GetRequiredService<ServiceMetadataBehavior>();
        smb.HttpGetEnabled = true;
        smb.HttpsGetEnabled = true;

        // Normal HTTP GET interface - this one works. 
        app.MapGet("/foo", (HttpContext ctx) => new {
            user = ctx.User?.Identity?.Name,
            authenticated = ctx.User?.Identity?.IsAuthenticated ?? false
        }).RequireAuthorization("Deny");

        app.Run();
    }

And my CoreWCF service:

[ServiceBehavior(Namespace = "http://localhost:52210")]
public class MyService : IMyService {

[Authorize(Policy = "Deny")]
public string CheckAccess(string testString) {
    var user = http.HttpContext.User;
    return testString;
}

And the interface:

[ServiceContract(Namespace = "http://localhost:52210")]
public interface IMyService {

[OperationContract]
string CheckAccess(string testString);
}

This policy should deny all requests. However, I'm able to call the CheckAccess method and I get a response with status code 200.

For the "normal" Endpoint, GET /foo, the policy is applied and it returns 401.

Is my scenario not supported? Or is there something wrong in my code, or maybe even a conceptual misunderstanding from my side?

[mconnew]

Looking at what you pasted, everything looks correct to me. I haven't tested this on IIS Express, but there's nothing inherent with IIS Express which would get in the way. We call into asp.net core api's to do the work and are as agnostic to the HTTP implementation as we can be. All that to say, I would expect this to work.

There are two pieces to this and I want to narrow down exactly which piece isn't working. Is the authentication piece working? In CheckAccess, is the user populated?

The code which enforces the authorization is in CoreWCF.Dispatcher.AuthorizationBehavior.AuthorizePolicyAsync, can you set a breakpoint for that method and see if it's getting hit? If you want to step through the code to see what decisions it's making, this should be called from CoreWCF.Dispatcher.ImmutableDispatchRuntime.ProcessMessageAsync. The line that calls this is here. If you step through that code, you should be able to see what's missing in the decision making about allowing that operation to be called. We publish symbol packages to nuget so you should be able to enable downloading the source for CoreWCF. In VS Debugging options, you'll want to turn off "Enable Just My Code" and turn on "Enable Source Link Support". Once you know the state that's allowing the call to be made, let me know and I can try to help work it backwards to see either what's missing or where the bug is in CoreWCF.

[afroewis]

Hi @mconnew
I created a standalone repro project here: https://github.com/afroewis/corewcf-ntlm-auth-error.

I would be very thankful if you could look into it when you have time.

[mconnew]

I've taken a look and have made some progress. I think this is going to need a product change to support. When Windows auth is used, a different set of code is used and the ClaimsPrincipal is not being set on the SecurityContext. The list of identities is set though, which contains the ClaimsPrincipal. There is an extensibility point that can be used to fix this up, but we have a check to prevent you using that extensibility point as we didn't want you mixing classic WCF auth customization with the asp.net core way of doing things. I need to give this some thought, and also see how the ClaimsPrincipal is being set on .NET Framework as I'm not seeing it. The code we implemented does look equivalent, so it's happening somewhere else, but I can't see where, so I'll need to fire up the debugger to work out where it's happening on .NET Framework.

[afroewis]

Thanks for your interesting reply. Good luck with the debugging. It would be very nice if you could keep me posted about this topic. If you want, I can create an issue to track this?

[mconnew]

Please do create an issue to track this.

[afroewis]

Here's the issue: #1648