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

В системе поддерживаются:

•аутентификация по паролю. При входе в систему у сотрудника запрашивается имя и пароль. Эти учетные данные хранятся в Directum RX, при этом пароль защищен от злоумышленников, так как в базе данных хранится только его хеш;

•внешняя аутентификация. Учетные данные пользователя не хранятся в Directum RX, аутентификация выполняется сторонними средствами: с помощью службы каталогов Active Directory (AD) или внешнего провайдера, например, Active Directory Federation Services (ADFS), Keycloak, PingOne и др. К внешней аутентификации также относятся аутентификация через ЕСИА.

В зависимости от того, где развернута система, доступны разные варианты настройки аутентификации:

Примечание. В таблице под прочими типами аутентификации понимается настройка с использованием внешних провайдеров по протоколам Kerberos, OpenID Connect 1.0, OAuth 2.0, SAML 2.0 и др.

Сквозная аутентификация

Для удобства входа администратор может настроить внешнюю сквозную аутентификацию. В этом случае пользователь проходит аутентификацию сторонними средствами и автоматически получает доступ к Directum RX.

Порядок входа в систему зависит от настроек:

•настроена сквозная аутентификация по протоколу Kerberos. Аутентификация работает только внутри домена. При первом входе на сайт сразу открывается проводник веб-клиента;

•настроена сквозная аутентификация с использованием внешнего провайдера. При первом входе пользователь перенаправляется на страницу аутентификации провайдера. Если аутентификация на стороне внешнего провайдера проходит успешно, открывается проводник веб-клиента;

•сквозная аутентификация не настроена. При каждом входе в систему у пользователя запрашивается имя и пароль. Имя задается в формате, который принят в используемой операционной системе, например <Домен>\<Имя пользователя операционной системы>.

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

Поддерживаемые протоколы для сквозной аутентификации

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

•Kerberos – для работы с ним используется служба каталогов Active Directory (AD), Samba4 или другие службы каталогов, которые зависят от дистрибутива Linux;

•OpenID Connect 1.0 – рекомендуемый протокол, представляет собой слой поверх протокола OAuth 2.0. Протокол OpenID Connect 1.0 работает с провайдерами, которые реализуют спецификацию OpenID Connect Core 1.0 incorporating errata set 1. Например ADFS 2016 и выше, Keycloak, PingOne. Аутентификация по этому протоколу настраивается проще по сравнению с поддерживаемым протоколом SAML 2.0;

•OAuth 2.0 – рекомендуемый протокол, но работает только с ADFS. Прочие провайдеры аутентификации для него не поддерживаются, в том числе Azure Active Directory (Azure AD);

•WS-Federation – устаревший протокол, не рекомендуется использовать. Работает только с ADFS;

•SAML 2.0 – устаревший протокол, не рекомендуется использовать. Вместо него рекомендуется использовать OpenID Сonnect 1.0. Если все же используется протокол SAML 2.0, то внешняя аутентификация поддерживается не только для ADFS, но и для прочих провайдеров аутентификации, если они удовлетворяют условиям:

•корректно реализуют спецификацию Security Assertion Markup Language (SAML) V2.0;

•принимают сообщения в формате HTTP Redirect Binding и отправляют сообщения в формате HTTP POST Binding;

•поддерживают подписание утверждений (SAML-Assertions) в SAML-ответе.

Примечание. В системе поддерживается аутентификация по протоколу OpenID Connect 1.0, и не поддерживаются схожие по названию протоколы OpenID 1.1 и OpenID 2.0. Спецификации этих протоколов существенно отличаются.

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

1.Определитесь, какой тип аутентификации будете использовать.

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

3.Задайте настройки в зависимости от типа аутентификации:

•аутентификация по паролю – задайте политики учетных записей, в которых настраиваются политики блокировки и сложность паролей;

•внешняя аутентификация – рекомендуется установить значение количества неуспешных попыток подключения к домену с запасом, так как при входе пользователя в систему может выполняться несколько попыток подключения. Если в домене настроено ограничение на количество неуспешных попыток подключения и пользователь ввел неверно данные при входе, то учетная запись пользователя в домене может быть заблокирована быстрее, чем ожидается. Может выполняться до четырех попыток подключения, а не одна, как ожидается;

•аутентификация через ЕСИА – настройте, если требуется, чтобы пользователи проходили аутентификацию на технологическом портале ЕСИА;

4.Для несквозной и сквозной аутентификации настройте подключение к контроллеру домена по протоколу LDAP.

5.Если настраивается сквозная аутентификация, задайте настройки для используемого протокола: Kerberos, OpenID Connect 1.0, OAuth 2.0, SAML 2.0, WS Federation.

6.Если сквозная аутентификация настраивается с использованием внешнего провайдера ADFS, то последовательно выполните:

•сертификаты ADFS добавьте в доверенные корневые центры сертификации на стороне веб-сервера;

•на сервере ADFS запустите Диспетчер служб IIS и настройте привязку SSL-сертификата, который используется для работы системы по протоколу HTTPS. При обновлении SSL-сертификата замените его в привязке на сервере ADFS.

© Компания Directum, 2024