ASP.Net Core 2.0 смешанная аутентификация JWT и аутентификация Windows не принимает учетные данные - PullRequest
0 голосов
/ 27 июня 2018

Я создал API в asp.net core 2.0, где я использую смешанный режим аутентификации. Для некоторых контроллеров JWT и для некоторых используется проверка подлинности Windows.

У меня нет проблем с контроллерами, которые авторизуются с помощью JWT. Но для контроллеров, где я хочу использовать проверку подлинности Windows, мне неопределенно предлагается диалоговое окно с именем пользователя и паролем Chrome.

Вот мой пример кода контроллера, где я хочу использовать аутентификацию Windows вместо JWT.

[Route("api/[controller]")]
[Authorize(AuthenticationSchemes = "Windows")]
public class TestController : Controller
{
    [HttpPost("processUpload")]
    public async Task<IActionResult> ProcessUploadAsync(UploadFileModel uploadFileModel)
    {

    }
}

Мой код настройки служб

public void ConfigureServices(IServiceCollection services)
{
     services.AddAuthentication(options =>
     {
        options.DefaultAuthenticateScheme = IISDefaults.AuthenticationScheme;
        options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
     })
     .AddJwtBearer("Bearer", options =>
     {
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateAudience = false,       
            ValidateIssuer = false,  
            ValidateIssuerSigningKey = true,
            IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("blahblahKey")),
            ValidateLifetime = true, //validate the expiration and not before values in the token
            ClockSkew = TimeSpan.FromMinutes(5) //5 minute tolerance for the expiration date
        };
     });

     // let only my api users to be able to call 
     services.AddAuthorization(auth =>
     {
        auth.AddPolicy("Bearer", new AuthorizationPolicyBuilder()
            .AddAuthenticationSchemes(JwtBearerDefaults.AuthenticationScheme‌​)
            .RequireClaim(ClaimTypes.Name, "MyApiUser").Build());
     });

     services.AddMvc();
}

Мой метод настройки.

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseCors("CorsPolicy");

    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    app.UseAuthentication(); //needs to be up in the pipeline, before MVC
    app.UseMvc();
}

Ценю ваши предложения и помощь в этом.

Обновление: до сих пор я отлаживал свой код в Chrome. Но когда я использовал IE 11, приведенный выше код работает без каких-либо проблем.

Может ли это быть проблема с CORS для Chrome, где возникает предпечатная проверка?

Спасибо

Ответы [ 2 ]

0 голосов
/ 27 июня 2018

Вы должны убедиться, что вы НЕ устанавливаете Authorization: Bearer <JWT_token> HTTP-заголовок при попытке использовать Windows Auth. Ключевым моментом здесь является то, как на самом деле работает Windows Auth. Давайте посмотрим, как это работает с браузером, например.

Давайте назовем это "нормальным потоком":

  1. Вы переходите на http://example.com/api/resource в своем браузере;
  2. Ваш браузер отправляет HTTP-запрос GET на http://example.com/api/resource без каких-либо Authorization HTTP-заголовков (пока анонимный запрос);
  3. Веб-сервер (или сам WebAPI) получает запрос, обнаруживает отсутствие заголовка Authorization и отвечает кодом состояния 401 Not Authorized с помощью WWW-Authenticate: NTLM,Negotiate HTTP Заголовок настроен ( «Уходите, анонимный доступ отсутствует. Приветствуются только парни из« NTLM »или« Переговоры »!» );
  4. Браузер получает ответ 401, обнаруживает, что запрос был анонимным, просматривает заголовок WWW-Authenticate и мгновенно повторяет запрос, теперь с Authorization: NTLM <NTLM_token> HTTP-заголовком ( «Хорошо, успокойтесь, мистер веб-сервер! Вот мой токен NTLM.» );
  5. Сервер получает второй запрос, находит токен NTLM в заголовке Authorization, проверяет его и выполняет запрос ( "Хорошо, вы можете передать. Вот ваш ресурс." ) .

Все немного меняется, когда вы изначально устанавливаете заголовок Authorization на какое-то значение:

  1. Ваш JS требует http://example.com/api/resource с авторизацией JWT;
  2. Ваш браузер отправляет запрос HTTP GET на http://example.com/api/resource с Authorization: Bearer <JWT_token> Заголовок HTTP сейчас;
  3. Веб-сервер (или сам WebAPI) получает запрос, обнаруживает, что существует заголовок Authorization со схемой аутентификации "Носитель", и снова отвечает кодом состояния 401 Not Authorized с WWW-Authenticate: NTLM,Negotiate Заголовок HTTP настроен ( "Уходите, мы не знаем, кто эти парни" на предъявителя ", но они нам не нравятся. Добро пожаловать только парням" NTLM "или" Переговоры "!" «);
  4. Браузер получает ответ 401, узнает, что запрос был авторизован, и решает, что этот токен неверен. Но поскольку вы на самом деле устанавливаете заголовок Authorization, это означает, что у вас на самом деле есть некоторые учетные данные. И поэтому он запрашивает эти учетные данные в этом диалоговом окне.
0 голосов
/ 27 июня 2018

Спасибо @ vasily.sib. Вы правы, мой JWTIterceptor добавляет JWTToken к заголовкам. Когда я прокомментировал это и протестировал, это сработало. Спасибо огромное за то, что избавили меня от 2 дней боли, чтобы разобраться в проблеме. Вы чемпион.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...