OAuth 2.0 или OpenID Connect

Для авторизации пользователей при подключении к репозиторию в веб-приложении доступно использование протокола OAuth 2.0 или OpenID Connect. Аутентификация пользователя производится под учётной записью сервисов, поддерживающих данный протокол.

Если учётная запись пользователя внешнего сервиса содержится в менеджере безопасности, то будет выполнено подключение к репозиторию и вход в навигатор объектов под этим пользователем.

Если учётная запись пользователя внешнего сервиса не содержится в менеджере безопасности, то будет создан временный пользователь и добавлен в группы из списка атрибута, указанного в userinfo. Если атрибут не задан, то временный пользователь добавляется во встроенную группу ПОЛЬЗОВАТЕЛИ.

Подключение к СУБД производится под технологической учётной записью.

При необходимости ознакомьтесь с расширенной схемой взаимодействия веб-приложения с внешним сервисом.

Шаг 1. Сохранение технологической учётной записи для подключения к СУБД

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

Для настройки подключения к репозиторию:

1. Запустите приложение PP.Util, расположенное в папке установки продукта «Форсайт. Аналитическая платформа», с помощью командной строки от имени администратора. Ниже приведены команды для настройки подключения к репозиторию. Вместо PP.Util используйте PP.Util_start.sh для выполнения команды в ОС Linux, PP.Util.exe для ОС Windows.

Примечание. В ОС Linux при сохранении зашифрованного пароля технологической учётной записи запрашивается единица лицензирования AnalyticsPlatform. Ознакомьтесь со способами указания системной переменной LSFORCEHOST или LSHOST перед выполнением PP.Util_start.sh.

2. Сохраните зашифрованный пароль технологической учётной записи для подключения к СУБД:

• если предполагается аутентификация на сервере базы данных под одной технологической учётной записью для всех пользователей внешнего сервиса, то в менеджере безопасности не обязательно добавлять всех внешних пользователей, но обязательно должен быть добавлен пользователь, учётные данные которого будут использоваться в качестве технологической учётной записи для подключения к СУБД. В этом случае данные единой технологической учётной записи должны быть сохранены с помощью команды:

PP.Util /save_creds /ALG gos <идентификатор репозитория> /DC <имя пользователя репозитория (технологической учётной записи)>
		

Пример сохранения данных одной общей технологической учётной записи для всех пользователей внешнего сервиса:

PP.Util /save_creds /ALG gos REPOSITORY_ID /DC TECHNO_ACCOUNT TECHNO_PASSWORD

• если предполагается аутентификация на сервере базы данных под разными технологическими учётными записями, соответствующими пользователю внешнего сервиса, то в менеджере безопасности не обязательно добавлять всех внешних пользователей, но обязательно должны быть добавлены пользователи, учётные данные которых будут использоваться в качестве соответствующих технологических учётных записей для подключения к СУБД. В этом случае данные каждой технологической учётной записи для соответствующих внешних пользователей должны быть сохранены с помощью команды:

PP.Util /save_creds /ALG gos <идентификатор репозитория> <имя пользователя репозитория (технологической учётной записи)> <пароль пользователя репозитория (технологической учётной записи)> <имя пользователя репозитория (внешнего сервиса)>		
		

Пример сохранения данных различных технологических учётных записей:

PP.Util /save_creds /ALG gos REPOSITORY_ID TECHNO_NAME1 TECHNO_PASSWORD1 USER1
PP.Util /save_creds /ALG gos REPOSITORY_ID TECHNO_NAME2 TECHNO_PASSWORD2 USER2
PP.Util /save_creds /ALG gos REPOSITORY_ID TECHNO_NAME2 TECHNO_PASSWORD2 USER3	

Пользователи TECHNO_NAME1, TECHNO_NAME2, учётные данные которых используются в качестве технологических, обязательно должны быть добавлены в менеджере безопасности. Пользователи внешнего сервиса USER1, USER2, USER3 могут быть добавлены в менеджере безопасности, а могут быть временными пользователями.

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

При подключении к репозиторию происходит поиск сохранённой технологической учётной записи для подключения к СУБД:

• Сначала выполняется поиск сохранённой технологической учётной записи, соответствующей пользователю внешнего сервиса;

• Если такая учетная запись не найдена, то подключение к СУБД осуществляется под единой учётной записью, сохранённой по умолчанию с параметром /DC;

• Если отсутствует единая учётная запись, сохранённая с параметром /DC, и учётная запись, соответствующая пользователю внешнего сервиса, то генерируется ошибка подключения.

Примечание. При входе в систему выполняется проверка имени пользователя, полученного от внешнего сервиса с учётом формата, заданного в параметре PPUserNameFormat.

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

