ASP.NET Core 2.0 IAuthorizationService и просроченные токены-носители - PullRequest
0 голосов
/ 24 апреля 2018

Я работаю над приложением ASP.NET Core 2.0 с использованием токенов Bearer.Все, что касается токенов и аутентификации, работает / работает нормально.

Я только что реализовал другой процесс авторизации.Теперь вместо использования атрибута Authorize для применения политик я использую подход IAuthorizationService и DefaultAuthorizationPolicyProvider.

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

Я настраиваю токены-носители в Startup.cs следующим образом:

.AddJwtBearer(options =>
{
  options.TokenValidationParameters = tokenValidationParameters;
});

Параметры проверки создаются следующим образом:

return new TokenValidationParameters
{
  // The signing key must match!
  ValidateIssuerSigningKey = true,
  IssuerSigningKey = GetSymmetricSecurityKey(configuration),
  ValidateIssuer = true,
  ValidIssuer = configuration.GetSection("TokenAuthentication:Issuer").Value,
  ValidateAudience = true,
  ValidAudience = configuration.GetSection("TokenAuthentication:Audience").Value,
  ValidateLifetime = true,
  ClockSkew = TimeSpan.Zero // leave at zero, we validate expiry!
};

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

public static void AddAuthorisationPolicies(this IServiceCollection services)
{
  services.AddAuthorization();
  services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();
  services.AddTransient<IAuthorizationPolicyProvider, AuthorisationPolicyProvider>();
  services.AddTransient<IAuthorizationHandler, RoleClaimHandler>();
}

Это все работает, как и ожидалось.Теперь в моих контроллерах я могу внедрить экземпляр службы авторизации, например так:

public SyncController(IAuthorizationService auth)

Все мои требования и обработчики работают так, как ожидалось, и так далее.Теперь в контроллерах метода действия я могу сделать это:

var auth = await authz.AuthorizeAsync(User, "Administrator");
if (!auth.Succeeded)
{
  return Challenge();
}
...

Когда токен действителен, ClaimsPrinciple установлен правильно, то есть вызов AuthorizeAsync выполняется с действительным пользователем.

Я вижу, что не ожидал увидеть, что с маркером Bearer с истекшим сроком действия запрос все еще достигает методов действия, но с нулевым ClaimsPrinciple.

Я должен отсутствоватькакая-то настройка ключа где-то.Я не ожидал, что это произойдет, и нет никакого смысла вызывать AuthorizeAsync с нулевым пользователем.Строго говоря, это не открыло никакой дыры в безопасности, поскольку при нулевом пользователе вызов на AuthorizeAsync всегда будет неудачным, но это не особенно чисто, разумно или логично.

Как я могу предотвратить запросс токеном с истекшим сроком действия, чтобы пройти этот путь через конвейер запросов?

Это на самом деле ожидаемое поведение, или мне нужно откатить свой собственный процесс (больше Middleware?) для этой проверки срока действия теперь, когда яв обход встроенной логики AuthorizeAttribute?

Я ожидал, что ValidateLifetime = true продолжит отклонять запрос, поскольку я изменил способ авторизации, а не аутентификацию.

1 Ответ

0 голосов
/ 24 апреля 2018

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

Добавление простого [Authorize] к контроллеру проверит токен-носитель, прежде чем он попадет в методы действия.

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