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

Домен аутентификации и авторизации охватывает все механизмы входа в 1Форму: от встроенной формы с логином и паролем до корпоративных протоколов LDAP, SAML, OAuth/OIDC и RADIUS. Архитектура построена на двух уровнях — сервисы подключения к внешним системам и провайдеры настроек входа, включая второй фактор и привязку к группам. После успешной аутентификации система выдаёт сессионный токен, а все входы фиксируются в журнале. Домен также включает политики паролей, защиту от подбора, персональные токены доступа (PAT), самостоятельную регистрацию и настройку страницы авторизации.

Обзор

Система аутентификации 1Формы поддерживает множество способов входа: от встроенной формы с логином/паролем до корпоративных протоколов (LDAP, SAML, OAuth/OIDC, RADIUS). Аутентификация построена на двухуровневой архитектуре: сервисы (подключение к внешним системам) и провайдеры (настройки входа, второй фактор, привязка к группам). Каждый провайдер ссылается на один сервис; для каждого сервиса допускается только один активный провайдер.

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

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

Начало работы и вход в систему

1Форма — веб-приложение, работа ведется в интернет-браузере, установка специального ПО не требуется. Для входа пользователь вводит в адресной строке браузера электронный адрес системы своей компании. Адрес выдается администратором; типовой вид — https://1forma.yourcompany.ru.

Учетные данные пользователя (логин и пароль) выдаются администратором тем способом, который допустим внутри компании: по E-mail, устно, в конверте и т.п. Самостоятельное восстановление учетных данных возможно только при Forms-авторизации.

Процедура входа зависит от того, настроена ли синхронизация с Active Directory: при настроенной синхронизации выполняется сквозная Windows-авторизация, без нее — Forms-авторизация с вводом логина и пароля.

Если в пароле учетной записи Active Directory символы < и > расположены в порядке < .. >, при входе возникает ошибка. Обратная последовательность > .. < обрабатывается корректно.

Способы входа на форме авторизации

Форма авторизации показывает пользователю один или несколько способов входа. Поддерживаются:

Способ	Что видит пользователь
Логин и пароль	Классический вход по учётным данным
По номеру телефона	Поле телефона → 4-значный SMS-код
По email	Поле email → 4-значный код на почту
Через внешнего провайдера	Отдельный экран с кнопками провайдеров (AD, SAML, OAuth и т.д.); форма логин/пароль скрыта, переход к ней по ссылке

Набор способов, способ по умолчанию, разрешена ли регистрация, для каких устройств виден каждый способ (веб / мобильный / все), ссылки на пользовательские соглашения и срок жизни кодов подтверждения настраивает администратор. Администратор также может полностью запретить вход по email (тогда пользователь может войти только по логину).

Подробности настройки — в admin.md § «Настройка типов входа» и admin.md § «Политики входа».

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

Провайдер — основная сущность управления внешней аутентификацией. Поддерживаемые типы провайдеров: ActiveDirectory, SAML, OpenLDAP, Radius, OAuth. Каждый провайдер настраивается набором параметров:

Параметр	Назначение
Тип провайдера	Один из пяти поддерживаемых протоколов
Сервис аутентификации	Ссылка на ранее созданный сервис (одноименного типа)
По умолчанию	Провайдер отображается выбранным в списке «Вход в» на странице авторизации
Активен / Скрыт	Управление видимостью на странице авторизации
Ссылка для восстановления пароля	Кастомная ссылка вместо стандартной при нажатии «Забыли пароль?»
Второй фактор	Настройка MFA: нет / SMS / Email / Сервис (Multifactor) / Telegram
Группы	Ограничение доступа к провайдеру по группам пользователей

Если провайдер один — выпадающий список «Вход в» не показывается, аутентификация идет напрямую через 1Форму. При нескольких провайдерах без флага «По умолчанию» по умолчанию выбирается «Первая Форма» (встроенная аутентификация).

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

Ошибки аутентификации через AD и OpenLDAP фиксируются в журнале ошибок системы.

Встроенная аутентификация (Forms-авторизация)

Базовый механизм: пользователь вводит логин и пароль, система проверяет их в собственной базе. При включенной настройке «Брать пароль из AD» (общие настройки) пароль проверяется в Active Directory, но сам механизм формы остается Forms-авторизацией.

Для мобильных приложений доступна двухшаговая авторизация: после ввода пароля приходит SMS/push-код, подтверждение которого завершает аутентификацию.