Шаг 2. Настройка параметров для протокола OAuth/OpenID Connect

При аутентификации через внешние сервисы должно быть настроено соединение между клиентом и BI-сервером по протоколу HTTPS. По умолчанию выполняется проверка параметра state для защиты от потенциальных атак типа CSRF при получении кода авторизации. Если соединение между клиентом и BI-сервером настроено по протоколу HTTP, то создайте параметр StateCheckOff со значением «1» в разделе реестра [HKLM\SOFTWARE\Foresight\Foresight Analytics Platform\10.0\PP\BIS\System\OAuth] или в соответствующем разделе файла settings.xml для отключения проверки.

Для протокола OAuth или OpenID Connect добавьте подразделы с наименованиями сервисов и задайте соответствующие настройки реестра в разделе [HKLM\SOFTWARE\Foresight\Foresight Analytics Platform\10.0\PP\BIS\System\OAuth\<наименование сервиса>] или в соответствующем разделе файла settings.xml со следующими параметрами:

Пример заполнения параметров представлен в разделе System для файла settings.xml.

Примечание. Для конструктора бизнес-приложений можно настроить автоматическую переадресацию на авторизацию пользователей через протокол OAuth/OpenID Connect при входе в веб-приложение. Для этого в файле DBA.config.json задайте значение «OAuth» в поле authentication и укажите сервисы авторизации, заданные при настройке параметров для протокола OAuth или OpenID Connect, в поле allowOauthProviders.

Шаг 3. Подготовка BI-сервера

Взаимодействие BI-сервера с внешними сервисами осуществляется через стороннюю библиотеку libcurl. С её назначением, возможностями и ограничениями можно ознакомиться на официальном сайте https://curl.haxx.se/libcurl/. Работа BI-сервера должна осуществляться по протоколу HTTPS.

Для подготовки BI-сервера проверьте наличие сети Интернет на сервере, где установлен BI-сервер, и убедитесь, что доступ к сайтам сервисов открыт.

Если интернет-соединение осуществляется через прокси-сервер, то создайте системные переменные:

• CURLOPT_PROXY. Задайте переменной значение «proxy.sever.ru:8080», в котором содержится адрес прокси-сервера и порт, через который осуществляется подключение;

• CURLOPT_PROXYUSERPWD. Задайте переменной значение «login:password», в котором содержится имя пользователя и пароль для подключения к интернету.

В ОС Linux переменные окружения содержатся в файле /opt/foresight/fp10.x-biserver/etc/envvars и добавляются в формате: <имя переменной>=<значение>.

Переменные окружения считываются при старте BI-сервера с экземпляром Apache2. Для получения подробной информации о добавлении переменных окружения в ОС Linux обратитесь к разделу «Конфигурация и настройка».

Примечание. При необходимости для отслеживания выполняемых действий и получения отладочной информации создайте переменные окружения PP_LOG и CURLOPT_VERBOSE со значением «1».

Если внешний сервис доступен по протоколу HTTPS, то скопируйте корневой сертификат *.crt, с помощью которого был подписан сертификат безопасности внешнего сервиса, на BI-сервер и выполните следующие действия:

• в ОС Linux:

1. Создайте папку fp-extra-certs и переместите в неё корневой сертификат внешнего сервиса:

sudo mkdir /usr/share/ca-certificates/fp-extra-certs
sudo cp <путь до папки>/<наименование сертификата>.crt /usr/share/ca-certificates/fp-extra-certs/fp-extra-ca.crt

После выполнения действий будет создана папка /usr/share/ca-certificates/fp-extra-certs с корневым сертификатом внешнего сервиса fp-extra-ca.crt.

2. Откройте на редактирование файл /etc/ca-certificates.conf и добавьте строку в конец файла:

fp-extra-certs/fp-extra-ca.crt

3. Примените изменение конфигурации:

sudo update-ca-certificates -v

• в ОС Windows импортируйте корневой сертификат внешнего сервиса в хранилище доверенных корневых центров сертификации средствами операционной системы:

1. Дважды щёлкните по корневому сертификату *.crt. После чего будет открыто окно «Сертификат».

2. Нажмите кнопку «Установить сертификат». После чего будет открыт мастер импорта сертификатов.

3. Выберите расположение хранилища «Текущий пользователь» и нажмите кнопку «Далее».

4. Установите переключатель «Поместить все сертификаты в следующее хранилище», выберите хранилище сертификатов «Доверенные корневые центры сертификации» и нажмите кнопку «Далее».

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

Шаг 4. Подготовка и открытие веб-приложения

Работа веб-приложения должна осуществляться по протоколу HTTPS. Для подготовки веб-приложения используйте файл Metabases.xml, добавьте атрибут Authentication со значением «7» и заполните раздел OAuthService с атрибутами:

