Для обеспечения возможности входа пользователя на аналитический портал (АП) посредством разных методов идентификации и аутентификации, спроектированы и разработаны провайдеры аутентификации.

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

Провайдер аутентификации (ПА) — это некоторый внутренний/внешний метод/сервис, который может выполнить идентификацию и последующую аутентификацию пользователя, результатом работы которого будет как минимум информация об учётных данных пользователя и маркер доступа с периодом действия («токен»).

Пока период действия маркера доступа не истек, пользователь автоматически входит на АП.

На основе текущей реализации вариантов входа на АП созданы следующие провайдеры аутентификации:

1. «Password» — провайдер, использующий имя пользователя и пароль для аутентификации;
2. «LDAP for Active Directory» — провайдер, передающий имя пользователя и пароль в службу каталогов «Active Directory» посредством протокола «LDAP»;
3. «SAML» — провайдер, выполняющий создание подписанного «XML–документа» по стандарту «SAML», который используется для идентификации системы и передающий созданный документ внешней системе для выполнения аутентификации пользователя;
4. «OAuth2.0 Client Credentials» — провайдер аутентификации, выполняющий авторизацию посредством стандарта авторизации «OAuth 2.0», с использованием типа предоставления учётных данных «ClientCredentials», который используется для конфиденциальных клиентов, которые запрашивают доступ к своим ресурсам или ресурсам, заранее согласованным с сервером авторизации;
5. «OAuth2.0 Authorization Code» — провайдер аутентификации, выполняющий авторизацию посредством стандарта авторизации «OAuth 2.0», с использованием типа предоставления учётных данных «Authorizationcode», который в основном используется для «Web-сервисов», которые выполняют перенаправление запроса на сервер авторизации и обрабатывают ответ;
6. JWT: Decode — проверка и декодирование JWT (JSON Web Token), переданного пользователем, с последующей аутентификацией на основе данных из токена;
7. Bitrix24 — провайдер, обеспечивающий аутентификацию через внешний портал Bitrix24 по протоколу OAuth 2.0 с возможностью входа под учётной записью Bitrix24.

Конфигурация провайдера аутентификации

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

Таким образом получается, что администратор АП может управлять методом идентификации и аутентификации на АП посредством создания/изменения конфигураций провайдера аутентификации.

Добавление конфигурации провайдеров доступа

1. Зайдите на портал с правами администратора. Перейдите в меню «Администрирование», перейдите в раздел «Настройки безопасности» и нажмите на кнопку «Добавить конфигурацию».
2. Заполните поля «Имя», «Отображаемое наименование», «Выбрать провайдера авторизации», тип хэширования и нажмите на кнопку «Создать».
   
3. Перейдите в редактирование конфигурации по кнопке «Редактировать» в столбце «Операции» строки провайдера.
4. При необходимости измените «Имя» и «Отображаемое наименование» (1), установите галочки (2) и выберите иконку (3), выберите администратора доступа (4), заполните поля (5) — поля меняются в зависимости от выбранного провайдера авторизации. При необходимости настройте группы (6) или серверные переменные (7).

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

Параметры конфигурации провайдера состоят из двух частей: постоянных (общих для всех) параметров и динамического набора полей, который определяется схемой провайдера аутентификации.

Постоянные параметры конфигурации при добавлении конфигурации (раздел «Настройки безопасности»/кнопка «Добавить конфигурацию»):

1. «Имя» — уникальное внутреннее название для конфигурации;

2. «Отображаемое наименование» — уникальное название конфигурации, которое отображается пользователю;

3. «Провайдер аутентификации/авторизации» — выбирается при добавлении конфигурации и не может быть изменён. На выбор следующие провайдеры:
   

   • Password;
   • LDAP for Active Directory;
   • SAML;
   • OAuth2: Client Credentials;
   • OAuth2: Authorization Code;
   • JWT: Decode;
   • Bitrix24.

4. «Тип хеширования» — алгоритм, который используется для обработки пароля пользователя, выбирается при добавлении конфигурации и не может быть изменен;
   

   • Skip hashing — режим, при котором пароль передаётся в открытом виде без хеширования. Используется для интеграции с внешними системами (например, LDAP), которые требуют исходный пароль;
   • SHA-256 — современный алгоритм хеширования с высокой криптостойкостью. Рекомендуется для локальной проверки паролей (например, провайдер «Password») и при поддержке внешней системой;
   • SHA-1-1C — устаревший алгоритм SHA-1 со специфической модификацией (для совместимости с 1С);
   • SAML — технический маркер, означающий, что провайдер использует протокол SAML, и хеширование пароля не применяется (аутентификация выполняется через внешний Identity Provider). Выбирается исключительно для провайдера типа «SAML».

Постоянные параметры конфигурации при редактировании конфигурации (раздел «Настройки безопасности»/кнопка «Редактировать» в строке конфигурации):

1. «Имя» — задано при добавлении, может быть изменено;

2. «Отображаемое наименование» — задано при добавлении, может быть изменено;

