Перейти к основному содержанию
`Ctrl`+`K`

# Идентификация и аутентификация

## Общая модель идентификации и аутентификации

В системе допускается использование следующих способов аутентификации:

1. Локальная аутентификация средствами платформы.

2. Аутентификация через внешний контур единого входа по протоколу OpenID Connect.

3. Аутентификация доменных пользователей с проверкой пароля внешней службой каталогов.

4. Аутентификация через внешний прокси-сервер авторизации.

5. Аутентификация технических подключений к REST- и SOAP-сервисам по схемам `Basic` и `Bearer`, включая постоянные токены и JWT.

При локальной аутентификации проверка учетных данных выполняется средствами Global ERP с применением встроенной политики паролей.

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

При использовании внешнего прокси-сервера аутентификация пользователя осуществляется на стороне сервера авторизации. По результатам успешной аутентификации прокси-сервер формирует JWT-токен и передает его в Global ERP. Система валидирует токен и предоставляет доступ к функционалу в пределах назначенных прав доступа.

Для технических подключений к сервисам используются штатные HTTP-механизмы аутентификации. Для интеграционных сценариев поддерживаются логин и пароль, токены сервера приложений, долгоживущие пользовательские токены и JWT-токены, подписанные пользователем или прокси-пользователем.

Независимо от используемого механизма аутентификации, прикладная модель авторизации и проверка прав доступа реализуются в контуре Global ERP.

## Идентификация пользователей

Идентификация пользователя в Global ERP осуществляется по уникальному идентификатору учетной записи. Указанный идентификатор используется в качестве логина и связывает учетную запись пользователя, механизмы аутентификации, назначенные роли и регистрируемые действия.

При локальной аутентификации идентификатор используется во внутреннем контуре Global ERP.

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

## Локальная аутентификация

При локальной аутентификации пользователь проходит встроенную процедуру аутентификации средствами платформы.

За включение централизованной настройки парольной политики отвечает флаг `bPasswordSettingsInOT` в классе `Btk_Setting`. При включенном флаге параметры задаются для типа объекта пользователя через `Btk_UserPasswordSetting`. При отключенном флаге применяются параметры из класса `Btk_User`.

Внутренняя реализация системы обеспечивает хранение паролей только в виде хэшей `Argon2id`. Исходное значение пароля не сохраняется и не может быть восстановлено по хэшу.

Для контроля повторного использования ранее применявшихся паролей используется сервис истории паролей. Значения предыдущих паролей сохраняются в журнале в хэшированном виде. Это позволяет проверять совпадение нового пароля с ранее использованными без раскрытия их исходных значений.

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

## Парольная политика

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

- требования к минимальной длине и составу пароля;

- историю паролей и запрет повторного использования;

- проверку паролей по словарям и черным спискам;

- сроки действия постоянного и временного пароля;

- уведомления о необходимости смены пароля.

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

- обязательное использование специальных символов;

- обязательное сочетание букв и цифр;

- обязательное использование букв в разных регистрах;

- минимальная длина пароля;

- запрет на повторное использование определенного числа предыдущих паролей;

- минимальный срок действия пароля;

- срок действия постоянного пароля;

- срок действия временного пароля;

- период предварительного уведомления о необходимости смены пароля.

Параметры парольной политики настраиваются в соответствии с руководством по политике паролей.

Рекомендуемая базовая конфигурация предусматривает:

- минимальную длину пароля не менее 8 символов для обычных пользователей и не менее 12 символов для администраторов и привилегированных учетных записей;

- использование не менее 3 категорий символов;

- ограничение срока действия пароля;

- обязательную смену временного пароля при первом входе;

- ведение истории паролей.

Использование простых, предсказуемых и скомпрометированных паролей запрещено.

## Автоматическая генерация паролей

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

Сгенерированный пароль:

- соответствует установленным требованиям сложности;

- формируется с использованием криптографически стойкого генератора случайных значений;

- исключает использование предсказуемых последовательностей и словарных комбинаций;

- отображается администратору однократно в момент создания учетной записи.

После завершения операции создания пользователя повторное отображение исходного значения пароля средствами системы не выполняется.

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

## Защита от подбора паролей

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

Параметр `jTempBlockingForUnsuccessfulLogin` определяет максимально допустимое количество неудачных попыток и продолжительность блокировки в минутах. При превышении установленного лимита система временно блокирует учетную запись.

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

При использовании единого входа защита от подбора паролей дополнительно обеспечивается на стороне внешнего поставщика идентификационных данных. В сценариях OpenID Connect поддерживается настройка параметров механизма обнаружения перебора паролей: `Max login failures`, `Wait increment` и `Quick login check`.

## Защита сеансов

Система обеспечивает автоматический разрыв сеанса при отсутствии активности пользователя.

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

Управление сеансами распространяется на пользовательские подключения и применяется как элемент общего контура идентификации, аутентификации и защиты доступа.

### Завершение сеанса

Сеанс работы пользователя может быть завершен по одному из следующих оснований:

- По инициативе пользователя — через штатную функцию выхода из системы.

- По таймауту бездействия — при отсутствии действий пользователя в течение интервала, заданного параметром `clientTimeout` в конфигурационном файле.

- По инициативе администратора — через функции администрирования активных сессий.

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

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

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

## Аутентификация через LDAP, Active Directory и ALDPro

Global ERP поддерживает аутентификацию пользователей через внешние службы каталогов, включая LDAP-каталоги, Active Directory и ALDPro. Для этого в конфигурации сервера приложений настраивается подключение к каталогу, а для базы данных активируется режим `authenticationType="ldap"`.

