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

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

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

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

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

При вызове сервиса аутентификации и авторизации указывается провайдер, через который будет происходить аутентификация. Для каждого клиента устанавливается список допустимых провайдеров аутентификации.
Каждый провайдер реализует единый интерфейс, поддерживает механизмы локализации и конфигурации Платформы, проверяет валидность учетных данных, сверяя их по своим правилам с хранящимися в БД пользователя или клиента, производит учет пользователей.
Провайдер взаимодействует с сервисом аутентификации и авторизации с помощью 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)

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