3. «Провайдер» — выбирается при добавлении конфигурации и не может быть изменен;

4. «Иконка» — графическое изображение, которое выводится в форме Входа/Выхода пользователя;

5. «Конфигурация по умолчанию» — признак, указывающий на конфигурацию, которая используется для идентификации/аутентификации пользователя, если пользователь не существует в списке пользователей АП или создан без указания конфигурации провайдера;

6. «Показывать форму авторизации» — признак указывает на необходимость отображения формы Входа;

7. «Показывать кнопку логаута» — признак, указывающий на необходимость отображения кнопки логаута (выхода) в разделе «Личный кабинет»;

8. «Администратор доступа» — пользователь, от имени которого выполняются автоматические операции после успешной обработки ответа от службы/сервиса идентификации/аутентификации.

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

Провайдеры аутентификации с динамическим набором полей:

1. «Password»:

   • Необходимо ввести имя пользователя — при включении переключателя в форме Входа будет отображаться поле имени пользователя и будет требоваться ввод имени пользователя;

   • Необходимо ввести пароль — при включении переключателя в форме Входа будет отображаться поле пароля и будет требоваться ввод пароля;

   • Пароль: минимальная длина — установка минимальной длины пароля для пользователей, например, если установить «4», то пароль формата «1234» возможно установить, а формата «123» — нет;

   • Пароль: не должен совпадать с именем — при включении переключателя будет происходить проверка на совпадение пароля и имени пользователя. Установить пароль совпадающий с имением пользователя будет нельзя;

   • Пароль: символы верхнего регистра — если переключатель включен, пароль пользователя должен содержать хотя бы один символ верхнего регистра (A–Z, A–Я).

   • Пароль: символы нижнего регистра — если переключатель включен, пароль должен содержать хотя бы один символ нижнего регистра (строчные буквы, например, a–z, а–я)

   • Пароль: специальные символы — если переключатель включен, пароль должен содержать хотя бы один специальный символ (например, !@#$%^&*)

   • Пароль: символы букв — если переключатель включен, пароль должен содержать хотя бы одну букву (латинскую или кириллическую);

   • Пароль: символы цифр — если переключатель включен, пароль должен содержать хотя бы одну цифру (0–9);

   • Пароль: запрещено повторное использование — если переключатель включен, запрещается устанавливать пароль, который совпадает с одним из ранее использованных пользователем;

   • Аккаунт: время действия (в часах) — установка времени жизни сессии аккаунтов.

2. «Bitrix24» — подробнее про настройку данного провайдера в разделе «Провайдер Bitrix24».

3. «LDAP for Active Directory»:

   • Необходимо ввести имя пользователя — если переключатель включен, на форме входа отображается поле для ввода имени пользователя;

   • Необходимо ввести пароль — если переключатель включен, на форме входа отображается поле для ввода пароля;

   • адрес («host») — обязательное поле. Укажите IP-адрес или DNS-имя сервера LDAP (например, dc.example.com);

   • порт («port») — необязательное поле. Укажите номер порта для подключения к LDAP-серверу. Если значение равно 0 (по умолчанию), используется стандартный порт 389 для незащищенного соединения или 636 — для защищенного (в зависимости от настроек SSL/TLS);

   • база поиска («base_dn») — обязательное поле. Укажите уникальное имя (DN) корня поиска пользователей в LDAP-каталоге. Пример: dc=example,dc=com;

   • база поиска с пользователем («bind_dn») — необязательное поле. Укажите уникальное имя (DN) учетной записи, от имени которой выполняются запросы к LDAP-серверу. Пример: cn=admin,dc=example,dc=com;

   • пароль пользователя («bind_pass») — необязательное поле. Пароль для учетной записи, указанной в поле «база поиска с пользователем». Если bind_dn не задан, это поле игнорируется;

   • не использовать шифрование TLS («skip_tls») — необязательное поле. Переключатель. По умолчанию включен (значение «Вкл.»). Если включен, шифрование TLS при выполнении запросов не применяется;

   • использовать шифрование SSL («use_ssl») — необязательное поле. Переключатель, по умолчанию выключен. Если включен, соединение с сервером LDAP устанавливается по защищенному протоколу SSL (порт 636). Для работы SSL необходимо указать сертификат и ключ в соответствующих полях;

   • SSL-сертификат («ssl_cert») — необязательное поле. Путь и имя файла SSL-сертификата. Используется, если включен переключатель «использовать шифрование SSL». Пример: /etc/ssl/certs/ldap.crt;

   • SSL-ключ («ssl_key») — необязательное поле. Путь и имя файла закрытого ключа для SSL-сертификата;

   • название сервера из SSL-сертификата («server_name») — необязательное поле. Указывает имя сервера (Server Name Indication), которое должно присутствовать в SSL-сертификате. Используется при включенном SSL;

   • NetBIOS имя домена («server_netbios») — необязательное поле. Содержит NetBIOS-имя домена, используемое для автоматического формирования логина в формате ДОМЕН\логин, если не включена настройка «использовать в качестве имени пользователя UPN». Например, при значении HOUSE и введенном логине v.ivanov итоговый логин будет HOUSE\v.ivanov. Если логин уже содержит домен (HOUSE\v.ivanov), добавление не выполняется;

   • пропускать проверку безопасность при использовании SSL («insecure_skip_verify») — необязательное поле. Переключатель. По умолчанию включен (значение «Вкл.»). Если включен, отключается проверка подлинности SSL-сертификата сервера (например, допускается использование самоподписанных сертификатов). Применяется с осторожностью;

   • использовать в качестве имени пользователя UPN («user_principal_name») — необязательное поле. Переключатель. По умолчанию включен (значение «Вкл.»). Если включен, в качестве логина используется атрибут userPrincipalName (например, user@domain.ru). Если выключен, применяется атрибут sAMAccountName (классическое имя учетной записи).

4. JWT: Decode:

   • Маркер доступа: ключ хеширования — секретный ключ для проверки подписи токена. Поле обязательно для заполнения;
   • Маркер доступа: использовать время окончания срока действия — позволяет учитывать срок действия токена из внешней системы. Если переключатель включен, Аналитический портал проверяет срок действия токена, указанный в поле exp (expiration time) в теле JWT. Если токен просрочен, доступ отклоняется, и пользователю необходимо получить новый токен. Если переключатель выключен, срок действия токена не проверяется, и токен считается действительным независимо от его возраста;
   • Маркер доступа: получать имя пользователя из свойства — название поля в токене, из которого извлекается логин пользователя;
   • Маркер доступа: получать ФИО пользователя из свойства — название поля в токене, из которого извлекается полное имя пользователя;
   • Маркер доступа: получать E-mail пользователя из свойства — название поля в токене, из которого извлекается адрес электронной почты;
   • Маркер доступа: получать группы безопасности из свойства (разделённые пробелом) — название поля в токене, содержащего список групп (значения разделяются пробелом);
   • Создавать пользователя — если переключатель включен, при первом входе по токену создается учетная запись пользователя;
   • Устанавливать Профили — если переключатель включен, профили доступа назначаются на основе групп, указанных в токене;
   • Внешний вид: показывать страницу ошибки Входа/Маркера — если переключатель включен, при неверном или просроченном токене отображается сообщение об ошибке;
   • Внешний вид: показывать шапку портала — если переключатель включен, отображается верхняя панель портала;
   • Внешний вид: показывать подзаголовок портала — если переключатель включен, отображается подзаголовок под шапкой;
   • Внешний вид: показывать кнопку вызова главного меню — если переключатель включен, отображается кнопка вызова главного меню;
   • Внешний вид: вызов меню кнопкой/свайпом экрана вправо — если переключатель включен, на мобильных устройствах меню открывается свайпом вправо;
   • Внешний вид: показывать главное меню — если переключатель включен, отображается главное меню;
   • Внешний вид: показывать доступ в интерфейс конструктора — если переключатель включен, в меню отображается пункт для перехода в конструктор отчетов;
   • Внешний вид: показывать шапку с названием отчета — если переключатель включен, отображается заголовок отчета.
   • Устанавливать роли из групп — необязательное поле. При значении «Вкл.» роль назначается по группам, указанным в конфигурации провайдера, при совпадении с группами пользователя из JWT (свойство, указанное в «Маркер доступа: получать группы безопасности из свойства»). При совпадении с несколькими группами назначается роль с наивысшими правами. При значении «Выкл.» роль не меняется.

5. «SAML»:

   • Поставщик учётных записей: Файла метаданных — обязательное поле, содержит наименование и полный путь к файлу, содержащему метаданные поставщика идентификации/аутентификации. Пример: «metadata.xml»;
   • Поставщик учётных записей: способ передачи для Входа (SingleSignOnService) – определяет значение атрибута «Binding» «XML-тэга» «SingleSignOnService», который необходимо использовать в файле настроек, указанного в пункте «1». Если значение настройки не указано, то используется первая запись «XML-тэга» «SingleSignOnService» из файла настроек, указанного в пункте «1». Допустимые поддерживаемые значения:

     • «urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST» — значение по умолчанию;

     • «urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect».

   • Поставщик учётных записей: способ передачи для Выхода (SingleLogoutService) – определяет значение атрибута «Binding» «XML-тэга» «SingleLogoutService», который необходимо использовать в файле настроек, указанного в пункте «1». Если значение настройки не указано, то используется первая завись «XML-тэга» «SingleLogoutService» из файла настроек, указанного в пункте «1».

     Допустимые поддерживаемые значения:

     • «urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST» - значение по умолчанию;

     • «urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect».

   • Поставщик сервиса: Адрес сервера портала — обязательное поле, содержит адрес сервера портала. Пример: «https://dev.modusbi.ru/v1/api»;

   • Поставщик сервиса: Использовать самозаверенный сертификат — не обязательное поле, если значение установлено в «Вкл.», то автоматически создаётся сертификат и ключ для доменного имени используемого в адресе сервера портала;

   • Поставщик сервиса: Файла сертификата — обязательное поле, если сервер портала использует протокол «HTTPS» и значение «Поставщик сервиса: Использовать самозаверенный сертификат» установлено в «Нет», содержит наименование и полный путь к файлу, содержащему сертификат, созданный для доменного имени, используемого в адресе АП.
     Пример: «domain.cert»;

   • Поставщик сервиса: Файла ключа для сертификата — обязательное поле, если сервер портала использует протокол «HTTPS» и значение «Поставщик сервиса: Использовать самозаверенный сертификат» установлено в «Нет», содержит наименование и полный путь к файлу, содержащему ключ для сертификата созданный для доменного имени, используемого в адресе АП.
     Пример: «domain.key»;
   • Поставщик сервиса: Формат идентификатора пользователя (NameIDFormat) – задаёт значение «XML-тэга» из которого необходимо получать формат представления идентификатора пользователя.
     • В соответствии с документацией (§4.2), поддерживаются следующие значения:

       - «urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified» — используется как значение по умолчанию;
       - «urn:oasis:names:tc:SAML:2.0:nameid-format:persistent»;
       - «urn:oasis:names:tc:SAML:2.0:nameid-format:transient»;
       - «urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress»;
       - «urn:oasis:names:tc:SAML:1.1:nameid-format:x509SubjectName»;
       

   • Поставщик сервиса: Создавать пользователя — не обязательное поле, если установлено «Вкл.», то после получения ответа от «Поставщик учётных записей» об успешной идентификации/аутентификации, создаётся новый пользователь в АП с данными полученными из ответа;

   • Поставщик сервиса: Устанавливать Профили — не обязательное поле, если установлено «Вкл.», то после получения ответа от «Поставщик учётных записей» об успешной идентификации/аутентификации, пользователю устанавливаются «Профили» с использованием «Групп для конфигурации провайдера аутентификации»;

   • Поставщик сервиса: Подписать запрос аутентификации — определяет необходимость использования шифрования отправляемых данных;

   • Поставщик сервиса: Проверять действительность сертификата шифрования — перед тем как подписывается запрос аутентификации выполняется проверка срока годности сертификата, используемого для шифрования;

   • Поставщик сервиса: Не проверять подпись — при обработке ответа от поставщика учётных записей не выполняется проверка подписи перед расшифровкой;

   • Поставщик сервиса: Разрешить отсутствие атрибутов — если в результате обработки ответа от поставщика учётных записей не будут найдены некоторые атрибуты в «XML-тэгах», то не возвращать ошибку обработки;

   • Поставщик сервиса: Проверять данные подтверждения субъекта — при обработки ответа от поставщика учётных записей проверяются атрибуты «XML-тэга» «urn:oasis:names:tc:SAML:2.0:assertion Subject»;

   • Использовать имя пользователя в качестве логина — необязательное поле. По умолчанию включено: логин берётся из элемента NameID в SAML-ответе. Если выключено, логин извлекается из атрибутов SAML-ответа согласно настройкам маппинга (поле «Variables»);

   • Загружать автоматически значения серверных переменных по данным провайдера — необязательное поле. Если включено, после успешной аутентификации значения пользовательских серверных переменных автоматически заполняются из атрибутов SAML-ответа (согласно маппингу в поле «Variables») для использования в RLS и запросах. Если выключено, загрузка не выполняется;

   • Устанавливать роли из групп — необязательное поле. При значении «Вкл.» роль назначается по группам, указанным в конфигурации провайдера, при совпадении с группами пользователя из атрибутов SAML-ответа. При совпадении с несколькими группами назначается роль с наивысшими правами. При значении «Выкл.» роль не меняется.

6. «OAuth2.0 Client Credentials»:

   • Необходимо ввести имя пользователя — если переключатель включен, на форме входа отображается поле для ввода имени пользователя;
   • Необходимо ввести пароль — если переключатель включен, на форме входа отображается поле для ввода пароля;
   • Идентификатор приложения — строковое значение (client ID), полученное при регистрации приложения на сервере авторизации;
   • Код приложения — строковое значение (client secret), полученное при регистрации приложения на сервере авторизации;
   • Адрес сервера авторизации — интернет-адрес сервера авторизации (например, https://auth.example.com);
   • Адрес получения маркера доступа — интернет-адрес, на который отправляются запросы для получения маркера доступа (token endpoint);
   • Адрес получения данных пользователя — интернет-адрес, на который с полученным маркером доступа отправляются запросы для получения информации о пользователе (userinfo endpoint);
   • Получать области пользователя (разделённые пробелом) — строка, содержащая названия областей (scopes), запрашиваемых у сервера авторизации. Эти области определяют набор данных пользователя, которые будут использоваться при создании или обновлении учетной записи в АП. Значение по умолчанию: openid name email groups roles;
   • Области для установки профилей (разделённые пробелом) — строка, содержащая названия областей, значения которых будут использоваться для назначения профилей доступа через «Группы конфигурации провайдера аутентификации». Значение по умолчанию: groups roles;
   • Создавать пользователя — необязательное поле. Если переключатель выключен, новые пользователи не создаются, и доступ разрешён только тем, кто уже добавлен в АП вручную. Если переключатель включен: 
     • при первой успешной аутентификации пользователя на сервере авторизации в Аналитическом портале автоматически создаётся новая учётная запись с данными, полученными от сервера (логин, имя, email и другие атрибуты);
     • если учётная запись с таким идентификатором уже существует, её данные обновляются в соответствии с информацией, переданной сервером авторизации.
   • Устанавливать Профили — необязательное поле. Если переключатель включен, то после успешной аутентификации пользователю назначаются профили доступа в соответствии с настройками «Групп конфигурации провайдера аутентификации»;
   • Устанавливать роли из групп — необязательное поле. При значении «Вкл.» роль назначается по группам, указанным в конфигурации провайдера, при совпадении с группами пользователя из данных, полученных с сервера авторизации. При совпадении с несколькими группами назначается роль с наивысшими правами. При значении «Выкл.» роль не меняется.

7. «OAuth2.0 Authorization Code»:

• Необходимо ввести имя пользователя — если переключатель включен, на форме входа отображается поле для ввода имени пользователя;
• Необходимо ввести пароль — если переключатель включен, на форме входа отображается поле для ввода пароля;
• Идентификатор приложения — строковое значение (client ID), полученное при регистрации приложения на сервере авторизации;
• Код приложения — строковое значение (client secret), полученное при регистрации приложения на сервере авторизации;
• Адрес сервера портала — интернет-адрес публикации API Аналитического портала (например, https://ваш-портал.ru/v1/api). На этот адрес сервер авторизации выполняет перенаправление после подтверждения учетных данных пользователя;
• Адрес сервера авторизации — интернет-адрес сервера авторизации (например, https://auth.example.com);
• Адрес получения маркера доступа — интернет-адрес, на который отправляются запросы для получения маркера доступа (token endpoint);
• Адрес получения данных пользователя — интернет-адрес, на который с полученным маркером доступа отправляются запросы для получения информации о пользователе (userinfo endpoint);
• Имя атрибута из которого получать ’login’ пользователя — не обязательное поле. Имя атрибута учетной записи, значение из которого следует использовать в качестве логина пользователя. Если не заполнено, используется атрибут “email”;
• Имя атрибута из которого получать ‘Имя’ пользователя - не обязательное поле. Имя атрибута учетной записи, значение из которого следует использовать в качестве имени пользователя. Если не заполнено, используется атрибут “given_name”;
• Имя атрибута из которого получать ‘Фамилию’ пользователя - не обязательное поле. Имя атрибута учетной записи, значение из которого следует использовать в качестве фамилии пользователя. Если не заполнено, используется атрибут “family_name”;
• Имя атрибута из которого получать ‘Отчество’ пользователя - не обязательное поле. Имя атрибута учетной записи, значение из которого следует использовать в качестве отчества пользователя. Если не заполнено, используется атрибут “middle_name”;
• Имя атрибута из которого получать ‘E-mail’ пользователя - не обязательное поле. Имя атрибута учетной записи, значение из которого следует использовать в качестве адреса электронной почты пользователя. Если не заполнено, используется атрибут “email”;
• Получать области пользователя — строка, содержащая названия областей (scopes), запрашиваемых у сервера авторизации. Области определяют набор данных пользователя, которые будут использоваться при создании или обновлении учетной записи в АП. Имена областей указываются через пробел. Значение по умолчанию: openid name email groups roles;
• Атрибуты для установки профилей — строка, содержащая имена атрибутов (получаемых от сервера авторизации), в которых передается информация о членстве пользователя в группах. Имена атрибутов указываются через пробел. Значения этих атрибутов должны быть массивами строк — названиями групп. Названия групп должны совпадать с именами групп, заданными в «Группах конфигурации провайдера аутентификации». По умолчанию используются атрибуты groups и roles. Пример для Keycloak: чтобы значения атрибутов передавались в нужном формате, при создании атрибута в Keycloak выберите параметры: «Claim JSON Type»: String, «Aggregate attribute»: On;
• Создавать пользователя — необязательное поле. Если переключатель выключен, новые пользователи не создаются, и доступ разрешён только тем, кто уже добавлен в АП вручную. Если переключатель включен: 
  • при первой успешной аутентификации пользователя на сервере авторизации в Аналитическом портале автоматически создаётся новая учётная запись с данными, полученными от сервера (логин, имя, email и другие атрибуты);
  • если учётная запись с таким идентификатором уже существует, её данные обновляются в соответствии с информацией, переданной сервером авторизации.
• Устанавливать Профили — необязательное поле. Если переключатель включен, то после успешной аутентификации пользователю назначаются профили доступа в соответствии с настройками «Групп конфигурации провайдера аутентификации» и значениями атрибутов, указанных в поле «Атрибуты для установки профилей»;
• Устанавливать роли из групп — необязательное поле. При значении «Вкл.» роль назначается по группам, указанным в конфигурации провайдера, при совпадении с группами пользователя из данных, полученных с сервера авторизации. При совпадении с несколькими группами назначается роль с наивысшими правами. При значении «Выкл.» роль не меняется.

Создание/изменение пользователя

Так как в результате идентификации и аутентификации пользователя может возникнуть необходимость создания/изменения учетных данных пользователя АП, а также назначение доступа пользователя к разным частям АП посредством назначения «Профилей», то для каждой конфигурации провайдера аутентификации возможно:

1. Указание необходимости создании пользователя после успешной идентификации и аутентификации.

2. Назначение пользователю «Профилей» (любых типов) на основании полученного «Списка доступа» в результате идентификации и аутентификации в провайдере аутентификации.

Группы для конфигурации провайдера аутентификации

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

Таким образом для каждой конфигурации провайдера аутентификации можно создать свой уникальный «Список доступа», который называется «Группы конфигурации».

Каждый элемент «Группы конфигурации» может быть связан с одним или несколькими существующими «Профилями».

Установка «Профилей» пользователя

Для обеспечения корректного текущего доступа пользователя к частям АП, установка «Профилей» на основании связи с «Группами конфигурации» выполняется каждый раз после успешной идентификации и аутентификации пользователя в провайдере аутентификации, посредством удаления установленных «Профилей» кроме профиля с типом «Личный» и назначения новых «Профилей» на основании «Группами конфигурации».

Пример настройки для Active Directory

На данном этапе предполагается, что установлены и настроены компоненты Active Directory (далее – AD), Active Directory Federation Services (далее – AD FS), Модуль АП.

Шаги настройки AD FS

Для начала необходимо произвести настройки AD FS.
Откройте оснастку «Управление AD FS», перейдите в пункт «Описания утверждений», добавьте новые описания утверждений путем нажатия «Добавить описания утверждений…»:

• у всех описаний утверждений не устанавливайте галочку в пункт «Опубликовать это описание утверждения в метаданных федерации в качестве типа утверждений, которые может отправлять данная служба федерации»;
• Отображаемое имя – modusDepartment, Идентификатор утверждения – Department;
• Отображаемое имя – modusEmail, Идентификатор утверждения – Email;
• Отображаемое имя – modusGroup, Идентификатор утверждения – Group;
• Отображаемое имя – modusID, Идентификатор утверждения – ID;
• Отображаемое имя – modusLogin, Идентификатор утверждения – Login;
• Отображаемое имя – modusName, Идентификатор утверждения – Name;
• Отображаемое имя – modusOrganization, Идентификатор утверждения – Organization;
• Отображаемое имя – modusPatronymic, Идентификатор утверждения – Patronymic;
• Отображаемое имя – modusPosition, Идентификатор утверждения – Position.;
• Отображаемое имя – modusRole, Идентификатор утверждения – Role;
• Отображаемое имя – modusSurname, Идентификатор утверждения – Surname.

Далее перейдите в пункт «Отношения доверия проверяющей стороны». Добавьте новое отношение доверия путем нажатия «Добавить отношение доверия проверяющей стороны…» и следуйте по шагам мастера настройки:

1. Пропускайте пункт «Добро пожаловать!».
2. В пункте «Выбор источника данных» выберите «Ввод данных о проверяющей стороне вручную».
3. В пункте «Указание отображаемого имени» в поле «Отображаемое имя:» впишите ModusBI.
4. В пункте «Выберите профиль» выберите «Профиль AD FS».
5. В пункте «Настройки сертификата» нажмите на кнопку «Обзор» и выберите *.cer файл открытого ключа SSL сертификата шифрования ModusBI.
6. Пропустите пункт «Настройка URL-адреса».
7. В пункте «Настройка идентификатора» в поле «Идентификатор отношения доверия проверяющей стороны:» впишите «https://доменный_адрес_ModusBI/v1/api/login/ID_конфигурации_в_ModusBI» и нажмите на кнопку «Добавить».
8. В пункте «Настроить многофакторную проверку подлинности» выберите «Сейчас не настраивать параметры для этого отношения доверия с проверяющей стороной».
9. В пункте «Выбор правил авторизации выдачи» выберите «Разрешить доступ к этой проверяющей стороне всем пользователям».
10. Пропустите пункт «Готовность для добавления отношения доверия».
11. В пункте «Готово» выберите «Открыть диалоговое окно «Изменение правил утверждений» для этого отношения доверия проверяющей стороны после закрытия мастера».

После настройки нажмите на кнопку«Закрыть».

Продолжите работу в открывшемся окне «Изменение правил утверждения для…».

Далее добавьте новое общее правило путем нажатия на кнопку «Добавить правило…»:

• в пункте «Выберите тип правила» в поле «Шаблон правила утверждения:» выберите «Отправка атрибутов LDAP как утверждений»;
• в пункте «Настройте правило утверждения» укажите:
  • «Имя правила утверждения:» – main;
  • «Хранилище атрибутов:» – «Active Directory»;
  • добавьте строки в поле «Сопоставление атрибутов LDAP типам исходящих утверждений:»:
    • Атрибут LDAP – SAM-Account-Name, Тип исходящего утверждения – modusLogin;
    • Атрибут LDAP – E-Mail-Addresses, Тип исходящего утверждения – modusEmail;
    • Атрибут LDAP – Surname, Тип исходящего утверждения – modusSurname;
    • Атрибут LDAP – Display-Name, Тип исходящего утверждения – modusName;
    • Атрибут LDAP – Organization-Name, Тип исходящего утверждения – modusOrhanization;
    • Атрибут LDAP – Department, Тип исходящего утверждения – modusDepartment.

Завершаем настройку нажатием «Готово».

Добавьте новое правило для пользователей путем нажатия на кнопку «Добавить правило…»:

• в пункте «Выберите тип правила» в поле «Шаблон правила утверждения:» выберите «Отправка членства в группе как утверждения»;
• в пункте «Настройте правило утверждения»:
  • «Имя правила утверждения:» — group.Пользователь;
  • «Группа пользователя:» — нажмите на кнопку «Обзор...» и выберите группу AD (группу необходимо создать или выбрать существующую для управления Ролью или правами пользователя в ModusBI);
  • «Тип исходящего утверждения:» — "modusGroup";
  • «Значение исходящего утверждения:» — Пользователь.

Завершите настройку нажатием на кнопку «Готово».

Добавьте новое правило для аналитиков путем нажатия на кнопку «Добавить правило...»:

• в пункте «Выберите тип правила» в поле «Шаблон правила утверждения:» выберите «Отправка членства в группе как утверждения».
• в пункте «Настройте правило утверждения»:
  • «Имя правила утверждения:» — group.Аналитик;
  • «Группа пользователя:» — нажмите на кнопку «Обзор...» и выберите группу AD (группу необходимо создать или выбрать существующую для управления Ролью или правами пользователя в ModusBI);
  • «Тип исходящего утверждения:» — "modusGroup";
  • «Значение исходящего утверждения:» — Аналитик.

Завершите настройку нажатием на кнопку «Готово».

Добавьте новое правило для администраторов путем нажатия на кнопку «Добавить правило...»:

• в пункте «Выберите тип правила» в поле «Шаблон правила утверждения:» выберите «Отправка членства в группе как утверждения»;
• в пункте «Настройте правило утверждения»:
  • «Имя правила утверждения:» — group.Администратор;
  • «Группа пользователя:» — нажмите «Обзор...» и выберите группу AD (группу необходимо создать или выбрать существующую для управления Ролью или правами пользователя в ModusBI);
  • «Тип исходящего утверждения:» — "modusGroup";
  • «Значение исходящего утверждения:» — Администратор.

Завершите настройку нажатием на кнопку «Готово».
 

Обратите внимание, что «Значение исходящего утверждения» — это, по сути, название группы в конфигурации, создаваемой в Модуле АП. Соответственно в зависимости от потребностей могут создаваться различные правила для групп.

Перейдите к редактированию появившегося отношения доверия путем нажатия, предварительно выбрав его, меню «Свойства»:

1. Перейдите на вкладку «Конечные точки»;
2. Добавьте первую конечную точку путем нажатия на кнопку «Добавить SAML...»:
   • «Тип конечной точки:» — «Получатель проверочного утверждения SAML Assertion»;
   • «Привязка:» — «POST»;
   • Не отмечайте «Установить доверенный URL-адрес в качестве используемого по умолчанию»;
   • «Индекс:» — 0;
   • «Доверенный URL-адрес:» — https://доменный_адрес_ModusBI/v1/api/login;
   • Завершите нажатием на кнопку «ОК».
3. Добавьте вторую конечную точку путем нажатия на кнопку «Добавить SAML...»:
   • «Тип конечной точки:» — «Получатель проверочного утверждения SAML Assertion»;
   • «Привязка:» — «POST»;
   • Отметьте «Установить доверенный URL-адрес в качестве используемого по умолчанию»;
   • «Индекс:» — 1;
   • «Доверенный URL-адрес:» — https://доменный_адрес_ModusBI/v1/api/login?pcid=ID_конфигурации_в_ModusBI;
   • Завершите нажатием на кнопку «ОК».

Настройка ADFS завершена.

Шаги настройки в Модуле АП

Со стороны сервера Модуля АП необходимо скопировать в корневую папку ModusBI следующие файлы:

• файл настроек федерации https://доменный_адрес_ADFS/FederationMetadata/2007-06/FederationMetadata.xml;
• файл отрытого ключа SSL сертификата шифрования ModusBI;
• файл закрытого ключа SSL сертификата шифрования ModusBI.

Для добавления конфигурации провайдера на Аналитическом портале необходимо перейти в меню «Администрирование» / «Настройки безопасности» и нажать на кнопку «Добавить конфигурацию». В появившейся форме заполните поля:

• Имя — уникальное имя конфигурации (пример: AD FS);
• Отображаемое наименование — описание, отображаемое в зависимых полях (пример: AD FS);
• выберите провайдера авторизации —SAML;
• выберите тип хеширования —SHA-256;

Далее нажмите на кнопку «Создать».

После создания, в списке конфигураций необходимо нажать на редактирование конфигурации . Откроется форма редактирования конфигурации.

Заполните поля настроек:

• «Поставщик учётных записей: Файла метаданных (metadata.xml)» — имя файла настроек федерации (пример: FederationMetadata.xml);
• «Поставщик учётных записей: способ передачи для Входа (SingleSignOnService)» — https://доменный_адрес_ADFS/adfs/ls/;
• «Поставщик учётных записей: способ передачи для Выхода (SingleLogoutService)» — https://доменный_адрес_ADFS/adfs/ls/;
• «Поставщик сервиса: Адрес сервера портала (https://demo.modusbi.ru)» — https://доменный_адрес_ModusBI/v1/api;
• «Поставщик сервиса: Использовать самозаверенный сертификат» — Выкл;
• «Поставщик сервиса: Файла сертификата (domain.cert)» — имя файла открытого ключа SSL сертификата шифрования;
• «Поставщик сервиса: Файла ключа для сертификата (domain.key)» — имя файла закрытого ключа SSL сертификата шифрования;
• «Поставщик сервиса: Формат идентификатора пользователя (NameIDFormat)» — urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified;
• «Поставщик сервиса: Создавать пользователя» — Вкл;
• «Поставщик сервиса: Устанавливать Профили» — Вкл;
• «Поставщик сервиса: Подписать запрос аутентификации» — Выкл;
• «Поставщик сервиса: Проверять действительность сертификата шифрования» — Выкл;
• «Поставщик сервиса: Не проверять подпись» — Вкл;
• «Поставщик сервиса: Разрешить отсутствие атрибутов» — Вкл;
• «Поставщик сервиса: Проверять данные подтверждения субъекта» — Выкл;
• «Использовать имя пользователя в качестве логина» — Выкл;
• «Загружать автоматически значения серверных переменных по данным провайдера» — Выкл;
• «Устанавливать роли из групп» — Выкл.

Сохраните настройки нажатием на кнопку «Сохранить».

Далее необходимо создать группы в конфигурации с целью:

• назначения Ролей пользователям;
• управления доступами пользователей.

Редактирование групп доступно по кнопке «Настроить группы» в конфигурации.

Нажмите на кнопку «Настроить группы», откроется список групп, изначально список пуст и необходимо создать группы.

Для начала создайте три группы для определения Ролей пользователя («Администратор», «Аналитик», «Пользователь»). Чтобы создать группу, нажмите на кнопку «Создать группу».

Укажите необходимые значения, например, для группы «Администратор»:

• «Имя группы» — «Администратор»;
• «Отображаемое наименование группы» — «Администратор».

И нажмите на кнопку «Создать».

Повторите создание группы для каждой роли АП.

Далее необходимо каждой группе по управлению ролью указать «ID» роли в метаданных. Для этого нужно подключиться к базе метаданных АП под суперпользователем через любое доступное приложение по управлению базами данных. И заполнить поле «role_id» соответствующим значением. Например, можно выполнить SQL-скрипты:

UPDATE <схема>.provider_group
SET role_id=1
WHERE provider_group_id=<id группы Администратор>

UPDATE <схема>.provider_group
SET role_id=2
WHERE provider_group_id=<id группы Аналитик>

UPDATE <схема>.provider_group
SET role_id=3
WHERE provider_group_id=<id группы Пользователь>

Настройка групп по управлению ролями пользователей завершена.

Далее в зависимости от потребностей создаются группы по управлению доступами пользователей. Создание таких групп ничем не отличается от создания группы для определения ролей. Но для них нет необходимости указывать «ID» роли в метаданных.

Для групп по управлению доступами указываются настроенные профили доступа АП. Для этого нужно перейти в список групп конфигурации («Настройки безопасности/ Редактировать конфигурацию/ Настроить группы»). Нажать на редактирование нужной группы . Откроется форма редактирования группы, где можно назначить необходимые профили доступа.

После назначения профилей доступа нажмите на кнопку «Сохранить».

После настройки конфигурации на начальном окне входа АП, где вводятся логин/пароль, появится соответствующая кнопка.

При нажатии на эту кнопку вход будет выполняться через AD FS.

Настройки взаимодействия AD FS и Модуля АП завершены.

Предполагаемый сценарий организации доступа

1. В интерфейсе AD FS:
   • создают нового пользователя;
   • назначают группы новому пользователю:
     • группу управления ролью;
     • группу управления доступом
2. В интерфейсе АП:
   • пользователь переходит на страницу АП в браузере;
   • нажимает на кнопку входа через AD FS;
   • вводит логин/пароль;
   • происходит вход в систему;
   • пользователю назначаются Роль и Профили доступа в соответствии с выбранными группами AD FS.