ASP.NET core 2.2: каково ожидаемое поведение ChallengeResult, когда настроено несколько схем проверки подлинности?

Мы пытаемся понять, какова ожидаемая обработка ChallengeResult, когда зарегистрировано несколько схем аутентификации.

Нам нужно обработать такой сценарий, потому что у нас есть приложение ASP.NET core 2.2, предоставляющее некоторые методы действий (мы используем промежуточное программное обеспечение MVC), которые должны использоваться SPA angularjs, который полагается на аутентификацию файлов cookie, и некоторые сторонние приложения, которые используют аутентификацию. механизм, основанный на заголовке HTTP-запроса авторизации. Обратите внимание, что вовлеченные методы действия одинаковы для обоих пользователей означает, что каждый из них должен разрешать аутентификацию с использованием как файла cookie, так и пользовательской схемы на основе заголовка HTTP-запроса авторизации. Мы знаем, что, вероятно, это не оптимальный дизайн, но мы не можем изменить общую архитектуру.

Эта документация, похоже, подтверждает, что то, чего мы хотели бы достичь, вполне возможно с использованием ядра ASP.NET 2.2. К сожалению, аутентификация cookie, используемая приложением пользовательского интерфейса, и пользовательская аутентификация, используемая третьими лицами, должны вести себя по-разному в случае проблемы аутентификации, и их ожидаемое поведение несовместимо друг с другом: приложение пользовательского интерфейса должно перенаправлять пользователя на форму входа. , в то время как стороннее приложение ожидает необработанный ответ с кодом состояния 401. Документация, указанная выше, не дает четкого объяснения обработки ChallengeResult, поэтому мы решили поэкспериментировать с тестовым приложением.

Мы создали два поддельных обработчика аутентификации:

public class FooAuthenticationHandler : IAuthenticationHandler
  {
    private HttpContext _context;

    public Task<AuthenticateResult> AuthenticateAsync()
    {
      return Task.FromResult(AuthenticateResult.Fail("Foo failed"));
    }

    public Task ChallengeAsync(AuthenticationProperties properties)
    {
      _context.Response.StatusCode = StatusCodes.Status403Forbidden;
      return Task.CompletedTask;
    }

    public Task ForbidAsync(AuthenticationProperties properties)
    {
      return Task.CompletedTask;
    }

    public Task InitializeAsync(AuthenticationScheme scheme, HttpContext context)
    {
      _context = context;
      return Task.CompletedTask;
    }
  }

public class BarAuthenticationHandler : IAuthenticationHandler
  {
    private HttpContext _context;

    public Task<AuthenticateResult> AuthenticateAsync()
    {
      return Task.FromResult(AuthenticateResult.Fail("Bar failed"));
    }

    public Task ChallengeAsync(AuthenticationProperties properties)
    {
      _context.Response.StatusCode = StatusCodes.Status500InternalServerError;
      return Task.CompletedTask;
    }

    public Task ForbidAsync(AuthenticationProperties properties)
    {
      return Task.CompletedTask;
    }

    public Task InitializeAsync(AuthenticationScheme scheme, HttpContext context)
    {
      _context = context;
      return Task.CompletedTask;
    }
  }

Мы зарегистрировали схемы аутентификации внутри метода ConfigureServices следующим образом:

public void ConfigureServices(IServiceCollection services)
    {
      services
        .AddMvc()
        .SetCompatibilityVersion(CompatibilityVersion.Version_2_2);

      services.AddAuthentication(options => 
      {
        options.DefaultChallengeScheme = "Bar";
        options.AddScheme<FooAuthenticationHandler>("Foo", "Foo scheme");
        options.AddScheme<BarAuthenticationHandler>("Bar", "Bar scheme");
      });
    }

Это наш конвейер промежуточного программного обеспечения:

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
    {
      if (env.IsDevelopment())
      {
        app.UseDeveloperExceptionPage();
      }
      else
      {
        // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
        app.UseHsts();
      }

      app.UseHttpsRedirection();

      app.UseAuthentication();

      app.UseMvc();
    }

и, наконец, мы создали контроллер с методом действия, требующим аутентификации:

[Route("api/[controller]")]
  [ApiController]
  public class ValuesController : ControllerBase
  {
    // GET api/values/5
    [HttpGet("{id}")]
    [Authorize(AuthenticationSchemes = "Foo,Bar")]
    public ActionResult<string> Get(int id)
    {
      return "value";
    }
  }

Мы заметили, что:

• и FooAuthenticationHandler, и BarAuthenticationHandler вызываются для обработки ChallengeResult
• порядок FooAuthenticationHandler перед BarAuthenticationHandler и зависит от атрибута Authorize (если вы поменяете схемы аутентификации внутри атрибута Authorize, то сначала вызывается BarAuthenticationHandler)
• вызывающая сторона получает необработанный ответ с кодом состояния 500, но это зависит только от порядка, в котором вызываются обработчики авторизации.
• вызов options.DefaultChallengeScheme = "Bar"; имеет значение если и только если внутри атрибута [Authorize] свойство AuthenticationSchemes имеет значение нет. Если вы это сделаете, будет вызван только BarAuthenticationHandler, а FooAuthenticationHandler никогда не получит шанс аутентифицировать запрос или обработать вызов аутентификации.

Итак, вопрос в основном таков: когда у вас есть такой сценарий, как вы должны обрабатывать возможную «несовместимость» различных схем аутентификации в отношении обработки ChallengeResult, поскольку они вызывают обе?

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

Спасибо за помощь !