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

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

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

•внешняя аутентификация. Учетные данные пользователя не хранятся в Directum RX, аутентификация выполняется сторонними средствами: с помощью службы каталогов Active Directory (AD), ALD Pro или внешнего провайдера, например, 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), ALD Pro, 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, Blitz Identity Provider. Аутентификация по этому протоколу настраивается проще по сравнению с поддерживаемым протоколом 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, Microsoft Entra ID (ранее Azure AD) и для прочих провайдеров аутентификации, если они удовлетворяют условиям:

•корректно реализуют спецификацию 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, 2025