Правильный дизайн для ASP. NET Core 3.x Microservices с токенами на предъявителя и сохранением некоторой пользовательской информации - PullRequest
Новая
       94

Правильный дизайн для ASP. NET Core 3.x Microservices с токенами на предъявителя и сохранением некоторой пользовательской информации

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

Мы начинаем переносить наши приложения из монолитных c приложений в коллекции микросервисов, работающих под управлением ASP. NET Core 3.1 и размещенных в кластере Kubernetes. У меня есть вопрос, касающийся наилучшего подхода к настройке аутентификации и авторизации в этих службах при сохранении надлежащего (а иногда и дублированного в разных сервисах) внутри каждого сервиса.

Я прошу прощения, если неправильно использовал терминологию безопасности. Пожалуйста, исправьте меня.

Для аутентификации у нас уже развернут федеративный сервер аутентификации, основанный на Thinktecture IdentityServer 4, который будет аутентифицировать пользователя по нескольким источникам (локальная база данных, Azure AD и др. c. При аутентификации пользователь получает токен Bearer, который можно использовать в ряде приложений. Эти приложения являются мобильными, традиционными ASP. NET MVC, Angular и многим другим ASP. NET Базовые службы WEB API.

Настройка конвейера для аутентификации входящий токен на предъявителя кажется простым.

Startup.cs 

public void ConfigureServices(IServiceCollection services) {
   ...
   services
      .AddAuthentication(options => {
         options.DefaultAuthenticateScheme = IdentityServerAuthenticationDefaults.AuthenticationScheme;
         options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
      })
      .AddIdentityServerAuthentication(options => {
         options.Authority = ssoSettings.BaseUri.ToString();
         options.ApiName = "someApi";
         options.ApiSecret = ssoSettings.ClientSecret;   

         options.EnableCaching = true;
      });
   ...
}

Либо запрос принят, либо 401 Unauthorized возвращается. (Существует глобальная политика авторизации.)

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

В традиционных приложениях пользователь, как правило, направляется к конечной точке, вошедшей в систему, которая может делать что угодно это нужно сделать с пользователем после того, как он войдет в систему. (Например, сохраните данные, предоставленные заявками для будущего использования.) Затем конечная точка может перенаправить их обратно на исходную страницу. Но в микросервисе Web API этот поток недоступен. Все, что сделал пользователь, - это отправил запрос с выданным токеном на предъявителя, который служба может подтвердить. И сервис будет делать это для каждого входящего запроса. (Кэширование на стороне службы может снизить стоимость проверки.)

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

Каков правильный подход к этому при работе с «отключенными» микросервисами?

Не уверены, влияет ли это на ответ или нет, мы используем Как pNet Core Identity для отслеживания информации о пользователях и ролях в наших приложениях для автономного использования (и нормализации данных), поэтому я подумывал сделать то же самое здесь. Таким образом, каждый микросервис будет иметь свой собственный набор таблиц [AspNet*] (User, Roles, UserRoles и т. Д. c.) Для этой цели. Очевидно, что свойства, связанные с аутентификацией пользователя, такие как PasswordHash, TwoFactorEnabled, et c. или даже некоторые таблицы, такие как [AspNetUserTokens] (??), будут существовать, но будут игнорироваться.

Startup.cs 

services
   .AddIdentity<IdentityUser, IdentityRole>(options => {
   })
   .AddEntityFrameworkStores<MyServiceDbContext>();

Это то, что используется для сценария ios как это?

...