Инструмент интерактивного анализа и визуализации данных
Функции администратора Системы

делегирование задачи аутентификации провайдеру;

получение identity token и access token от провайдера;

проверка наличия учетной записи пользователя в базе:

Система получает REST-запрос от стороннего приложения;

из запроса извлекается access token;

выполняется проверка наличия учетной записи пользователя в базе:

сторонняя система отправляет в провайдер запрос на предоставление access token, который может быть использован для доступа к ресурсам Системы от имени пользователя;

провайдер проводит аутентификацию пользователя, затем при необходимости высылает пользователю запрос на согласие в предоставлении доступа, после чего отправляет в стороннюю систему access token;

сторонняя система отправляет в Систему REST-запрос c полученным access token;

REST сервис в Системе обрабатывает запрос, извлекает access token. Выполняется проверка подписи и доступов:

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

Система извлекает identity token и access token. Выполняется проверка наличия пользователя, подписи и доступов:

пользователь авторизуется в стороннем приложении с помощью единой точки входа;

работает с разделами стороннего приложения;

нажимает на кнопки для перехода к Системе, после чего переходит в автоматизированную информационно-аналитическую систему «Analytic Workspace», минуя форму авторизации (Система получает access_token от сторонней системы).

сторонняя система отправляет в провайдер запрос на предоставление access token, который она может использовать для доступа к ресурсам Системы от имени пользователя;

провайдер проводит аутентификацию пользователя. Затем при необходимости отправляет пользователю запрос на согласие в предоставлении доступа. После чего отправляет в стороннюю систему access token;

сторонняя система делает POST запрос к api/auth-provider/verify-code (верификация кода авторизации) с обязательными параметрами: id – идентификатор провайдера в Системе, code – access_token, полученный от провайдера;

если все проверки на стороне Системы пройдены успешно, то в ответ сторонняя система получает token Системы. Дальше его используют для последующих запросов к API Системы.

сторонняя система отправляет в провайдер запрос на предоставление access token, который она может использовать для доступа к ресурсам Системы от имени пользователя;

провайдер проводит аутентификацию пользователя. Затем при необходимости отправляет пользователю запрос на согласие в предоставлении доступа. После чего отправляет в стороннюю систему access token;

сторонняя система отправляет запрос на frontend Системы /auth/verify-code/ с обязательными параметрами: id – идентификатор провайдера в Системе, code – access_token, полученный от провайдера, и дополнительными параметрами: sessionId – идентификатор сессии пользователя и redirectUrl – URL Системы, запрашиваемый пользователем;

frontend Системы перехватывает запрос и обращается к backend Системы, backend обращается к провайдеру;

если все проверки на стороне Системы пройдены успешно, то генерируется внутренний token Системы. Дальше frontend использует его для открытия запрашиваемого ресурса в redirectUrl (например, /app/widgets, при отсутствии адреса в redirectUrl пользователю откроется первый доступный раздел Системы).

в случае неуспешной аутентификации пользователя через LDAP выводится текст ошибки, полученный от LDAP сервера;

в случае успешной аутентификации пользователя через LDAP и отсутствия данного пользователя в списке пользователей Системы:

в случае успешной аутентификации пользователя через LDAP и при наличии учетной записи данного пользователя в списке пользователей Системы:

логин;

электронная почта;

тип пользователя из настроек провайдера;

группы (см. п. 2)).

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