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

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

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

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

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

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

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

  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. Конфигурация провайдера аутентификации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. «Password»:

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

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

  2. «LDAP for Active Directory»:

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

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

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

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

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

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

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

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

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

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

    • пароль пользователя ( «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 свойство учетной записи пользователя.

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

  3. «SAML»:

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

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

    • поставщик сервиса: «Адрес сервера портала» — обязательное поле, содержит адрес сервера портала.

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

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

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

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

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

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

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

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

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

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

    В соответствии с документацией (http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf, §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».

  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.4. Создание/изменение пользователя

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

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

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

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

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

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

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

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

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

2. Инструкции и пример настройки

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

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

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

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

  1. Добавляем конфигурацию с параметрами:
  1. Заполняем настройки конфигурации — поля «Адрес», «База поиска» и выбираем иконку для конфигурации:
  1. Создаем пользователя. Имя пользователя (UPN) по умолчанию в интернет-стиле, также указываем конфигурацию:
  1. Проверяем доступ на портал указывая логин, пароль и нажимая на иконку созданной конфигурации: