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

Print Провайдеры аутентификации
Download Провайдеры аутентификации as PDF
Download Провайдеры аутентификации as ODT
Download Провайдеры аутентификации as TXT

 

Общее описание

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

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

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

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

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

  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-сервисов», которые выполняют перенаправление запроса на сервер авторизации и обрабатывают ответ.

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

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

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

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

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

Постоянные параметры конфигурации:

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

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

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

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

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

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

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

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

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

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

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

  1. «Password»:

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

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

  2. «LDAP for Active Directory»:

    По умолчанию 0.

    Если равен 0, то используется стандартный порт «389» для не защищённого соединения или порт «636» для защищённого соединения (параметры указываются ниже);

    Пример: «dc=example,dc=com»;

    Пример: «cn=username,dc=example,dc=com»;

    Пример: username@example.com.

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

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

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

    • порт («port») — не обязательное поле, содержит порт, который прослушивается службой LDAP на «адрес».

    • база поиска («base_dn») — обязательное поле, содержит уникальное имя базы поиска («DN»), состоящее из одного или нескольких относительных уникальных имён («RDN»).
    • база поиска с пользователем («bind_dn») — не обязательное поле, содержащее уникальное имя базы поиска, содержащее клиента/пользователя.

    • пароль пользователя ( «bind_pass») — не обязательный если не указан «база поиска с пользователем», содержит пароль клиента/пользователя, указанного в «база поиска с пользователем»;

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

    • использовать шифрование SSL («use_ssl») — не обязательное поле, по умолчанию значение «Нет», использовать шифрование SSL при выполнении запросов (параметры указываются ниже);

    • SSL-сертификат («ssl_cert») — не обязательное поле, путь и наименование файла, содержащего SSL-сертификат, используется если «использовать шифрование SSL» установлено в «Да»;

    • SSL-ключ («ssl_key») — не обязательное поле, путь и наименование файла, содержащего SSL-ключ, используется если «использовать шифрование SSL» установлено в «Да»;

    • название сервера из SSL-сертификата («server_name») — не обязательное поле, содержащее название сервера, указанное в SSL сертификате (Server Name Indication), используется если «использовать шифрование SSL» установлено в «Да»;

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

    • пропускать проверку безопасность при использовании SSL («insecure_skip_verify») — не обязательное поле, по умолчанию установлено в «Да», пропускать проверку безопасность при использовании SSL;

    • использовать в качестве имени пользователя UPN («user_principal_name») — не обязательное поле. Указывает порталу, что в качестве логина пользователи будет использовать userPrincipalName (UPN) — имя участника-пользователя. Это новый формат указания имени пользователя для входа в систему, основанный на интернет-стандарте RFC 822. UPN образуется сочетанием имени пользователя с доменным суффиксом, например “ivanov_ii@home.local”. По умолчанию настройка установлена в значение «Да» - использовать UPN. Если настройка указана «Нет», то в качестве логина будет использоваться sAMAccountName свойство учетной записи пользователя.

  3. «SAML»:

    Пример: «metadata.xml»;

    Пример: «https://dev.modusbi.ru/v1/api»;

    Пример: «domain.cert»;

    Пример: «domain.key»;

    Если значение настройки не указано, то используется первая запись «XML-тэга» «SingleSignOnService» из файла настроек, указанного в пункте «1». Допустимые поддерживаемые значения:

    Если значение настройки не указано, то используется первая завись «XML-тэга» «SingleLogoutService» из файла настроек, указанного в пункте «1».

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

    В соответствии с документацией (§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»;
    • поставщик учётных записей: «Файла метаданных» — обязательное поле, содержит наименование и полный путь к файлу, содержащему метаданных поставщика идентификации/аутентификации.
    • поставщик сервиса: «Адрес сервера портала» — обязательное поле, содержит адрес сервера портала.

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

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

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

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

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

    • поставщик учётных записей: «способ передачи для Входа» (SingleSignOnService) – определяет значение атрибута «Binding» «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».

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

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

    • поставщик сервиса: «Формат идентификатора пользователя» (NameIDFormat) – задаёт значение «XML-тэга» из которого необходимо получать формат представления идентификатора пользователя.

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

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

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

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

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

  4. «OAuth2.0 Client Credentials»:

    • «Необходимо ввести пароль» — требует ввода пароля на форме Входа;
    • «Идентификатор приложения» — строковое значение, полученное при регистрации на сервере авторизации («client id»);
    • «Код приложения» — строковое значение, полученное при регистрации на сервере авторизации («client secret»);
    • «Адрес сервера авторизации» — интернет адрес сервера авторизации;
    • «Адрес получения маркера доступа» — интернет адрес куда необходимо отправлять запросы на получение маркера доступа;
    • «Адрес получения данных пользователя» — интернет адрес куда необходимо отправлять запросы с полученным маркером доступа, чтобы получить данные пользователя;
    • «Получать области пользователя» (разделённые пробелом) — строка, содержащая значения, описывающие данные пользователя на стороне сервера авторизации и использующиеся при создании и обновлении пользователя после успешной аутентификации в АП, по умолчанию равно «openid name email groups roles»;
    • «Области для установки профилей» (разделённые пробелом) — строка, содержащая значения, описывающие данные пользователя на стороне сервера авторизации и использующиеся для установки профилей после успешной аутентификации в АП, посредством «Групп конфигурации провайдера аутентификации», по умолчанию равно «groups roles»;
    • «Создавать пользователя» — не обязательное поле, если установлено в «Да», то после успешной авторизации на сервере авторизации, создаётся новый пользователь в АП с данными полученными из ответа;
    • «Устанавливать Профили» — не обязательное поле, если установлено в «Да», то после успешной авторизации на сервере авторизации, пользователю устанавливаются «Профили» с использованием «Групп для конфигурации провайдера аутентификации».

       

  5. «OAuth2.0 Authorization Code»:

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

  • «Создавать пользователя» — не обязательное поле, если установлено в «Да», то после успешной авторизации на сервере авторизации, создаётся новый пользователь в АП с данными полученными из ответа;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Описание настройки провайдера доступа для интеграции АП с Active Directory Federation Services

На данном этапе предполагается, что установлены и настроены компоненты 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.

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

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

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

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

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

  • В пункте «Выберите тип правила» в поле «Шаблон правила утверждения:» выбираем «Отправка атрибутов 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".
    • "Значение исходящего утверждения:" - Администратор.

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

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

  • Перейдем во вкладку "Конечные точки",
  • Добавим первую конечную точку путем нажатия "Добавить SAML...":
    • "Тип конечной точки:" - "Получатель проверочного утверждения SAML Assertion",
    • "Привязка:" - "POST",
    • Не отмечаем "Установить доверенный URL-адрес в качестве используемого по умолчанию",
    • "Индекс:" - 0,
    • "Доверенный URL-адрес:" - https://доменный_адрес_ModusBI/v1/api/login,
    • Завершаем нажатием "ОК";
  • Добавим вторую конечную точку путем нажатия "Добавить 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;
  • «Поставщик сервиса: Создавать пользователя» — Вкл;
  • «Поставщик сервиса: Устанавливать Профили» — Вкл;
  • «Поставщик сервиса: Подписать запрос аутентификации» — Выкл;
  • «Поставщик сервиса: Проверять действительность сертификата шифрования» — Выкл;
  • «Поставщик сервиса: Не проверять подпись» — Вкл;
  • «Поставщик сервиса: Разрешить отсутствие атрибутов» — Вкл;
  • «Поставщик сервиса: Проверять данные подтверждения субъекта» — Выкл;
  • «Использовать имя пользователя в качестве логина» — Выкл;
  •  «Загружать автоматически значения серверных переменных по данным провайдера» — Выкл;
  • «Устанавливать роли из групп» — Выкл.

Сохраняем настройки нажатием «Сохранить»;

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

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

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

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

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

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

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

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

Повторяем для каждой Роли АП.

Обратите внимание, «Имя группы» должно соответствовать значению поля «Значение исходящего утверждения:» в правилах группы AD FS.

Далее необходимо каждой группе по управлению Ролью указать «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:
    1. Создают нового пользователя.
    2. Назначают группы новому пользователю:
      • Группу управления ролью
      • Группу управления доступом
  2. В интерфейсе АП:
    1. Пользователь переходит на страницу АП в браузере
    2. Нажимает на кнопку входа через AD FS
    3. Вводит логин/пароль
    4. Происходит вход в систему
    5. Пользователю назначаются Роль и Профили доступа в соответствии с выбранными группами AD FS.
Обратите внимание, если пользователю не назначить группу определяющую Роль, он авторизуется с ролью «Пользователь».