Сервис аутентификации

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

Функции сервиса аутентификации:

• Аутентификация пользователей;
• Аутентификация сервисов;
• Авторизация сервисов;
• Выдача прав для межсервисной аутентификации: сервер аутентифицирует другой сервис по его учётным данным, выдавая ему токен доступа и позволяя получать доступ к ресурсам.

Провайдеры аутентификации

При вызове сервиса аутентификации указывается провайдер, через который будет происходить аутентификация. Для каждого клиента устанавливается список допустимых провайдеров аутентификации.
Каждый провайдер реализует единый интерфейс, поддерживает механизмы локализации и конфигурации Платформы, проверяет валидность учетных данных, сверяя их по своим правилам с хранящимися в БД пользователя или клиента, производит учет пользователей.
Провайдер взаимодействует с сервисом аутентификации с помощью Authorization code flow, который обменивает код авторизации на токен идентификации.
Реализованы следующие провайдеры аутентификации:

• Identity provider;
• Active Directory provider.

Identity provider

Identity provider является основным провайдером при аутентификации и хранит в себе БД с внутренними пользователями системы (пользователи, которые содержатся в Identity), имеющими доступ к Платформе. В БД провайдера хранятся следующие пользовательские данные: логин, имя, фамилия, email, номер телефона.

Active Directory provider

Active Directory является внешним провайдером только для чтения, подключается по протоколу LDAP/LDAPS.

Аутентификация пользователей

Сервис аутентификации поддерживает механизм работы, основанный на открытом стандарте аутентификации и авторизации OpenID Connect, реализованном поверх протокола OAuth2.0.

О протоколе OAuth 2.0

Понятия и определения

Resource Owner: пользователь, который может предоставлять доступ к защищенному ресурсу.
Resource Server: сервер, на котором размещены защищенные ресурсы. Это WebAPI-приложение, к которому требуется получить доступ.
Client: приложение, выполняющее запросы защищенных ресурсов от имени Resource Owner.
Authorization Server: сервер, выдающий токены доступа клиенту после успешной аутентификации владельца ресурса и получения авторизации (сервис аутентификации).
Scope: механизм в OAuth 2.0 для ограничения доступа приложения к учетной записи пользователя.

OAuth 2.0 GrantTypes

OAuth 2.0 определяет четыре способа (Flow) для получения токена доступа, которые называются GrantTypes. Выбор способа (Flow) для использования определяется типом приложения.

• Authorization Code Flow: применяется для веб-приложений, которые развернуты на сервере. Возможно использование для мобильных приложений, но в этом случае используется дополнительный метод ProofKeyforCodeExchange (далее PKCE). Также этот способ рекомендуется использовать для SPA-приложений с использованием PKCE метода.
• Implicit Flow with Form Post: используется SPA-приложениями, написанными на JavaScript, выполняющимися в браузере пользователя.
• Resource Owner Password Flow: используется только с доверенными приложениями. Применение этого способа аналогично применению способа AuthorizationCode.
• Client Credentials Flow: используется для M2M (machine-to-machine) взаимодействий, таких как интерфейсы командной строки или серверные службы; аутентифицируется и авторизируется приложение, а не пользователь.

Спецификация также предоставляет механизм расширяемости для определения дополнительных грантов. Подробнее о протоколе OAuth2.0.

Дополнительные flow-платформы:

Delegation: применяется для запроса токена от имени интерактивного пользователя.
Refresh: используется для получения токенов обновления, которые позволяют получить долгосрочный доступ к API.

Алгоритм работы сервиса аутентификации

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

1. При входе пользователя отправляется запрос на условный интерфейсный сервис на аутентификацию.
2. Происходит проверка на аутентификацию от условного интерфейсного сервиса к сервису аутентификации.
3. Сервис аутентификации отправляет запрос на аутентификацию на указанный провайдер. Если провайдер не указан, то используется Identity provider.
4. Провайдер отправляет пользователю страницу аутентификации.
5. Пользователь вводит логин и пароль.
6. Провайдер осуществляет проверку пользователя в БД, выдает токен идентификации, отправляет токен идентификации в сервис управления сущностями. Токен идентификации включает в себя данные о пользователе.
7. Сервис управления сущностями проверяет, что пользователь с этим токеном идентификации существует. Если проверка прошла успешно, то выдает пользователю токен доступа, в котором он обращается к ресурсам интерфейсного сервиса. Токен доступа включает запрашиваемые области видимости.
8. Пользователь с текущим токеном доступа и разрешенными областями осуществляет запрос к ресурсу.

Авторизация пользователей с помощью сервиса аутентификации

Перед выполнением какого-либо пользовательского действия API-ресурс должен удостовериться, что это действие допустимо. Для авторизации на вызовы методов сервиса используется токен доступа, который выдается пользователю после его аутенцификации в сервисе управления сущностями. Из выданного токена доступа API-ресурс считывает разрешенные для пользователя области доступа, и сверяет с требуемыми на запрашиваемом методе. В некоторых сервисах после авторизации пользователя для работы с методом требуется проверка прав в Security на возможность работы пользователя с конкретными объектами этого сервиса.

Межсервисная аутентификация

При межсервисной аутентификации клиентское приложение вызывает метод сервиса (например, Service1), который вызывает защищённый метод другого сервиса (например, Service2). Алгоритм работы сервиса аутентификации при межсервисной аутентификации на Платформе представлен на рисунке ниже.

1. Сервис (далее Service1) запрашивает у другого сервиса (далее Service2) список методов и необходимые области видимости. Эта информация запрашивается только один раз. В дальнейшем используются сохранённые данные.
2. (а) Если в кэше есть токен доступа, содержащий все необходимые области видимости, то Service1 вызывает метод Service2, используя этот токен доступа.
   (б) Если обозначенных областей видимостейнедостаточно, то отправляется запрос с параметрами, указанными в предыдущем разделе, в сервис управления сущностями.
3. Если Service1 имеет право на область видимости: Service2_method, то сервис получит новый токен доступа с этой областью. Токен доступа будет храниться в кэше, пока не истечёт срок его действия.
4. Service1 вызывает method Service2, используя полученный токен доступа.

Настройка межсервисной аутентификации

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

1. Сначала настраиваются сущности ресурсов и их областей видимости для доступа к конкретным методам этого ресурса. Пример первого списка:

Сервис	Метод	Область
reporting-module	/api/reports/templates/save	reports:templates:write
reporting-module	/api/reports/export	reports:execute
MessageDispatcher	/api/message/list	messagedispatcher:message:read
Localization	/api/Culture/Get/{Code}	localization:culture:read
Localization	/api/Culture/Add	localization:culture:write
WebNotification	/api/Home/ClearHistory	webnotification:home:write

2. Затем происходит настройка клиентов, используемых в сервисах, и областей видимости, необходимых для работы этого сервиса. Пример второго списка:

Сервис	Требуемые области
reporting-module	discovery:service:read
reporting-module	filesservice:files:read
bookservice	filesservice:data:read

В коде сервиса (который затем станет ресурсом) прописываются области видимости в атрибутах на методах/контроллерах, с которыми в этот метод даётся доступ. В базе взаимодействующих сервисов прописываются области видимости для сервисов для доступа к другим ресурсам (сервисам).

Пример C#

[HttpPost("RedirectUris/GetOne")] // endpoint метода
[ScopeRequirement("identityadminapi:client:read")] // название области, 
// необходимой для выполнения метода
public async Task<ValueApiResult> GetOneRedirectUri([FromBody] IntIdApiParam value)

Области видимости настраиваются при первоначальной настройке или при обновлении Платформы. Менять области видимости при использовании Платформы не требуется.