Включить проверку подлинности Windows и анонимную аутентификацию в приложении ASP.NET Core.

Я знаю, что это было задано много раз раньше, но, к сожалению, не о веб-приложениях ASP.NET Core, просто классических веб-приложениях ASP.NET. Все ответы, которые я нашел в Интернете, не помогают мне, потому что конфигурация IIS для приложений ASP.NET Core отличается от классического ASP.NET. Например, ASP.NET Core использует прокси-сервер Kestrel, поэтому многие из конфигураций, относящихся к ASP.NET, не относятся к ASP.NET Core. Я в основном пробовал все, что мог найти в Интернете, но никто не помог мне. Я прошу, чтобы это было так же просто, как включение анонимных и оконных аутентификаций в приложение в IIS, и что это так, но я думаю, что это будет работать больше, чем это.

Какова процедура включения обеих этих аутентификаций в одно основное веб-приложение asp.net?

Ответ 1

IIS будет действовать как обратный прокси-сервер и будет отвечать за настройку и передачу в Kestrel идентификатора пользователя Windows. Итак, сначала настройте IIS, чтобы разрешить как Windows, так и анонимную аутентификацию:

Затем вам нужно изменить свой web.config, чтобы попросить IIS передать идентификатор Windows (в случае его обнаружения) в ваше основное приложение ASP.NET: fooobar.com/questions/1669386/...

На данный момент, если вы создаете действие контроллера с атрибутом "[Авторизовать]", HttpContext.User.Identity.Name; должен иметь значение идентификатора Windows, используемого вашим клиентом. Я ответил на нечто подобное: проверка подлинности NTLM по определенному маршруту в ASP.NET Core

Хорошо, что стандартное действие контроллера будет по-прежнему работать, если ваш клиент не пройдет через токен идентификации Windows, а защищенный (с использованием [Авторизовать] тег) не удастся.

PS: Мне нравится использовать curl.exe в подробном режиме, чтобы увидеть, что происходит с точки зрения протокола авторизации (протокол ведения переговоров, токены NTLM...)

Ответ 2

У меня есть похожий сценарий для приложения ASP.NET Core 2.0 (используйте проверку подлинности Windows во всем приложении, за исключением одного контроллера), и объяснения Daboul было недостаточно.

Мне пришлось настроить пользовательское промежуточное ПО, как указано здесь, поскольку анонимность имеет приоритет.

Промежуточное программное обеспечение

public class NtlmAndAnonymousSetupMiddleware
{
    private readonly RequestDelegate next;

    public NtlmAndAnonymousSetupMiddleware(RequestDelegate next)
    {
        this.next = next;
    }

    public async Task Invoke(HttpContext context)
    {
        if (context.User.Identity.IsAuthenticated || context.Request.Path.ToString().StartsWith("/Anonymous"))
        {
            await next(context);
            return;
        }

        await context.ChallengeAsync("Windows");
    }

}

и его использование в Startup.cs:

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
    app.UseMiddleware<NtlmAndAnonymousSetupMiddleware>();

    // other code here
}

Таким образом, промежуточное программное обеспечение принимает анонимные запросы только для AnonymousController и создает проблему, если не предоставлена информация об аутентификации Windows.

Анонимный контролер

Поскольку промежуточное программное обеспечение делает различие между тем, что является анонимным и требует аутентификации, это будет выглядеть как любой обычный контроллер:

[Route("Anonymous")]
public class AnonymousController : Controller
{
    [HttpGet("Echo")]
    public string Echo(string data)
    {
        return data;
    }
}

тесты

(все сделано на машине с Windows)

Chrome + доступ к неанонимному действию контроллера => работает нормально (оба @User.Identity.Name и @Context.User.Identity.Name возвращают правильного пользователя
Chrome + анонимное действие => работает напрямую
Firefox (который напрямую не передает билет NTLM из ОС) + неанонимный => модал запрашивает user/pass =>, если предоставлен правильно, он работает нормально
Firefox + анонимное действие => работает напрямую