Аутентификация и авторизация: бизнес-логика

Обзор

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

После успешной аутентификации система выдает JWT-токен. При входе через SAML или OIDC в токен дополнительно включаются claims провайдера (ProviderId, NameId, SessionIndex), а время жизни определяется ответом IDP.

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

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

Форма авторизации управляется пользовательским ключом AuthConfig (JSON-массив AuthTypes). Каждый элемент массива задает тип входа и его параметры.

Типы входа (AuthTypes)

Тип	Описание
login-pass	Классический вход по логину и паролю
phone-code	Вход по номеру телефона: система отправляет 4-значный SMS-код
email-code	Вход по адресу электронной почты: 4-значный код на email
external-provider	Приоритетный вход через внешнего провайдера: отображается отдельный экран с кнопками провайдеров, форма логин/пароль скрыта, переход к ней по ссылке

Для каждого типа настраиваются: признак по умолчанию (IsDefault), разрешение регистрации (AllowRegister), авторегистрация (AutoRegister), видимость по устройствам (Visibility: all/web/mobile), ссылки на пользовательские соглашения (PrivacyLink, RegisterPrivacyLink), способ регистрации (RegistrationType: all/phone/email).

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

Ключ AuthConfig имеет приоритет над настройкой "Разрешена регистрация, вход по номеру телефона" из общих настроек: если в ключе регистрация отключена, она недоступна даже при активной глобальной опции.

Время жизни кода подтверждения настраивается параметром AuthLoginCodeExpiresInMinutes в appsettings.json секции Auth (по умолчанию 1440 минут = 24 часа). Ограничение распространяется на все коды -- регистрации и аутентификации.

Ключ ForbidEmailAsLogin позволяет запретить вход по email, разрешив только логин.

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

Провайдер -- основная сущность управления внешней аутентификацией. Типы провайдеров:

• ActiveDirectory
• SAML
• OpenLDAP
• Radius
• OAuth

Параметры провайдера

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

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

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

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

Типы аутентификации (провайдеры)

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

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

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

Active Directory

Аутентификация через доменную инфраструктуру Microsoft. Требования: адрес домена, системная учетная запись, сервер приложений в домене (или DNS-зона на адаптере).

Параметры сервиса: домен, признак корня леса, логин/пароль доступа к AD (опционально, если пользователь приложения имеет нужные права).

По умолчанию аутентификация реализована через DirectoryServices. Для лесов AD с одноименными учетными записями используется режим через PrincipalContext (настройка ActiveDirectoryAuthenticationMode в appsettings.json).

OpenLDAP

Аутентификация через LDAP-каталог (не AD). Параметры: адрес сервера, DN-путь, DN-привязки, пароль.

SSL-подключение настраивается ключом UseSecureLDAP (если не указан ActiveDirectoryAuthenticationMode).

SAML

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

Параметры сервиса: - IDP Metadata URL -- URL метаданных IdP (например, ADFS FederationMetadata.xml) - Issuer -- издатель запроса (для ADFS должен совпадать с доменом SP) - UserClaimName -- claim для идентификации пользователя (для ADFS: primarySid) - SignAuthRequests / SignCertificatePath / SignCertificatePassword -- подпись запросов сертификатом - SignatureAlgorithm -- алгоритм подписи (по умолчанию RSA-SHA256) - Сопоставление пользователей -- по SID из Active Directory

Настройка SP: генерация .pfx-сертификата, установка публичного ключа IDP на сервере 1F, создание провайдера. После создания метаданные SP доступны по /api/auth/saml/{providerId}/metadata.

Эндпоинты: /api/auth/saml/{providerId}/login, /api/auth/saml/{providerId}/assertionconsumer, /api/auth/saml/{providerId}/logout, /api/auth/saml/{providerId}/singlelogout.

Автосоздание профилей: параметр CreateProfiles в ClaimsMapperConfig позволяет создавать учетные записи из атрибутов ADFS/SAML. Поддерживается маппинг множества полей профиля (Nick, LastName, FirstName, Email, Phone, Position, SID и др.).

Параметры appsettings.json: SamlEntityId (доменное имя SP), SamlCertificatesRoot (путь к сертификату).

OAuth 2.0 / OpenID Connect

Протокол аутентификации через внешний IdP (KeyCloak). Доступен с версии 2.263.

Параметры сервиса: Alias, ClientId, ClientSecret, Settings (JSON с AuthorityUrl, ResponseType, ResponseMode, CallbackPath, Claims, ClaimsMapperConfig).

Способы сопоставления пользователей: - По справочнику (категории) - По произвольному атрибуту - По У.З. внешнего сервиса (UserExternalAccounts) - По Nickname - По SID

Alias каждого OpenId-провайдера добавляется в ключ OidcAliases в appsettings.json (через запятую при нескольких провайдерах).

RADIUS

Аутентификация через RADIUS-сервер. Минимальная конфигурация: IP-адрес, порт, shared secret.

Windows-аутентификация (Kerberos/NTLM)

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

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

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

SMS

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

Email

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

Multifactor (сервис)

Интеграция с внешней системой MULTIFACTOR (с версии 2.256). Процесс: пользователь вводит логин/пароль, при успехе система запрашивает API Multifactor, пользователя перенаправляют на страницу второго фактора, после подтверждения Multifactor возвращает токен доступа.

Настройка: сервис типа Multifactor (API URL, API-ключ, секретный ключ из личного кабинета admin.multifactor.ru), затем выбор этого сервиса в параметре "Второй фактор" провайдера. В appsettings.json: секция Multifactor с ключами IsEnabled и Host. Требуется установка сертификата 1forma.net.cer.

Telegram