На форме входа пользователь может выбрать язык интерфейса — по клику на иконку выбора языка раскрывается список доступных языков. Язык можно сменить и позднее, уже после входа в систему.

Восстановление пароля

Если пользователь не помнит логин и/или пароль и в компании используется Forms-авторизация, в окне авторизации он нажимает ссылку «Забыли пароль?» и в открывшемся окне выбирает один из трех способов восстановления.

Способ	Что вводит пользователь
По Email — «Получить код восстановления по Email»	E-mail и код безопасности с картинки (капча)
По SMS — «Получить код восстановления по SMS»	Номер телефона и капчу
По логину — «Получить код восстановления по логину»	Логин, выбор канала доставки кода (Email или SMS) и капчу

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

После заполнения полей пользователь нажимает кнопку Отправить — в течение нескольких минут код восстановления приходит на указанный адрес или номер (если код не получен, нужно обратиться к администратору). Затем открывается следующее окно восстановления — его также можно открыть сразу по ссылке «У меня есть код восстановления» на начальном окне. Поле E-mail или Телефон заполняется системой автоматически; пользователь вводит полученный код, нажимает Далее и регистрирует новый пароль.

При синхронизации с Active Directory для смены пароля дополнительно требуется ввод текущего пароля. При Windows-авторизации самостоятельная смена пароля невозможна — нужно обращаться к администратору.

Смена пароля при истечении срока

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

1. Превышена сумма даты установки пароля и срока действия пароля из общих настроек.
2. При создании пользователя активирован флаг «Сменить пароль при входе».
3. Пользователь не входил в систему более 30 дней.

Под полем подтверждения пароля показывается надпись «Пароль не совпадает» (красным), если значения различаются; при совпадении становится активна кнопка Сохранить. После сохранения нового пароля система автоматически выполняет повторную авторизацию с обновленными учетными данными.

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

Аутентификация через доменную инфраструктуру Microsoft. Требования: адрес домена, системная учётная запись, сервер приложений в домене (или DNS-зона на адаптере). Параметры сервиса: домен, признак корня леса, логин/пароль доступа к AD (опционально, если пользователь приложения имеет нужные права). Для лесов AD с одноимёнными учётными записями администратор может переключить режим работы с каталогом — подробности в admin.md § «Active Directory». При настроенной синхронизации с Active Directory выполняется сквозная Windows-авторизация: учетные данные для входа в Windows автоматически применяются и для входа в 1Форму, пользователю не нужно запоминать дополнительный логин и пароль. Вход через Active Directory возможен также по сертификату SSL.

Аутентификация через OpenLDAP и RADIUS

OpenLDAP обеспечивает аутентификацию через LDAP-каталог (не AD). Параметры подключения: адрес сервера, DN-путь, DN-привязки, пароль. SSL-подключение настраивается администратором — см. admin.md § «OpenLDAP».

RADIUS обеспечивает аутентификацию через RADIUS-сервер. Минимальная конфигурация: IP-адрес сервера, порт, shared secret. Оба протокола подходят для организаций, где нет инфраструктуры Active Directory, но есть централизованный каталог или RADIUS-сервер для сетевой аутентификации.

Аутентификация через SAML

Протокол SSO на основе XML-утверждений. Используется для интеграции с ADFS и другими SAML-провайдерами. Вся коммуникация между 1Формой и внешним провайдером проходит через браузер пользователя (запросы и перенаправления).

Что нужно для работы: настроенный сервис SAML на стороне 1Формы (метаданные IdP, сертификат для подписи, способ сопоставления пользователей) и зарегистрированная 1Форма как Service Provider у внешнего IdP. Поддерживается автосоздание учётных записей из атрибутов SAML — администратор задаёт правила сопоставления полей профиля.

Полная пошаговая настройка (включая параметры сервиса, генерацию сертификатов, регистрацию в IdP и маппинг атрибутов) — в admin.md § «SAML (ADFS)».

Аутентификация через OAuth 2.0 / OpenID Connect

Протокол аутентификации через внешний IdP (например, KeyCloak). Поддерживается стандартный поток авторизации OAuth 2.0 с получением ID-токена по OpenID Connect. Способы сопоставления пользователя с учётной записью 1Формы, которые может выбрать администратор:

• по справочнику (категории);
• по произвольному атрибуту профиля;
• по учётной записи внешнего сервиса;
• по никнейму;
• по SID.

Полная настройка сервиса OAuth/OIDC, регистрация провайдера и параметры маппинга — в admin.md § «OAuth / OIDC».

