Hey there, I get your frustration—testing Windows auth-dependent APIs in Azure without ADFS or Owin feels tricky, but there are workable ways to simulate a single user for all test requests. Let's break down two reliable approaches tailored to your scenario:

1. Custom Authorization Filter to Simulate User Identity #

Since you can't rely on Owin and need to keep [Authorize(Roles)] checks working, a custom authorization filter lets you directly inject a simulated Windows-style user identity into every request. This skips the need for actual NTLM handshake entirely.

Step-by-Step Implementation: #

• Create a custom filter that inherits from AuthorizationFilterAttribute:

public class SimulateWindowsUserAttribute : AuthorizationFilterAttribute
{
    public override void OnAuthorization(HttpActionContext actionContext)
    {
        // Define your simulated user and roles (adjust to your needs)
        var userName = "DOMAIN\\TestAdmin";
        var roles = new[] { "Administrator" };

        // Build a generic principal with the simulated identity
        var identity = new GenericIdentity(userName, "Windows");
        var principal = new GenericPrincipal(identity, roles);

        // Assign the principal to both the current thread and HTTP context
        Thread.CurrentPrincipal = principal;
        if (HttpContext.Current != null)
        {
            HttpContext.Current.User = principal;
        }

        base.OnAuthorization(actionContext);
    }
}

• Register this filter globally in your WebApiConfig so it applies to all requests:

public static class WebApiConfig
{
    public static void Register(HttpConfiguration config)
    {
        // Add other WebAPI configs first
        config.Routes.MapHttpRoute(
            name: "DefaultApi",
            routeTemplate: "api/{controller}/{id}",
            defaults: new { id = RouteParameter.Optional }
        );

        // Register the simulation filter (only for TEST environment!)
#if DEBUG
        config.Filters.Add(new SimulateWindowsUserAttribute());
#endif
    }
}

Important: Wrap the filter registration in a #if DEBUG directive to ensure this never makes it to production—this is strictly for testing purposes.

2. Modified Message Handler to Inject User Identity #

Your initial message handler idea was on the right track, but instead of trying to replicate NTLM headers, you can directly set the user identity in the handler before the request reaches the authorization checks.

Updated Handler Code: #

public static class WebApiConfig
{
    public static void Register(HttpConfiguration config)
    {
        // Other WebAPI registrations here
        config.MessageHandlers.Add(new SimulateUserHandler());
    }
}

class SimulateUserHandler : DelegatingHandler
{
    protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
        // Simulate Windows user identity
        var userName = "DOMAIN\\TestAdmin";
        var roles = new[] { "Administrator" };
        var identity = new GenericIdentity(userName, "Windows");
        var principal = new GenericPrincipal(identity, roles);

        // Attach the principal to the request properties
        request.Properties["MS_UserPrincipal"] = principal;
        // Also set thread/context principal for broader compatibility
        Thread.CurrentPrincipal = principal;
        HttpContext.Current?.User = principal;

        return base.SendAsync(request, cancellationToken);
    }
}

Why This Works #

• When you disable authentication mode="None", the framework still checks for a valid principal when [Authorize] is applied. By manually constructing a GenericPrincipal with the required roles, you satisfy those checks without needing actual Windows auth.
• Both approaches avoid the complexity of mimicking NTLM's four-way handshake—since you only need to test role-based access, simulating the identity directly is far simpler.

Key Notes #

• Only use these in test environments: Never deploy this to production, as it bypasses actual security checks.
• Adjust the userName and roles values to match your application's requirements (e.g., use your test admin's role).
• If you need to test different users occasionally, you could modify the filter/handler to read a query parameter or header to switch identities (but keep it locked to test environments).

内容的提问来源于stack exchange，提问作者Ogglas