Как реализовать базовый API-контроллер ASP. Net, который допускает аутентификацию токена на предъявителя ИЛИ аутентификацию API-ключа - PullRequest
Новая
       11

Как реализовать базовый API-контроллер ASP. Net, который допускает аутентификацию токена на предъявителя ИЛИ аутентификацию API-ключа

0 голосов
/ 19 апреля 2020

Я хотел бы создать веб-API, к которому можно получить доступ, используя токен Bearer ИЛИ простой ключ API, для ключа API см. https://gist.github.com/GeorgDangl/87db6426962bf50933b093e0952570e1. Я понимаю, как реализовать оба подхода по отдельности, однако мой вопрос заключается в том, как применить атрибут Authorize к моему классу контроллера, который позволяет использовать любой из этих методов. Насколько я понимаю, атрибуты Authorize накапливаются ie, если я применяю оба, это будет означать, что для запроса требуется медвежий токен И ключ API. Я хочу, чтобы он работал так, чтобы, если запрос имел маркер Bearer ИЛИ ключ API, он успешно аутентифицировался.

1 Ответ

1 голос
/ 19 апреля 2020

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

Когда происходит авторизация, logi c, используемый как промежуточным ПО авторизации, так и фильтром авторизации, выглядит следующим образом (немного упрощенно): 

var authenticateResult = await policyEvaluator.AuthenticateAsync(policy, httpContext);

if (HasAllowAnonymous(context))
    return;

var authorizeResult = await policyEvaluator.AuthorizeAsync(
        policy, authenticateResult, httpContext, context);

if (authorizeResult.Challenged)
    // trigger Challenge (401)
else if (authorizeResult.Forbidden)
    // trigger Forbid (403)

Во-первых, оценщик политики запрашивается проверка подлинности пользователя для политики, а затем возвращенный результат используется для авторизации пользователя. Аутентификация в оценщике политики работает следующим образом:

  1. Для каждого AuthenticationScheme в политике попытайтесь аутентифицировать пользователя.
  2. Для всех успешных аутентификаций, объединить свои пользовательские принципалы в один принципал.
  3. Проверка подлинности политики прошла успешно, если был создан принципал, т.е. не менее одна проверка подлинности прошла успешно.

Итак, в В этом процессе все схемы аутентификации будут использоваться для аутентификации пользователя. Они могут быть аутентифицированы только по одной схеме, например, Bearer и ApiKey, или они могут даже аутентифицироваться по нескольким схемам.

Затем оценщик политики авторизует пользователя, с помощью просто позвонив в службу авторизации на авторизацию пользователя в соответствии с политикой требований . И требования политики не содержат схему аутентификации, с которой вы ее построили.

Итак, подведем итог: Нет, схемы аутентификации, которые вы передаете AuthorizationPolicyBuilder, используются только для аутентификации, но не для авторизации, и все они будут использоваться для потенциальной аутентификации пользователя.

...