Windows-аутентификация и первый вход

Поддерживается прозрачная аутентификация через Windows. При настроенной синхронизации с Active Directory учетные данные для входа в Windows автоматически применяются и для входа в 1Форму — пользователю не нужно запоминать дополнительный логин и пароль. Вход через Active Directory возможен также по сертификату SSL.

Для первого входа пользователь после загрузки рабочего стола Windows выбирает ярлык приложения (если он создан) или вводит адрес приложения в браузере. Если в компании требуется согласие на обработку персональных данных, при первом входе показывается экран с текстом соглашения — пользователь включает параметр «Предоставляю согласие...» и нажимает кнопку ОК.

В общих настройках приложения существует параметр «Страница редиректа несуществующих пользователей» — применяется только для Windows-аутентификации.

Многофакторная аутентификация (MFA)

Второй фактор настраивается на уровне провайдера аутентификации. Поддерживаются четыре метода: SMS, Email, внешний сервис Multifactor и Telegram. Каждый метод требует предварительной настройки соответствующего провайдера или бота и выдачи специального права группе пользователей.

SMS. Специальное право группы «Подтверждение пароля по SMS (при входе)». На мобильный номер из профиля отправляется 5-значный код. Требуется настроенный SMS-провайдер. Также доступно право «Подтверждение пароля по SMS (при смене)» — для подтверждения смены пароля.

Email. Специальное право группы «Двухфакторная аутентификация по Email». На почтовый адрес из профиля отправляется цифровой код. Требуется настроенный SMTP и почтовый ящик для системных писем.

Multifactor (сервис). Интеграция с внешней системой MULTIFACTOR (с версии 2.256). Процесс: пользователь вводит логин/пароль, при успехе система запрашивает MULTIFACTOR, пользователя перенаправляют на страницу второго фактора (мобильное приложение, пуш, голосовой звонок и т.п.), после подтверждения возвращается на 1Форму и попадает в систему. Полная настройка (создание сервиса, регистрация в кабинете MULTIFACTOR, конфигурация сертификата) — в admin.md § «Multifactor».

Telegram. Специальное право группы «Двухфакторная аутентификация через Telegram». Требуется настроенный Telegram-бот. Процесс: после ввода логина/пароля пользователя перенаправляют в Telegram для подтверждения; после подтверждения он возвращается в 1Форму уже залогиненным. Настройка: администратор создаёт бота в Telegram (через стандартный @BotFather), регистрирует его реквизиты в сервисе аутентификации 1Формы и выдаёт спецправо группе. Подробности — в admin.md.

Политики паролей для веб-входа

Настройки в разделе «Настройки требований к паролям» общих настроек:

Параметр	Описание
Срок действия пароля (дни)	При истечении — принудительное перенаправление на форму смены (только Forms-авторизация)
Минимальная / Максимальная длина	Ограничения длины
Спец. символ обязателен	Минимум один символ, не являющийся буквой/цифрой
Заглавная буква обязательна	Минимум одна прописная буква
Запрет совпадения с предыдущим	Блокировка повторного использования паролей
Запрет совпадения с логином	По умолчанию разрешено, можно запретить
Длина истории паролей	Количество запоминаемых предыдущих паролей
Проверка на дату рождения	Запрет паролей, содержащих дату рождения
Минимальная длина последовательности	Обнаружение клавиатурных (qwerty, йцукен) и алфавитных последовательностей
Минимальная длина повторяющегося паттерна	Обнаружение повторений типа «qweqwe»

Срок действия кода для восстановления пароля настраивается отдельно (в днях).

Пароли для самостоятельной регистрации

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

Полный перечень настраиваемых полей и пример конфигурации — в admin.md § «Самостоятельная регистрация».

Мобильные политики паролей и восстановление

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

• Пароль не обязателен
• 4 цифры
• 6 цифр
• Буквенно-цифровой (с регулярным выражением)

При пересечении групп с разными политиками действует наиболее строгая. Специальное право «Запрещено пользоваться восстановлением пароля» блокирует самостоятельное восстановление пароля для группы пользователей, которым назначена данная политика. Это право применяется независимо от типа мобильной политики и распространяется как на Forms-авторизацию, так и на вход через внешних провайдеров.

Защита от подбора и блокировки

Общие настройки приложения содержат три параметра защиты:

Параметр	Действие
Максимальное число попыток логина до блокировки	Полная блокировка учетной записи (разблокировка — через администратора)
Максимальное число попыток логина пользователя до капчи	Капча после N неудачных попыток для конкретного пользователя
Максимальное число попыток логина с IP до капчи	Капча/блокировка IP после N неудачных попыток с одного адреса

При работе через балансировщик нагрузки администратор должен настроить проброс реальных IP клиентов с прокси/балансировщика — иначе счётчик попыток «с одного IP» увидит только адрес самого балансировщика и заблокирует всех пользователей сразу. Настройка — в admin.md § «Защита от брутфорса».

Геолокация при входе: по умолчанию запрашивается при каждом первом входе. Настройка «Запрашивать геолокацию только после неудачного логина» ограничивает запрос только случаями неудачных попыток.

Отзыв именной лицензии во время сессии

С версии 2.268.329 отзыв именной лицензии у уже авторизованного пользователя вступает в силу в течение минуты, а не «висит» до конца жизни access-токена (раньше — до ~5 часов). Логика:

• В активной сессии система раз в минуту перепроверяет именную лицензию пользователя. Между перепроверками доступ сохраняется по выданному ранее токену — это сделано осознанно, чтобы перепроверка не нагружала каждый запрос.
• Если на момент очередной перепроверки лицензии уже нет, ближайший запрос пользователя получает отказ (HTTP 402), а веб-клиент редиректит на страницу входа (обработка 402 в Auth401Interceptor — с 2.268.338; до этой версии браузер «зависал в вечной загрузке»). Войти снова без лицензии нельзя — на форме логина уже работает обычная проверка лицензий.
• Отказ фиксируется в журнале действий (ActionLog) с указанием причины, идентификатора пользователя, IP и хоста — чтобы администратор мог отследить факт обрыва сессии по лицензии.
• Сценарий перевоплощения (impersonation) и support-аккаунты не затронуты: support-аккаунты доступ сохраняют, перевоплощение работает по правилам своей задачи.
• Пользователи с действующей лицензией продолжают работу без прерываний — перепроверка обновляет внутренний таймер при каждом успешном гранте.

Интервал перепроверки (1 минута) в конфигурацию не выносится — этого достаточно, чтобы отзыв вступал в силу за минуты, а не часы, и при этом перепроверка не нагружала per-request путь.

Самостоятельная регистрация

Самостоятельная регистрация пользователей включается администратором: задаётся набор полей формы и допустимые способы (по телефону / по email / по нику).

Правила автозаполнения: - одно из полей «Телефон», «Email» или «Ник» — обязательно; - при заполнении ника обязателен и пароль; - если ник не указан — система автозаполняет его из телефона или email; - если не указано отображаемое имя — оно собирается из «Имя Фамилия» или ника; - при регистрации по телефону или почте поле-источник автоматически заполняется и скрывается.

Администратор может настроить регистрационную ссылку с предзаполненными значениями — пользователь переходит по ней и попадает на форму с уже заполненными полями. Полная настройка — в admin.md § «Самостоятельная регистрация».

Процесс регистрации

Регистрация проходит по шагам:

1. На форме авторизации — кнопка «Регистрация».
2. Выбор способа верификации: по номеру телефона или по email.
3. Валидация ввода:
4. Email — проверка стандартного формата (@, доменная часть). При ошибке: «Введите Email».
5. Телефон — маска +7 XXX XXX XX XX. При ошибке: «Введите телефон».
6. Кнопка Далее → ввод полученного кода (SMS или email).
7. Дальше:
8. Если пользователь уже был зарегистрирован — перенаправление на стартовую страницу.
9. Если пользователь новый — форма регистрации с обязательными полями (набор настраивается администратором).

Требования к паролю и расширенная политика безопасности при регистрации

Требования отображаются при фокусе на поле пароля: серым до ввода, красным при невыполнении, зелёным при выполнении. Подтверждение пароля имеет онлайн-индикацию: «Пароль не совпадает» (красным) / «Пароль совпадает» (зелёным). Редактирование любого из двух полей запускает повторную проверку. Кнопка «Регистрация» на финальном шаге активна только когда все обязательные поля заполнены корректно.

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

SSO (Single Sign-On)

SSO позволяет один раз войти во внешнюю систему (Active Directory, ADFS, KeyCloak) и автоматически попадать в 1Форму без повторного ввода логина и пароля. Поддерживаемые протоколы — SAML и OAuth/OpenID Connect.

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

Возврат на исходную страницу при входе через внешнего провайдера

