Перейти к основному содержимому
Версия: Next

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

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

  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. Если нет, то сохраняет о нем информацию.

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

  1. При открытии Платформы зарегистрированным Пользователем проверяется наличие валидного ADCP kc-access.
    1. Если kc-access валидный, то пользователь автоматически аутентифицируется в Платформе.
    2. Если kc-access, но время его действия истекло, то проверяется kc-refresh, если он валидный и время его действия не истекло, то выпускается новый kc-access, и пользователь аутентифицируется в платформе.
  2. Если ADCP kc-access невалидный, пользователь перенаправляется на IDP Компании. IDP Компании возвращает код. Код обменивается на access_token и refresh_token Keycloak-ом. Keycloak генерирует код и отправляет его ADCP для его обмена на kc-access и kc-refresh.
  3. Если оба токена невалидны (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. Использование функционала определяется конфигурацией системы. Авторизация в 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.

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