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

Допущения и ограничения

1. Аутентификация пользователей ADCP через IDP (Identity Provider) компании реализуется на базе протокола OpenId Connect 1.0 (далее OIDC). Подробнее о протоколе: https://openid.net/connect/.
2. Допускается использование любого IDP.
3. Описанное решение распространяется только для аутентификации пользователей Платформы и применяется в компонентах GraphQL Server, Front-End. При взаимодействии компонентов Платформы между собой используются отдельные токены, хранящиеся в kubernetes secrets (этот функционал будет рассмотрен в рамках отдельного документа).
4. Назначение пользовательских ролей производится администратором Платформы ADCP.
5. На первом этапе внедрения сторонней аутентификации в ADCP не предполагается учет групп пользователей из AD.
6. Безопасность данных пользователей, хранящихся в системе обеспечивается ограничением доступа к компонентам системы.

Процесс аутентификации Пользователя

Регистрация пользователя

1. Новый Пользователь открывает Платформу путем перехода по адресу ADCP.
2. Пользователь автоматически перенаправляется на сервис аутентификации IDP Компании. Сервис предоставляет форму аутентификации для ввода логина и пароля.
3. IDP Компании выполняет аутентификацию пользователя по стандартному процессу протокола. И возвращает в ответ код, в обмен на который Keycloak получает токены и информацию о пользователе.
   1. Если пользователь уже существует, то генерирует свой код, который он передает непосредственно ADCP.
   2. Если пользователь не существует, то создается новая запись о пользователе и для нее генерируется код для передачи в ADCP.
4. Далее ADCP обменивает код у Keycloak на access_token и refresh_token, и сохраняет их в cookie браузера пользователя. Дополнительно проверяется, есть ли пользователь в Auth Service. Если нет, то сохраняет о нем информацию.

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

5. При открытии Платформы зарегистрированным Пользователем проверяется наличие валидного ADCP kc-access.
   1. Если kc-access валидный, то пользователь автоматически аутентифицируется в Платформе.
   2. Если kc-access, но время его действия истекло, то проверяется kc-refresh, если он валидный и время его действия не истекло, то выпускается новый kc-access, и пользователь аутентифицируется в платформе.
6. Если ADCP kc-access невалидный, пользователь перенаправляется на IDP Компании. IDP Компании возвращает код. Код обменивается на access_token и refresh_token Keycloak-ом. Keycloak генерирует код и отправляет его ADCP для его обмена на kc-access и kc-refresh.
7. Если оба токена невалидны (access_token и refresh_token), то пользователь перенаправляется на форму аутентификации IDP Компании и выполняются пп.2 и 3 Процесса первичной регистрации пользователя, которые описаны выше.

Схема обмена данными с внутренними сервисами при аутентификации пользователей

Для работы внутренних компонентов используется внутренний токен ADCP. Токен от внешнего провайдера авторизации используется только для авторизации пользователя в системе.

Все обращения к External Identity Provider производятся по защищенному https-протоколу.

Техническое описание компонентов аутентификации

Точка аутентификации ADCP

Точкой аутентификации в системе ADCP является Keycloak.

Он берет на себя задачу интеграции с провайдерами идентификации (IDP) и предоставления возможности входа пользователей в систему ADCP.

Keycloak никак не ограничивает выбор IDP, в том числе он позволяет использовать в качестве IDP сторонний Keycloak.

Точка интеграции ADCP с Keycloak

Точкой интеграции ADCP с Keycloak является Gatekeeper.

Задачи GoGateKeeper

1. Актуализация токенов
2. Proxy запросов к системе с функцией проверки доступа
3. Обработка сценариев отсутствия доступа

Данный компонент устанавливается всегда наряду с требующим аутентификацию компонентом.

В системе ADCP в настоящее время таких компонента два - GraphQL Server (предоставляет доступ к GraphQL API) и Frontend (отвечает за отображение интерфейса). Связка этих компонентов обеспечивает доступ к основному функционалу системы: Маркетплейс, Глоссарий, DataLab, Cleanroom.

Когда пользователь посещает систему ADCP, его запрос в первую очередь обрабатывается Gatekeeper’ом. Он проверяет, аутентифицирован ли пользователь. Если - нет, то перенаправляет его в Keycloak, если - да, то проксирует запрос компоненту Frontend, и в итоге пользователь видит интерфейс системы.

При взаимодействии с интерфейсом системы ADCP периодически отправляются запросы на GraphQL Server. Gatekeeper проверяет аутентификацию каждого запроса GraphQL Server’a. В случае успеха проксирует запрос к нему, добавляя в его заголовки X-Auth-Email, X-Auth-Given-Name, X-Auth-Family-Name.

В будущих версиях планируется поддержка авторизации в GitLab c использованием учетной записи пользователя. То есть при входе в ADCP не нужно будет дополнительно логиниться в GitLab. Авторизация в Apache Atlas может быть использована авторизация через External Identity Provider. Использование функционала определяется конфигурацией системы. Авторизация в Grafana и Kibana обеспечивается теми же мехнизмами, что и для основной части системы ADCP.

Точка идентификации пользователя ADCP

В качестве точки идентификации выступает Auth Service. Данный сервис хранит информацию о пользователях и их ролях в организациях, является внутренним компонентом системы ADCP.

К данному сервису приходят запросы от GraphQL Server.

GraphQL Server автоматически регистрирует пользователя в случае, если он не был найден в Auth Service и Identity Provider предоставляет информацию об имени и фамилии пользователя. Эти данные передаются GraphQL Server’у Gatekeeper’ом через headers X-Auth-Given-Name, X-Auth-Family-Name.

Назначение роли пользователя

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

1. Назначение администратором системы
2. Назначение на основе данных access_token

Назначение администратором системы

В этом случае, назначение роли происходит после завершения регистрации пользователя в системе. При первом входе в систему такой пользователь не будет иметь назначенных ролей. Назначить роль для пользователя через интерфейс системы может только пользователь с ролью ADMIN.

Рекомендуется включить возможность в конфиге в случае, когда используемые на инстансе IDP не отправляют роль в access_token.

Назначение на основе данных access_token

Назначение/обновление роли происходит каждый раз при обработке запроса пользователя к системе.

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

Внешний провайдер идентификации (IDP) выпускает access_token, в котором вшита информация о ролях пользователя в ADCP.

Когда отправляется запрос в GraphQL Server (то есть происходит обращение пользователя к системе), он запрашивает в Keycloak ADCP access_token внешнего IDP, потом его декодирует и получает роли пользователя. Если роли изменились, обновляет их в ADCP.

Список ролей в ADCP описан по ссылке.

Ожидаемое соответствие ролям названий:

• DATA_ASSET_OWNER = Владелец информационного актива
• DATA_STEWARD = Распорядитель / стюард данных
• DATA_ANALYST = Технический стюард
• DATA_RESEARCHER = Датасаентист
• ADMIN = Администратор
• GLOSSARY_RESEARCHER = Исследователь глоссария
• TEAMLEAD = Тимлид

Процесс входа пользователя в систему ADCP

Ниже приведена диаграмма последовательности входа пользователя в систему ADCP, в настройках Keycloak которой в качестве IDP указан Active Directory. В качестве провайдера авторизации вместо Active Directory может выступать любой OIDC Provider, в частности это может быть другой KeyCloak со стороны компании.

В диаграмме приведены процесс получения токена доступа п. 1-22.

Процесс аутентификации пользователей приведен в п. 22-31.

Ссылка на просмотр