Аутентификация и авторизация в качестве центральной службы MicroService ASP.NET

Я планирую изменить ASP.NET Web API 2.0, который включает аутентификацию и авторизацию, а также все службы, в архитектуру микросервисов.

Мой вопрос, если я создам центральный микросервис для обработки аутентификации и авторизации. Как разрешить пользователям отправлять запросы со своими токенами в другие сервисы?

Чтобы уточнить вопрос:

Допустим, у меня есть три микросервиса. 1) Платформа ASP NET, обрабатывающая аутентификацию и авторизацию, которая аутентифицирует пользователя и отправляет токен. 2) Сервис заказов, который будет получать запросы с токеном в заголовках. (Ядро ASP NET) 3) Бухгалтерский сервис, который будет получать запросы с токеном в их заголовках. (Ядро ASP NET)

Как мы авторизуем пользователей, когда они звонят в службу 2 или 3? И это идеальный подход?


microservices asp.net-core asp.net-web-api asp.net-identity asp.net-authorization
person sai dharmendra kanneganti    schedule 08.04.2019    source источник
comment
ваша служба аутентификации и авторизации, скорее всего, сгенерирует токен jwt token. токен будет отправлен в качестве токена на предъявителя другим службам. другие ваши службы будут проверять токен jwt в своем промежуточном программном обеспечении.   -  person Imran Arshad    schedule 08.04.2019
comment
См. docs.identityserver.io/en/latest   -  person Chris Pratt    schedule 08.04.2019
comment
@ImranArshad Спасибо за идею. У меня мой API написан на платформе ASP.NET, которая будет генерировать токен с помощью OAuthProvider, и теперь я хочу авторизовать этот токен в другой базовой службе ASP.NET и получить userId из токена, с помощью которого я могу извлекать данные из база данных. Это возможно? И если это возможно, не могли бы вы указать мне, какие шаги необходимы, или опубликуйте меня с примером статьи или документа.   -  person sai dharmendra kanneganti    schedule 08.04.2019

Ответы (2)


arrow_upward
3
arrow_downward

Основано на комментариях выше

Внешний поставщик удостоверений

Возможно, вам потребуется использовать внешнего поставщика удостоверений, например. Identiyserver4, azure ad или auth0 и т. д. Поскольку токен может быть сгенерирован, это токен JWT, вам необходимо будет проверить токен.

Проверить токен

Вам необходимо проверить токен в промежуточном ПО ядра .Net. Каждый выпущенный токен имеет полезную нагрузку, и промежуточное ПО вашего приложения будет проверять каждый входящий токен и отклонять его, если оно не может быть проверено. Ваше промежуточное ПО будет соответствовать принципу претензий, который можно использовать в вашем приложении для проверки авторизации, например. роли (если у пользователя есть авторизация для доступа к определенному API). Вы поместите атрибут «авторизовать» поверх контроллера, и он выполнит свою работу.

Вы можете проверить токен вручную, или какой-либо поставщик удостоверений выполнит автоматическую проверку, например. Azure Ad проверит токен и выполнит принцип утверждений, не прилагая особых усилий, просто добавив пакет Azure ad nuget.

Есть куча примеров, если просто погуглить. Токены могут сбивать с толку, поэтому я предлагаю вам разобраться в токенах, например. id_token, access_token, токен обновления. Потоки аутентификации и утверждения. Стало бы легче, если бы вы понимали типы и потоки токенов. Я прилагаю очень простой пример, чтобы дать вам представление.

Пример

person Imran Arshad    schedule 10.04.2019
comment
Просто подтверждаю, нужно ли мне заменить существующего поставщика удостоверений веб-API asp net на внешнего поставщика удостоверений для генерации токенов JWT, которые позволят другим моим микросервисам использовать и аутентифицироваться? Если да, мне нужно написать новый API (на этот раз можно также использовать ASP Net Core API) для генерации токенов. Могу ли я использовать существующий API для генерации токенов и теперь могу писать новые микросервисы? - person sai dharmendra kanneganti; 10.04.2019
comment
из вопроса я предположил, что вам нужно написать систему с нуля. Если вы уже используете поставщика удостоверений, вы можете его использовать. какого поставщика удостоверений вы используете? возможно, вам придется поделиться более подробной информацией о вашем существующем провайдере идентификации и о том, как далеко вы продвинулись в системе и какие части отсутствуют? - person Imran Arshad; 11.04.2019

arrow_upward
5
arrow_downward

Вместо аутентификации внешних запросов на каждой микросервисе (вы можете сделать это для внутренней связи микросервисов) я бы установил шлюз (например, Ocelot, который может обрабатывать внешнюю" восходящую "аутентификацию для вас, используя любую систему, которую вы используете, например, для носителя Jwt:

public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthentication()
        .AddJwtBearer("TestScheme", x => ...
}

Затем в Ocelot вы можете решить, для каких маршрутов требуется эта схема, следующим образом

"Routes": [{
        "DownstreamHostAndPorts": [...],
        "DownstreamPathTemplate": "/",
        "UpstreamPathTemplate": "/",
        "AuthenticationOptions": {
            "AuthenticationProviderKey": "TestScheme", //<--here decide to use this scheme
            "AllowedScopes": []
        }
    }]

Если аутентификация прошла успешно, вы можете использовать метод Ocelot «преобразования требований в утверждения» из восходящего потока в нисходящий этот метод - я лично хотел настроить его и создать новый токен Jwt для внутренней аутентификации, поэтому использовал свой собственный обработчик нисходящего потока, например:

services
   .AddHttpClient<IMyService, MyService>(client => ...)
   .AddHttpMessageHandler<MyJwtDownstreamHandler>();

//then in the MyJwtDownstreamHandler
request.Headers.Authorization = new AuthenticationHeaderValue(
   "bearer",
   TokenGenerator.Generate( //<--generate your own Symmetric token using your own method
       identity: myIdentity, //<--claims for downstream here
   )
);
person Brett    schedule 28.05.2020