Если пользователь переходит по прямой ссылке на задачу или другую страницу системы, не будучи авторизованным, SPA сохраняет исходный URL и редиректит его на форму входа. После входа через SAML (ADFS) система возвращает пользователя на исходную страницу, а не на главную. На OAuth-провайдерах поведение зависит от того, как бэк переносит returnUrl через state — нужна отдельная проверка для каждого провайдера. При обычном входе по логину и паролю возврат на исходную страницу работает через SPA-логику и описанным фиксом не затрагивается.

Режим перевоплощения

Администраторы по умолчанию имеют доступ к перевоплощению — работе в системе от имени другого пользователя. Спецправо «Запретить перевоплощение» блокирует перевоплощение для группы; запрещено назначать группе «Администраторы». Администратор с этим правом не может деактивировать его и редактировать состав своей группы. Право не переходит заместителю в период замещения. Удаление из группы с этим правом через смарт-действие «Удалить пользователя из групп» запрещено. Перевод в группу без этого права возможен только администратором, у которого право на перевоплощение сохранено.

Персональные токены доступа (PAT)

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

Токен показывается единожды и в системе не хранится в открытом виде: при генерации полная строка токена показывается пользователю один раз — в системе сохраняется только защищённая контрольная сумма, восстановить токен невозможно. Пользователь обязан сохранить строку токена самостоятельно; повторно получить её нельзя. Токен передаётся в HTTP-заголовке 1F-Pat при вызове API. Технические детали транспорта (в т.ч. для realtime-подключений) — в admin.md § «Аутентификация API-запросов». Пользователь, аутентифицированный через PAT, работает с теми же правами, лицензиями и ограничениями, что и при входе по логину/паролю. Рекомендация: выдавать PAT на специального сервисного пользователя в отдельной группе с ограниченными правами.

Администратор может задать максимальное число активных токенов на пользователя и максимальный срок жизни токена. По умолчанию — 10 токенов и 365 дней. Подробности — в admin.md § «Personal Access Tokens».

Интерфейс управления токенами

Страница «Токены доступа» доступна в персональном меню пользователя (между пунктами «Канбан» и «Диск»). Отображается администраторам и пользователям со спецправом «Генерация PAT».

Интерфейс страницы:

• Заголовок «Токены доступа» с фильтром по статусу (по умолчанию — «Активные»).
• Кнопка «+ Создать токен» в правом верхнем углу.
• Таблица столбцов: Название, Токен (маскированный, виден префикс + ****), Статус (Активен/Отозван/Истёк), Активен до, Дата создания, Отозвать (×).
• Пустая таблица показывает «Нет данных».

Создание токена:

1. Кнопка + Создать токен → модальное окно «Создание токена».
2. Поля: Название (произвольное), Срок действия (по умолчанию — настроенный администратором максимум).
3. Кнопка Создать (или Отмена).
4. Открывается диалог «Токен создан»: предупреждение на жёлтом фоне (токен виден один раз), скрытое значение токена (раскрывается иконкой глаза), кнопка копирования.
5. После закрытия диалога новая запись появляется в таблице.

Каждый пользователь, включая администратора, может выпустить токен только для своей учётной записи; выдать токен от имени другого через интерфейс нельзя.

Отзыв токена: кнопка × в колонке «Отозвать» — токен перестаёт работать сразу.

Текущие ограничения PAT

У текущей реализации персональных токенов доступа есть несколько ограничений, которые планируется снять в будущих версиях:

• Области действия (scopes) не реализованы — все токены работают с полным набором прав пользователя. Планируется к доработке по бизнес-потребностям.
• Логирование входов по PAT — отдельной записи о входе по PAT в журнале нет; фиксируются только дата и IP последнего использования у самого токена.
• Очистка просроченных или отозванных токенов не автоматизирована — записи остаются в системе как история.

MCP-имперсонация (перевоплощение через MCP)