Специальное право группы "FormsAuthWithTelegram". Требуется настроенный Telegram-бот (через BotFather) и webhook. Процесс: после ввода логина/пароля система запрашивает Telegram Bot API, пользователя перенаправляют на страницу Telegram, после подтверждения -- возврат с токеном.

Настройка: создание бота через @BotFather, указание ID/токена бота и имени пользователя бота в провайдере, выдача спецправа группе.

Политики паролей

Пароли для веб-входа (режим администрирования и сброс)

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

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

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

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

Отдельная настройка через ключ RegistrationFields (имеет приоритет над общими настройками). Расширенные параметры секции PasswordSettings: MinNumberOfChar, MaxNumberOfChar, UpperLowercaseRequired, AcceptableLanguage, MinNumberOfDigits, NoSpaces, MinNumberOfSpecialChar, DisallowLoginOrBirthdayPattern, DisallowedSequenceLength, DisallowedRepeatingPatternLength, NumberOfPreviousPasswordsToCheck, MinCharPasswordDifference.

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

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

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

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

Специальное право "Запрещено пользоваться восстановлением пароля" блокирует самостоятельное восстановление пароля для группы.

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

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

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

При работе через балансировщик нагрузки необходимо передавать реальные IP через заголовки X-Real-IP, X-Forwarded-Proto. Настройка ForwardHeaders в appsettings.json предотвращает массовую блокировку всех пользователей за балансировщиком.

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

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

Регистрация пользователей управляется ключом RegistrationFields (набор полей) и общей настройкой "Разрешена регистрация, вход по номеру телефона".

Правила: - Одно из полей CellPhone, Email или Nick -- обязательно - При заполнении Nick обязателен и пароль - При пустом Nick -- автозаполнение из Phone или Email - При пустом DisplayName -- автозаполнение из "FirstName LastName" или Nick - Источник регистрации (source): spa_base (веб) или mobile (МП)

Предопределение значений полей через URL: ~/spa/entry/signup?RegistrationCode=значение.

При регистрации по телефону/почте поле-источник автоматически заполняется и скрывается.

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

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

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

Требования отображаются при фокусе на поле пароля: серым до ввода, красным при невыполнении, зелёным при выполнении.

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

Кнопка «Регистрация» на финальном шаге активна только когда все обязательные поля заполнены корректно.

Расширенная политика безопасности паролей

Администратор может включить дополнительные правила проверки сложности:

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

SSO (Single Sign-On)

SSO реализуется через протоколы SAML и OAuth/OIDC. При SAML-аутентификации SPA-приложение отрисовывает кнопку входа через провайдер; при клике -- редирект на LoginPath, формирование подписанного запроса, аутентификация на IDP, возврат с JWT-токеном.

При разлогине SPA считывает из токена ProviderId и LogoutPath, 1Форма формирует запрос разлогина к IDP, IDP удаляет сессию и перенаправляет обратно, 1Форма удаляет cookie и токен.

OIDC-провайдер (KeyCloak) работает по протоколу OpenID Connect с аналогичной схемой SSO.

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

Администраторы по умолчанию имеют доступ к перевоплощению -- работе в системе от имени другого пользователя. Управление:

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

Personal Access Tokens (PAT)

Реализовано (спринт С-01-26, релиз 2.266)

PAT -- долгоживущие интеграционные токены для безопасного доступа к API без логина/пароля. Предназначены для автоматизации и внешних интеграций.

Управление доступом

• Спецправо "Генерация PAT" (GENERATEPAT) на группу -- разрешает создавать токены на своё имя.
• Администраторы получают эту возможность по умолчанию и могут выдавать PAT любому пользователю.
• Обычные пользователи без спецправа могут просматривать и отзывать свои токены, но не генерировать новые.

Генерация и хранение

• При генерации полная строка токена возвращается один раз -- в БД хранится только хеш (SHA-256) и префикс (первые 8 символов).
• Пользователь обязан сохранить строку токена самостоятельно; повторно получить её невозможно.

Использование

• Токен передаётся в HTTP-заголовке 1F-Pat.
• Для SignalR-подключений токен можно передавать в GET-параметре access_token (нужно для realtime-подключений, где клиентская библиотека SignalR передаёт токен в строке запроса при установке соединения).
• Пользователь, аутентифицированный через PAT, работает как обычный JWT-пользователь со всеми его правами, лицензиями и ограничениями.
• Рекомендация: выдавать PAT на специального сервисного пользователя в отдельной группе с ограниченными правами.

Ограничения по конфигурации

Параметр (appsettings.json → Auth)	Дефолт	Описание
PatMaxTokensPerUser	10	Максимум не-отозванных токенов на пользователя
PatMaxExpirationDays	365	Максимальный срок жизни токена (дни); 0 = бессрочные разрешены

UI управления токенами

Реализовано

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

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

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

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

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

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

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

Текущие ограничения (техдолг)

• Scopes не реализованы -- все токены работают с полным набором прав пользователя. Планируется к доработке по бизнес-потребностям.
• Логирование входов по PAT -- отсутствует запись в LoginsLog; фиксируются только LastUsedAt и LastUsedIp в таблице PersonalAccessTokens.
• Очистка просроченных/отозванных токенов из БД не автоматизирована.

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

При включенной настройке "Требовать подтверждение согласия на обработку перс. данных" (общие настройки) система при аутентификации проверяет поле IsAgreeToStorePersonalData в таблице Users. Без отметки о согласии пользователю отображается текст соглашения, и вход возможен только после подтверждения.

Безопасность транспорта

• HTTPS-редирект (301) -- конвертация HTTP-запросов в HTTPS
• HSTS -- заголовок Strict-Transport-Security (необратимая настройка: после включения отключить невозможно до истечения срока действия)

Кастомизация страницы авторизации

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

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

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