В указанном режиме проверка пароля пользователя не выполняется средствами платформы, а передается внешней службе каталогов для подтверждения подлинности.

Параметры парольной политики для доменных пользователей определяются корпоративной службой каталогов предприятия, включая групповые политики Active Directory или аналогичные политики LDAP/ALDPro. Смена пароля пользователя выполняется средствами операционной системы с пользовательского рабочего места, в том числе при очередном входе, если такая смена требуется политикой службы каталогов. Global ERP в этом сценарии не хранит доменный пароль и не управляет его сменой, а использует результат проверки учетных данных, выполненной службой каталогов.

Параметры подключения к службе каталогов задаются в конфигурации `<ldap .../>` и включают, в частности, адрес LDAP-сервера и домен. Данный режим применяется для аутентификации доменных пользователей при сохранении прикладной модели ролей внутри Global ERP.

Система поддерживает синхронизацию пользователей из внешних служб каталогов. Для этого используется сервис LDAP-синхронизации, настраиваемый в модуле `Btk`. Сервис обеспечивает загрузку пользователей из указанных доменов, фильтрацию по группам и выбор режимов синхронизации в соответствии с выбранным сценарием. При необходимости к системному имени пользователя может быть добавлен домен в формате `User@Domain`.

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

Настройка выполняется в соответствии с инструкцией по LDAP-синхронизации и описанием параметров LDAP в конфигурации базы.

## Процесс аутентификации с помощью единого входа

Поддержка единого входа реализована в компоненте Global Server через протокол OpenID Connect с использованием внешнего поставщика идентификационных данных. Настройка выполняется на стороне сервера приложений посредством блока `<openId>` в файле `global3.config.xml`.

Процесс аутентификации при использовании единого входа включает следующие этапы:

1. Пользователь инициирует вход в систему.

2. Аутентификация выполняется внешним провайдером идентификации.

3. На стороне внешнего провайдера могут использоваться федерация пользователей через LDAP, Active Directory или ALDPro, защита от подбора паролей и дополнительные факторы аутентификации.

4. После успешной аутентификации пользователю предоставляется доступ к функциям системы в рамках назначенных ролей и полномочий в Global ERP.

Во внешнем SSO-контуре могут использоваться корпоративные службы каталогов и механизмы многофакторной аутентификации, включая одноразовые пароли и приложения-аутентификаторы. Настройка второго фактора осуществляется на стороне поставщика идентификационных данных и может включать одноразовые коды, подтверждения по электронной почте, SMS, приложения-аутентификаторы и другие поддерживаемые провайдером методы.

Настройка выполняется в соответствии с руководством по настройке SSO. Настройка второго фактора описана в документации по настройке 2FA.

## Аутентификация через внешний прокси-сервер авторизации

Global ERP поддерживает работу с внешним сервером авторизации `gs-authproxy` и совместимыми внешними сервисами авторизации. Данный режим применяется в сценариях, когда требуется вынести первичную аутентификацию пользователей во внешний контур, например для предоставления доступа пользователям внешних организаций к выделенному функционалу.

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

В этом режиме внешний прокси обеспечивает первичную аутентификацию и выдачу токена, а Global ERP — проверку токена, сопоставление учетной записи и применение полномочий.

Подробнее см. в разделе Развертывание сервера приложений GS с сервером авторизации.

## Аутентификация технических подключений и сервисов

Для технических подключений к REST- и SOAP-сервисам поддерживаются HTTP-схемы аутентификации `Basic` и `Bearer`.

При `Basic`-аутентификации клиент передает в запросе имя пользователя, пароль и имя базы. Имя пользователя и пароль кодируются в Base64 и передаются через заголовок `Authorization` в формате `Basic {Base64Cred}`, где `{Base64Cred}` — строка `user:password`. Имя базы может передаваться через сегмент URL, заголовок `Database` или HTTP-параметр `Database`. При отсутствии указания используется база по умолчанию, определяемая конфигурацией `global3.config.xml`.

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

Поддерживаются следующие варианты JWT-аутентификации:

- `UserHash` — долгоживущий токен пользователя;

- `UserCrt` — JWT, подписанный пользователем;

- `ProxyCrt` — JWT, подписанный прокси-пользователем для выполнения действий от имени другого пользователя.

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

Подробнее см. в разделе Аутентификация в REST/SOAP-сервисах.

## Аутентификация устройств

Для устройств могут использоваться механизмы аутентификации с применением сертификатов и дополнительных атрибутов идентификации. В зависимости от архитектуры внедрения может использоваться интеграция с внешними системами управления устройствами класса `MDM`.

Использование таких механизмов допускается только в рамках штатного контура безопасности и не отменяет требований к сопоставлению устройства, учетной записи и назначенных прав доступа.

## Источники учетных данных

В зависимости от архитектуры конкретного внедрения источником учетных данных могут выступать:

- локальная учетная запись Global ERP;

- внешняя служба каталогов LDAP, Active Directory или ALDPro;

- внешний провайдер идентификации в SSO-контуре;

- внешний прокси-сервер авторизации, выдающий JWT;

- учетные данные или токены, используемые для подключения к техническим сервисам.

Независимо от источника первичной аутентификации, учетные записи пользователей хранятся в базе данных Global ERP. Назначение ролей и проверка прав выполняются в контуре системы и описаны в разделе «Управление доступом».

## Требования к расширениям и функциональному дизайну

Расширения и прикладные доработки обязаны использовать штатный контур идентификации и аутентификации Global ERP. Реализация изолированных механизмов входа, параллельных хранилищ паролей или обходных сценариев аутентификации не допускается. Аутентификация расширений должна выполняться одним из штатных способов, предусмотренных платформой.