С версии 2.268.356 (задача #2096971, коммит 5a199942fb) PAT-токены поддерживают имперсонацию при работе через MCP-интерфейс (Model Context Protocol). Это позволяет внешнему AI-агенту, подключённому по MCP, выполнять действия от имени другого пользователя, используя PAT владельца интеграции.

Как это работает:

• Имперсонация активируется только на маршрутах /mcp* (проверка StartsWith("/mcp", StringComparison.OrdinalIgnoreCase)).
• В запросе должен быть заголовок 1f-real-user-id с UserId целевого пользователя (того, от имени которого выполняется действие).
• Владелец PAT (тот, чей токен используется) становится OldUserId — это сохраняется для аудит-трэйла.
• В контексте запроса UserId подменяется на таргет, OldUserId фиксирует владельца PAT.

Правила и ограничения (fail-closed):

• Только MCP — на обычных API-маршрутах заголовок 1f-real-user-id игнорируется.
• Fail-closed — если имперсонация не удалась (нет прав, пользователь не найден, попытка эскалации), запрос отклоняется с ошибкой аутентификации (401). Нет фоллбэка на владельца PAT.
• Анти-эскалация — встроенная проверка права на имперсонацию:
• god (администратор платформы) → может имперсонировать кого угодно;
• non-god → никогда не может имперсонировать god;
• остальные пары → требуется спецправо group-on-group Impersonate (то же право, что и для обычного перевоплощения через UI, см. раздел «Режим перевоплощения»). Специальных прав под MCP не вводилось.
• Цепочечная имперсонация запрещена — OldUserId всегда указывает на владельца PAT, нельзя «перепрыгнуть» дальше.
• Аудит — пара UserId (таргет) / OldUserId (владелец PAT) доступна в логах и ActionLog для отслеживания, кто и от чьего имени действовал.

Рекомендация: для MCP-интеграций заводите отдельного сервисного пользователя с PAT и минимально необходимыми правами, выдавайте группе этого пользователя спецправо Impersonate на целевые группы.

Согласие на обработку персональных данных

При включённой настройке «Требовать подтверждение согласия на обработку перс. данных» (общие настройки) система при входе проверяет, давал ли пользователь согласие. Если согласие требуется и пользователь его ещё не давал — в новом SPA открывается блокирующее окно с текстом соглашения. Окно нельзя закрыть крестиком, клавишей Escape или кликом по фону: пользователь должен выбрать одно из двух действий.

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

Окно согласия не показывается:

• в режиме перевоплощения (impersonation);
• сервисным учётным записям (Users.IsService = 1);
• системному пользователю (UserId = 3).

С версии 2.268.339 согласие собирается нативно в SPA через PersonalDataConsentService + personal-data-consent.component; запуск — из post-bootstrap.service.ts после загрузки приложения, проверка идёт по уже загруженным данным пользователя и конфигурации, без дополнительных GET-запросов. До 2.268.339 SPA редиректил на legacy-aspx страницу для сбора согласия.

Управление со стороны администратора. Согласие хранится в карточке пользователя (Users.IsAgreeToStorePersonalData). Администратор может запросить его повторное подтверждение: - у конкретного пользователя — действие «Запросить согласие на обработку персональных данных повторно» в карточке пользователя AdminSPA (вкладка профиля, блок служебных действий) — с 2.268.339; - массово у всех пользователей — кнопка остаётся на legacy-aspx странице общих настроек приложения (UI чекбокса требования согласия и текст соглашения тоже там).

Безопасность транспорта и кастомизация страницы авторизации

Соединение с системой защищено на транспортном уровне. Принудительный HTTPS — все обращения по незащищённому HTTP автоматически перенаправляются на HTTPS. HSTS — браузеру предписывается всегда обращаться к сайту только по HTTPS, даже если пользователь набрал адрес без протокола. ⚠️ Настройка HSTS необратимая: после включения отключить её невозможно до истечения срока, заданного в политике.

Внешний вид страницы входа можно оформить под компанию:

Элемент	Настройка
Логотип	Загрузка файла (239x57 px, предпочтительно PNG)
Фоновое изображение	Путь к файлу (2000x3000 px, предпочтительно SVG)
Текст под логотипом	«Текст на странице логина»

Связи с другими доменами

Аутентификация связана с несколькими смежными доменами:

Домен	Связь
Пользователи и группы	Провайдеры привязываются к группам; спецправа управляют MFA и восстановлением пароля; мобильные политики назначаются группам
Синхронизация (AD/1C)	Синхронизация учётных записей из AD и 1С; SAML-автосоздание профилей из атрибутов
Уведомления	SMS-провайдеры для MFA; email для кодов и восстановления пароля
Порталы	Стартовая страница после входа может быть порталом
Календарь / Exchange	Синхронизация с Exchange использует доменную авторизацию и перевоплощение
Чаты / Telegram	Telegram-бот для двухфакторной аутентификации
Смарт-логика	Глобальное смарт-событие «После создания пользователя» при регистрации
Журналы	Журнал входов, белый список IP-адресов, журнал ошибок аутентификации