• Providers. Массив наименований сервисов авторизации, учётные записи которых можно использовать для входа в веб-приложение. Допустимые значения определяются тем, какие сервисы заданы при настройке параметров для протокола OAuth/OpenID Connect, и указываются через точку с запятой. Обязательный атрибут;

• AutoStartProvider. Индекс сервиса авторизации, указанного в массиве атрибута Providers. На выбранный сервис будет выполняться автоматическая переадресация при попытке входа в веб-приложение с использованием протокола OAuth/OpenID Connect. Необязательный атрибут.

Если в качестве значения атрибута используется сервис, который не содержится в атрибуте Providers, то автоматическая переадресация выполняться не будет;

Пример файла Metabases.xml:

<PP>
    <Metabases>
        <REPOSITORY_ID Name="REPOSITORY_ID" Authentication="7" Package="STANDARDSECURITYPACKAGE">
            <OAuthService AutoStartProvider="0" Providers="Google"/>
            <LogonData DATABASE="DATABASE_NAME" CASESENSITIVE="true" SERVER="SERVER_DATABASE"/>
        </REPOSITORY_ID>
    </Metabases>
</PP>		

Альтернативным способом подготовки веб-приложения является добавление аналогичных параметров в раздел реестра:

• [HKEY_CURRENT_USER\SOFTWARE\Foresight\Foresight Analytics Platform\10.0\Metabases\<идентификатор репозитория>] - настройки конкретного репозитория для текущего пользователя, не зависимо от разрядности системы;

• [HKEY_LOCAL_MACHINE\SOFTWARE\Foresight\Foresight Analytics Platform\10.0\Metabases\<идентификатор репозитория>] - настройки конкретного репозитория в случае, когда разрядность «Форсайт. Аналитическая платформа» совпадает с разрядностью операционной системы. Для всех пользователей.

После изменений перезапустите BI-сервер и откройте веб-приложение. В окне регистрации будут доступны кнопки авторизации для входа в систему с использованием протокола OAuth или OpenID Connect:

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

Расширенная схема взаимодействия веб-приложения с внешним сервисом

Схема взаимодействия веб-приложения с внешним сервисом:

1. Пользователь выбирает репозиторий, настроенный на работу с внешним сервисом:

BI-сервер обрабатывает запрос на передачу настроек внешних сервисов и отображения соответствующих кнопок в окне регистрации.

2. Пользователь нажимает кнопку соответствующего внешнего сервиса в окне регистрации и переходит на страницу авторизации. Вводит логин и пароль.

При успешной аутентификации происходит перенаправление пользователя в веб-приложение и клиент получает код подтверждения авторизации.

3. Клиент отправляет запрос BI-серверу на получение токена авторизации внешнего сервиса. В запросе передаётся код подтверждения авторизации и адрес веб-приложения.

4. BI-сервер отправляет запрос внешнему сервису на получение токена авторизации. Запрос выполняется через адрес сервиса авторизации, указанный в параметре RequestTokenUrl. Внешний сервис обрабатывает запрос по коду подтверждения авторизации и возвращает данные:

• access_token. Токен авторизации;

• id_token. Идентификационный токен, если в параметре AuthUrl задан дополнительный параметр scope для протокола OpenID Connect;

• refresh_token. Токен для периодического обновления токена авторизации;

• expires_in. Время жизни токена авторизации. Во время открытой сессии с репозиторием будет выполняться запрос на обновление access_token и refresh_token по истечении времени жизни токена авторизации. Если на внешнем сервисе сессия пользователя неактивна или сервер недоступен, то соединение с репозиторием будет прервано.

Полученные данные определяют текущее состояние авторизации. В качестве хранилища состояний авторизации используется:

• сервер состояний. Сохранённые данные автоматически удаляются по истечении времени хранения записей на сервере;

• оперативная память BI-сервера. Сохранённые данные автоматически удаляются при перезапуске BI-сервера.

5. BI-сервер создаёт в хранилище уникальный ключ текущего состояния авторизации и передаёт его на клиент. Клиент отправляет запрос BI-серверу на подключение к репозиторию. В запросе передаётся уникальный ключ текущего состояния авторизации.

6. BI-сервер отправляет запрос внешнему сервису на получение данных авторизованного пользователя. Внешний сервис обрабатывает запрос по значению параметра UserDataUrl и возвращает информацию о пользователе, в том числе имя пользователя, которое будет отображаться в навигаторе объектов и менеджере безопасности.

7. BI-сервер обращается к СУБД, используя предварительно сохранённую технологическую учётную запись.

8. BI-сервер возвращает на клиент моникёр сессии. Происходит перенаправление пользователя в навигатор объектов.