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

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

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

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 реализована комплексная политика паролей, направленная на обеспечение информационной безопасности. Политика охватывает:

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

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

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

Параметры парольной политики настраиваются в соответствии с [руководством по политике паролей](https://help.globalerp.ru/books/G3AppAdministrationGuide/SNAPSHOT/html/070_%D0%9F%D0%BE%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%D0%B0_%D0%BF%D0%B0%D1%80%D0%BE%D0%BB%D0%B5%D0%B9.html).

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

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

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

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

При создании локальных учетных записей в системе может использоваться [автоматическая генерация временного пароля](https://help.globalerp.ru/books/G3AppAdministrationGuide/SNAPSHOT/html/030_%D0%BF%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B0%D0%B4%D0%BC%D0%B8%D0%BD%D0%B8%D1%81%D1%82%D1%80%D0%B0%D1%82%D0%BE%D1%80.html#id4) в соответствии с действующей парольной политикой.

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

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

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

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

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

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

Параметр `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-синхронизации](https://help.globalerp.ru/books/GlobalUserGuideSystemWide/SNAPSHOT/html/service/0080_%D1%81%D0%B8%D0%BD%D1%85%D1%80%D0%BE%D0%BD%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F.html) и описанием [параметров LDAP в конфигурации базы](https://help.globalerp.ru/books/gs-docs-sphinx/master/reference/configuration/global3_config_xsd/configuration/databases/Database.html#Configuration.Databases.Database.ldap).

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

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

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

1. Пользователь инициирует вход в систему.
2. Аутентификация выполняется внешним провайдером идентификации.
3. На стороне внешнего провайдера могут использоваться федерация пользователей через LDAP, Active Directory или ALDPro, защита от подбора паролей и дополнительные факторы аутентификации.
4. После успешной аутентификации пользователю предоставляется доступ к функциям системы в рамках назначенных ролей и полномочий в Global ERP.

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

Настройка выполняется в соответствии с [руководством по настройке SSO](https://help.globalerp.ru/books/G3SysAdminDoc/SNAPSHOT/html/070_addition/005_openid.html). Настройка второго фактора описана в [документации по настройке 2FA](https://help.globalerp.ru/books/G3SysAdminDoc/SNAPSHOT/html/070_addition/005_openid.html#fa-e-mail).

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

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

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

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

Подробнее см. в разделе [Развертывание сервера приложений GS с сервером авторизации](https://help.globalerp.ru/books/G3SysAdminDoc/SNAPSHOT/html/050_gs-authproxy.html).

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

Для технических подключений к 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-сервисах](https://help.globalerp.ru/books/GlobalServerAppGuide/SNAPSHOT/html/080_addition/serv_serv/070_%D0%B0%D1%83%D1%82%D0%B5%D0%BD%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F.html).

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

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

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

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

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

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

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

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

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