Перейти к содержанию

Авторизация и вход — Администрирование

Обзор

Администрирование auth построено вокруг связки "сервис аутентификации -> провайдер аутентификации -> политики входа". Основной UI-контур расположен в разделе system -> подключения.

В домене используются все три уровня: - формы dbadmin (провайдеры и сервисы); - EntityEditor для провайдеров; - служебные Admin API для проверки LDAP и получения конфигураций.

Механизмы администрирования

Автоадминка (dbadmin)

Alias формы Название Таблица БД Что настраивается
authentication-providers Провайдеры аутентификации dbo.AuthenticationProviders Тип провайдера, активность, 2FA, видимость
authentication-provider-groups Доступ к провайдеру по группам dbo.AuthenticationProviderGroups Ограничения входа по группам
authentication-provider-domains Домены провайдера аутентификации dbo.AuthenticationProviderDomains Ограничение отображения провайдера по доменам (FQDN)
active-directory-service-settings Сервис Active Directory dbo.LDAPServicesCredentials Подключение к AD
openldap-service-settings Сервис OpenLDAP dbo.OpenLDAPServicesCredentials Подключение к OpenLDAP
oauth-service-settings Сервис OAuth dbo.OAuthServicesSettings OIDC/OAuth параметры
saml-service-settings Сервис SAML dbo.SAMLServicesSettings IdP metadata, сертификаты, claims
radius-service-settings Сервис Radius dbo.RadiusServicesCredentials Radius-сервер
multifactor-service-settings Сервис Multifactor dbo.MultifactorCredentials Внешний второй фактор
synchronizations Синхронизации (AD, LDAP) dbo.SynchronizationProfiles Профили sync с каталогами
synchronization-settings Настройки синхронизации dbo.SynchronizationProfilesADSettings Параметры AD-синхронизации

EntityEditor

Схема JSON Таблица Назначение
authenticationProviders dbo.AuthenticationProviders Расширенное редактирование провайдеров

Admin API контроллеры

Контроллер Маршрут Методы Назначение
AuthenticationProvidersController /api/admin/authentication-providers GET Список провайдеров для админ-интерфейса
LdapController /api/admin/ldap GET, POST Проверка провайдеров, поиск пользователей и групп в LDAP

Runtime API для проверки результата настроек

Контроллер Маршрут Что проверяет
AuthController /api/auth/token-v2, /api/auth/token/refresh, /api/auth/info Базовый password/refresh контур
SamlAuthController /api/auth/saml/* SAML SSO-поток
OAuthController /api/auth/oauth OAuth/OIDC вход и выход

Ключевые настройки

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

Где настраивается: authentication-providers, authentication-provider-groups, authentication-provider-domains, auth_providers.md

Таблицы БД: - dbo.AuthenticationProviders - dbo.AuthenticationProviderGroups - dbo.AuthenticationProviderDomains

Что контролируется: - тип провайдера (ActiveDirectory, OpenLDAP, OAuth, SAML, Radius); - флаги активности/скрытия/"по умолчанию"; - второй фактор; - доступность провайдера для конкретных групп; - привязка провайдера к доменам (FQDN) — на странице авторизации провайдер показывается только при входе с указанных доменов. Если список доменов пуст — провайдер доступен со всех доменов. Список настроенных доменов передаётся на фронт через app-settings.json → Providers для фильтрации.

2. Сервисы внешней аутентификации

OpenID Connect / OAuth: формирование scope из настроек провайдера

Для OIDC-провайдера список scope в запросе к Identity Provider теперь может задаваться явно и/или вычисляться по конфигурации провайдера.

Что важно при настройке: - openid должен присутствовать всегда — это базовый scope протокола OpenID Connect; - если в SettingsJson задан ключ Scopes, платформа использует его как явный список дополнительных scope; - если Scopes не задан, платформа вычисляет дополнительные scope по списку Claims; - для claim phone_number и phone_number_verified требуется scope phone; - для claim email и email_verified требуется scope email; - для claim группы профиля (name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, updated_at) требуется scope profile; - для claim address требуется scope address.

Это изменение нужно для сценариев, где пользователь сопоставляется не по стандартному sub, а по другому claim, например по номеру телефона. Ранее запрос мог уходить только с scope=openid, из-за чего IdP не возвращал нужный claim и вход завершался ошибкой.

Пример настройки входа по телефону:

{
  "Claims": ["phone_number"],
  "Scopes": ["phone"],
  "ClaimsMapperConfig": {
    "MapperType": "ByAttribute",
    "IdentityClaim": "phone_number",
    "UserAttribute": "MobilePhone"
  }
}

Практическое правило: если используемый для идентификации claim зависит от стандартного OIDC scope, лучше явно указать Scopes в SettingsJson, чтобы поведение не зависело от неявного вывода.

Где настраивается: формы *-service-settings в system -> подключения.

Таблицы БД: - dbo.LDAPServicesCredentials - dbo.OpenLDAPServicesCredentials - dbo.OAuthServicesSettings - dbo.SAMLServicesSettings - dbo.RadiusServicesCredentials - dbo.MultifactorCredentials

Что контролируется: endpoint-ы, креды, сертификаты, маппинг claims и технические параметры handshake.

3. Политики входа и защитные лимиты

Где настраивается: общие системные настройки (system-settings) и пользовательские ключи (sys_user).

Что контролируется: - лимиты неудачных попыток входа и captcha; - ограничения на логин по email (ForbidEmailAsLogin); - правила регистрации и password-политики.

Защита от брутфорса (общие настройки → блок аутентификации)

Настройка Эффект при превышении
Максимальное число попыток логина до блокировки Учётная запись блокируется. Разблокировка — только администратором
Максимальное число попыток логина пользователя до капчи Запрашивается ввод captcha при следующих попытках
Максимальное число попыток логина с IP до капчи IP-адрес блокируется; для разблокировки выводится captcha

⚠️ Все три счётчика работают независимо. Если значение пустое — соответствующая защита выключена.

Адрес страницы логина для редиректа после API-ошибок (с v2.257) задаётся ключом AuthTokenLoginUrl в appsettings.json. Используется в сценарии ~/api/...?auth=true (см. user-ui/admin.md, §9.2).

Политика паролей (для встроенных учётных записей)

Область применения: настройки учитываются при создании пользователей из режима администрирования и при сбросе пароля. Для самостоятельной регистрации действуют требования из пользовательского ключа RegistrationFields (см. ниже §«Самостоятельная регистрация»).

Параметр Поведение
Срок действия пароля (дни) Только forms-авторизация. Если задан — в профиле отображается счётчик дней до смены; при просрочке пользователь редиректится на форму смены при следующем входе
Минимальная / Максимальная длина пароля Если не задано — не проверяется
Содержит спецсимвол (! @ # $ % и т. п.) Флаг
Содержит заглавную букву Флаг
Пароль может совпадать с предыдущим Если выключено — нельзя устанавливать ранее использованный пароль
Пароль может совпадать с логином Если включено — допускается пароль, идентичный логину
Длина истории паролей Сколько предыдущих паролей запоминается и блокируется к повторному использованию
Проверять пароль на наличие даты рождения Запрет использовать дату рождения пользователя
Минимальная длина последовательности символов для проверки Распознаются как небезопасные: подряд идущие цифры (123, 7890), буквы по алфавиту (abc, mno), соседи на клавиатуре (рус.: йцукен…, фывапрол…, ячсмить…; англ.: qwerty…, asdfgh…, zxcvbn…)
Минимальная длина повторяющегося паттерна для проверки Запрет паттернов вида qweqwe, 123123. Срабатывает только при непосредственном повторе (не при разрозненном употреблении)

Срок действия кода восстановления пароля

Параметр «Срок действия кода для восстановления пароля в днях» задаёт TTL email-кода, высылаемого по запросу «Забыли пароль?».

3.1 Алгоритм хеширования паролей встроенных учётных записей

Для встроенных учётных записей платформа использует алгоритм хеширования паролей Argon2id (RFC 9106) как актуальный стандарт хранения паролей.

Текущие параметры хеширования: - память — 19 MiB (m=19456); - итерации — 3; - parallelism — 1; - длина хеша — 32 байта; - длина salt — 16 байт.

Хеш хранится в поле PasswordHashPhc в формате PHC string: $argon2id$v=19$m=19456,t=3,p=1$<salt-base64>$<hash-base64>

Переход со старого формата выполнен без принудительного сброса паролей. При входе пользователя система сначала проверяет актуальный формат Argon2id. Если пароль был сохранён в старом формате Argon2i, выполняется fallback-проверка legacy-хеша, после чего при успешной аутентификации пароль автоматически перехешируется в формат Argon2id.

Это поведение относится только к встроенным учётным записям 1Формы. Для пользователей Active Directory, LDAP, SAML и OIDC пароль в БД 1Формы не хранится, поэтому поле PasswordHashPhc для них может оставаться пустым.

4. Синхронизация каталогов

Где настраивается: synchronizations, synchronization-settings.

Таблицы БД: - dbo.SynchronizationProfiles - dbo.SynchronizationProfilesADSettings

Что контролируется: импорт пользователей/групп и консистентность каталога для auth-проверок.

5. Personal Access Tokens (PAT)

Реализовано (релиз 2.266)

Где настраивается: - appsettings.json → секция Auth (серверные лимиты); - спецправо GENERATEPAT на группу (управление через system → подключения → спецправа или dbadmin-форму groups_spec).

Параметры appsettings.jsonAuth:

Ключ Тип Дефолт Описание
PatMaxTokensPerUser int 10 Максимум не-отозванных токенов на одного пользователя
PatMaxExpirationDays int 365 Максимальный TTL токена в днях; 0 = бессрочные разрешены

Таблица БД: dbo.PersonalAccessTokens

Admin API: /api/admin/pat/* -- CRUD для администраторов (генерация, просмотр, отзыв токенов любого пользователя).

User API: /api/user/pat/* -- генерация (только при наличии спецправа GENERATEPAT), просмотр и отзыв своих токенов.

DevOps-задача: при деплое/обновлении -- убедиться, что ключи PatMaxTokensPerUser и PatMaxExpirationDays добавлены в appsettings.json.

6. appsettings.json — справочник ключей Auth и связанных секций

Ключ Default Назначение
AuthTokenLoginUrl URL формы логина для редиректа из API при ошибке 401 (используется в сценарии ~/spa/entry/signin?fromUrl=..., см. user-ui/admin.md §9.2). С v2.257+
AuthTokenExpiresInMinutes 1500 (25 ч) TTL access-токена. ⚠️ В SPA по истечении нужна повторная авторизация
AuthRefreshTokenExpiresInMinutes 43200 (30 дней) TTL refresh-токена
AuthTokenRefreshStrategy SlidingExpiration Стратегия обновления: SlidingExpiration — авто-обновление при активности, RefreshToken — через api/auth/token/refresh, None — без обновлений
AuthTokenRefreshPeriodInMinutes 20% от AuthTokenExpiresInMinutes Период автообновления при SlidingExpiration. Действует только при этой стратегии
AuthTempTokenExpiresInMinutes TTL временного access-токена с ограниченными правами (выдаётся при смене пароля)
AuthBasicAllowedPaths Регексы путей с разрешённой Basic-аутентификацией (через ; или ,). ⚠️ Экранируйте спецсимволы regex
AuthLoginCodeExpiresInMinutes 1440 (24 ч) TTL кода регистрации/аутентификации
ConcurrentSessionMinLengthInMinutes 1 Минимальная длительность активной сессии для конкурентной лицензии (через кэш ConcurrentSessionsExpirationCache). Меньше — быстрее перераспределение лицензий, больше — медленнее освобождение при закрытой вкладке
LDAPSearchBase База поиска для LDAP
UseSecureLDAP true SSL для LDAP. Актуально, если ActiveDirectoryAuthenticationMode не указан
OidcAliases Алиасы OpenID-провайдеров (через запятую): "sm,forma"
AlignedAuthResponseTimeMs 700 Минимальное время ответа аутентификации (для защиты от time-attacks). При неуспехе — задержка до этого порога. Успешные ответы (200) — без задержки. 0 или отрицательное — отключение (для медленного AD)
PatMaxTokensPerUser 10 Максимум активных PAT-токенов на пользователя
PatMaxExpirationDays 365 Макс TTL PAT в днях. 0 — разрешает бессрочные
WinAuthHost IIS Включение Windows-аутентификации
Multifactor.IsEnabled true Двухфакторная через сервис MULTIFACTOR
Multifactor.Host Адрес сервиса Multifactor
ActiveDirectoryAuthenticationMode ldap Библиотека для AD-аутентификации: DirectoryServices (System.DirectoryServices, только AD), PrincipalContext (более высокоуровневая, нужна при одноимённых учётных записях в лесе AD), ldap (Novell.Directory.Ldap — работает и с AD, и с OpenLDAP)
AuthUseInsecureCookies bool / false Разрешает не-secure cookie для аутентификации. ⚠️ Включать только при работе по HTTP. Для HTTPS — снижает безопасность
SetCookieForUpperLevelDomain bool / false Cookie 1FormaAuth ставится на домен верхнего уровня (нужно при нескольких поддоменах, например forms.example.ru + win.example.ru). По умолчанию — на полный FQDN

Диагностика:

-- Все активные PAT пользователя
select
        pat.Id,
        pat.Name,
        pat.TokenPrefix,
        pat.CreatedAt,
        pat.ExpiresAt,
        pat.LastUsedAt,
        pat.IsRevoked
from PersonalAccessTokens pat with (nolock)
where pat.UserId = @UserId
      and pat.IsRevoked = 0
order by pat.CreatedAt desc;

Пошаговые сценарии настройки сервисов

Контент в business.md описывает концепции и параметры протоколов. Ниже — UI-сценарии создания сервисов и провайдеров.

Общий порядок

  1. Создать сервис (system → подключения → Сервисы) — выбрать тип, заполнить параметры подключения
  2. Создать провайдер аутентификации (authentication-providers) — выбрать сервис, настроить MFA, группы, видимость
  3. Настроить AuthConfig (пользовательский ключ) — определить доступные типы входа

Active Directory

Сервис (active-directory-service-settings):

Поле Описание
Домен Имя домена компании
Домен является корнем леса Работа с корнем леса AD
Логин/Пароль для доступа к AD Опционально — если пользователь приложения уже имеет нужные права

⚠️ Режимы аутентификации: по умолчанию используется DirectoryServices. При наличии одноимённых учётных записей в лесу AD переключить на PrincipalContext через настройку ActiveDirectoryAuthenticationMode в web.config/appsettings.json. Без переключения система может авторизовать не того пользователя.

Провайдер: тип ActiveDirectory, выбрать созданный сервис, настроить второй фактор при необходимости.

Параметры и бизнес-логика: business.md#active-directory

OpenLDAP

Сервис (openldap-service-settings):

Поле Описание
Адрес сервера URL LDAP-сервера
DN путь Базовый DN для поиска
DN привязки DN учётной записи для bind
Пароль привязки Пароль для bind

SSL-подключение: ключ UseSecureLDAP в web.config/appsettings.json.

Параметры: business.md#openldap

SAML (ADFS)

Сервис (saml-service-settings):

Поле Описание
IDP Metadata URL URL метаданных IdP, например https://your-domain.com/FederationMetadata/2007-06/FederationMetadata.xml
Сопоставление пользователей На данный момент — только по SID из Active Directory

Settings (JSON):

Ключ Описание
Issuer Издатель запроса. ⚠️ Для ADFS должен совпадать с доменом SP-приложения (relying party trust в терминах ADFS)
SignatureAlgorithm Алгоритм подписи (default: rsa-sha256)
UserClaimName Claim для идентификации пользователя. Для ADFS: primarySid
SignAuthRequests Подписывать ли запросы к IDP. ⚠️ Для ADFS обязательно true
SignCertificatePath Путь к .pfx-сертификату для подписания SP→IDP
SignCertificatePassword Пароль к .pfx-файлу

ClaimsMapperConfig:

Ключ Описание
IdentityClaim Атрибут для однозначной идентификации: Email, Nick, ExternalAccount, SID
CreateProfiles true → автосоздание профиля из SAML-атрибутов, если УЗ не найдена по IdentityClaim
ProfileAttributesMap Маппинг полей профиля (см. ниже)

ProfileAttributesMap — 29 полей: Nick, LastName, FirstName, MiddleName, FullName, Phone, Phone2, Phone3, Email, ExternalEmail, DisplayName, Position, EnglishDisplayName, ExternalDisplayName, CellPhone, HomePhone, Fax, Skype, ICQ, LiveJournal, Twitter, IsEmployee, BirthDate (datetime), WorkStartDate (datetime), Country, City, Gender (bool), Notes, SID, GuidFrom1C (guid), PhoneAdditional, Phone2Additional, Phone3Additional, HomePhoneAdditional, MaidenName, CanEditAvatar (bool), TelegramUserName

⚠️ CreateProfiles: true = автопровизионинг пользователей без предварительного создания в 1Ф. Без понимания ограничения Issuer — SSO с ADFS не заработает.

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

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

Метаданные SP: /api/auth/saml/{providerId}/metadata.

Концепции и SSO-поток: business.md#saml

OAuth / OIDC (KeyCloak, v2.263+)

Сервис (oauth-service-settings):

Поле Описание
Alias Алиас провайдера [a-z]
Реализация OAuth OpenIDConnect
ClientId ID приложения KeyCloak (Clients → компания → General → Client ID)
ClientSecret Секретный ключ (Clients → компания → Credentials → Client secret)
Сопоставление пользователей Один из 4 типов (см. ниже)

Settings (JSON):

Ключ Описание
AuthorityUrl URL центра OAuth
ResponseType Тип ответа AtomID
ResponseMode Режим ответа
CallbackPath URL возврата после аутентификации
Claims Список claims
ClaimsMapperConfig Настройки маппинга (см. ниже)

4 типа ClaimsMapper:

Класс Описание
ClaimsMapperByDictionary По справочнику (категории)
UserClaimsMapperByAttribute По произвольному атрибуту
UserClaimsMapperByExternalAccounts По УЗ внешнего сервиса (UserExternalAccounts)
UserClaimsMapperByNickname / по SID По Nickname или SID

ClaimsMapperConfig:

Ключ Описание
IdentityClaim Email, Nick, ExternalAccount, SID
DictionarySubcatId ID категории справочника (для ClaimsMapperByDictionary)
DictionaryIdentityExtParamId ID ДП для идентификации
DictionaryUserIdExtParamId ID ДП для UserID

После настройки: 1. Добавить провайдер аутентификации с созданным сервисом 2. Прописать алиас в ключе OidcAliases в appsettings.json (несколько провайдеров — через запятую)

Логирование: вход через OIDC логируется в LoginsLog аналогично Forms-аутентификации (сброс счётчика попыток, добавление IP в белый список). Выход не логируется.

Концепции и способы сопоставления: business.md#oauth-20--openid-connect

RADIUS

Сервис (radius-service-settings):

Поле Описание
IP-адрес Адрес RADIUS-сервера
Порт Порт (обычно 1812)
Shared secret Общий секрет

Параметры: business.md#radius

Multifactor (v2.256+)

Сервис (multifactor-service-settings):

  1. В админ-панели Multifactor (admin.multifactor.ru): Настройки → Расширенное API → скопировать API Key и API Secret
  2. В 1Ф: создать сервис типа Multifactor, указать API URL (https://api.multifactor.ru), API-ключ и Секретный ключ
  3. Установить сертификат 1forma.net.cer на сервер
  4. В провайдере аутентификации: Второй фактор → Сервис → выбрать сервис Multifactor

appsettings.json: секция Multifactor с ключами IsEnabled и Host. web.config: MultifactorIsEnabled и MultifactorHost.

Процесс и параметры: business.md#multifactor-сервис

Настройка типов входа (AuthConfig)

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

По умолчанию: {"AuthTypes": []}

Параметры каждого элемента AuthTypes:

Параметр Описание
Type login-pass, phone-code, email-code, external-provider
IsDefault Тип входа по умолчанию. При нескольких true — появляется кнопка переключения
AllowRegister Показать кнопку регистрации
AutoRegister Автоматическая регистрация
Visibility all, web, mobile — ограничение по устройству
PrivacyLink Ссылка на соглашение при входе
RegisterPrivacyLink Массив ссылок на соглашение при регистрации (linkUrl + linkTitle)
RegistrationType all, phone, email
HideProviders Скрыть выбор провайдера

⚠️ Параметры в AuthTypes обязательно с заглавной буквы.

Поведение external-provider: отображается экран только с кнопками внешних провайдеров (без формы логина/пароля и капчи). Внизу — ссылка «Войти по логину и паролю» с кнопкой «Назад». ⚠️ Если в AuthTypes нет login-pass — ссылка не отображается.

Приоритет: AuthConfig > sys_general_settings — если регистрация отключена в ключе, глобальная настройка «Разрешена регистрация» не поможет.

Время жизни кода: AuthLoginCodeExpiresInMinutes в appsettings.jsonAuth (default 1440 мин = 24ч).

Балансировщик нагрузки: без настройки ForwardHeaders все запросы воспринимаются как один IP → массовая блокировка.

"ForwardHeaders": {
  "Headers": "For,Proto,Host,Prefix",
  "Networks": "*",
  "Proxies": "*"
}

Полная JSON-схема и типы входа: business.md#способы-входа-на-форме-авторизации

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

Ключ RegistrationFields определяет набор полей на форме самостоятельной регистрации.

9 кодов полей:

Код Тип Описание
Email email Адрес почты
CellPhone phone Мобильный телефон
Nick string Псевдоним
FirstName string Имя
LastName string Фамилия
Gender select Пол (1 = Мужской, 0 = Женский)
City string Город
Password password Пароль
Note string Примечание (поддерживает HTML; доп. параметры title и Color)

Структура элемента:

{"Key": "Email", "isRequired": true/false, "IsHidden": true/false}

PasswordSettings (вложенная секция для поля Password) — 11 параметров:

Параметр Описание
MinNumberOfChar Минимальное количество символов
MaxNumberOfChar Максимальное количество символов
UpperLowercaseRequired Заглавные и строчные обязательны
AcceptableLanguage Допустимый язык (например ru-RU)
MinNumberOfDigits Минимум цифр
NoSpaces Без пробелов
MinNumberOfSpecialChar Минимум спец. символов
DisallowLoginOrBirthdayPattern Запрет логина/даты рождения в пароле
DisallowedSequenceLength Запрет последовательностей (йцукен, qwerty, 123)
DisallowedRepeatingPatternLength Запрет повторяющихся паттернов (qweqwe, 123123)
NumberOfPreviousPasswordsToCheck Проверка истории паролей (рекомендуется ≥ 10)
MinCharPasswordDifference Мин. отличие от предыдущего пароля (рекомендуется ≥ 5)

⚠️ PasswordSettings действует только на форму самостоятельной регистрации. Для создания пользователей из режима администрирования и сброса паролей — sys_general_settings.

7 правил регистрации: 1. Одно из CellPhone, Email, Nick — обязательно 2. Поле, использованное для верификации (телефон/email), скрывается на форме 3. При заполнении Nick — пароль обязателен 4. Пустой Nick автозаполняется из Phone или Email 5. Пустой DisplayName автозаполняется из FirstName LastName или Nick 6. При заданном CellPhone без Email (если Email обязателен) — phone@domain 7. Gender по умолчанию = 1 (Мужской)

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

Параметр source: spa_base (веб) или mobile (МП) — используется в смарт-событии «После создания пользователя».

Автозаполнение и бизнес-правила: business.md#самостоятельная-регистрация

Синхронизация каталогов (связь с сервисами)

Профиль синхронизации (synchronizations) связывается с сервисом через поле Сервис — выбирается один из настроенных AD/LDAP-сервисов.

⚠️ Для каждого сервиса может быть только одна активная настройка синхронизации.

Ключевые параметры профиля:

Параметр Описание
Синхронизация с AD Синхронизация по расписанию ADSyncJob
Данные пользователей Синхронизация полей профиля
Названия групп Синхронизация имён групп
Создание новых групп Авто-создание групп из AD
Членство пользователей Синхронизация состава групп
Вложенность групп Синхронизация иерархии групп
Создавать пользователей из AD Авто-создание новых пользователей
Логины в формате Domain\Nick Для работы в нескольких доменах с одинаковыми никами
Только орг. единиц из AD Сохраняет ручные орг.единицы при синке
Маска для создания групп Фильтр групп по маске
Организационные единицы Дерево OU для синхронизации
AD фильтр пользователей LDAP-фильтр пользователей (до 1000 символов)
AD фильтр групп LDAP-фильтр групп
Макс. допустимое кол-во обновлений Лимит — при превышении задание не выполняется

Маппинг полей (встроенные): company → Компания, department → Отдел, description → Должность, givenName → Имя, displayName → Псевдоним (рус.), telephoneNumber → Рабочий, mail → E-mail, thumbnailPhoto → Аватар.

⚠️ Названия полей регистрозависимыеdisplayname и DisplayName распознаются как разные параметры.

Детали синхронизации и AD-ограничения: ../users-and-groups/business.md

CustomSettings — прочие ключи аутентификации

Ключ Тип Назначение
ForbidTCLogin 0 / 1 Если 1 — вход в приложение TaskCenter (платформа .NET Framework, legacy-клиент) проверяется на права. Если 0 — войти может любой пользователь. Используется для блокировки legacy-доступа
PasswordRecoveryText string (Markdown) Кастомный текст на странице восстановления пароля (/spa/entry/password-recovery). Markdown-форматирование поддерживается
LogRefreshTokenRequests bool Если true — обновления токенов мобильного клиента логируются в LoginsLog и отображаются в журнале пользователя/логах МП наряду с обычными входами. Используется для аудита

Типичные ошибки настройки

Симптом Причина Где проверить SQL-диагностика
На форме логина нет нужного провайдера Провайдер неактивен/скрыт/не назначен по умолчанию authentication-providers select ProviderID, Name, ProviderType, IsActive, IsHidden, IsDefault from dbo.AuthenticationProviders order by ProviderID;
Пользователь видит провайдер, но вход запрещён Нет привязки группы в AuthenticationProviderGroups Доступ к провайдеру по группам select * from dbo.AuthenticationProviderGroups where ProviderId = @ProviderId;
LDAP/AD поиск пользователей в админке не работает Неверные credentials или endpoint сервиса active-directory-service-settings, openldap-service-settings select * from dbo.LDAPServicesCredentials; select * from dbo.OpenLDAPServicesCredentials;
SAML/OAuth handshake падает Ошибка metadata/issuer/cert/callback-path saml-service-settings, oauth-service-settings select * from dbo.SAMLServicesSettings; select * from dbo.OAuthServicesSettings;
Вход блокируется после серии ошибок Слишком жёсткие лимиты попыток / captcha system-settings select FailedAttemptsCount, LastUpdate from dbo.IpList where Ip = @Ip; select LogFailsCount from dbo.Users where Nick = @Login;
PAT-токен не работает (401) Токен отозван, просрочен или повреждён /api/*/pat/list или БД select TokenPrefix, IsRevoked, ExpiresAt, LastUsedAt from PersonalAccessTokens where UserId = @UserId;
Пользователь не может генерировать PAT Нет спецправа GENERATEPAT спецправа группы Проверить наличие права GENERATEPAT на группу пользователя
Лимит токенов исчерпан PatMaxTokensPerUser достигнут appsettings.json select count(*) from PersonalAccessTokens where UserId = @UserId and IsRevoked = 0;

Аутентификация API-запросов

Метод Заголовок Когда использовать
PAT 1F-Pat: {token} Production-окружение
JWT 1FormaAuth: {jwt} Тестовые стенды — PAT не работает
Cookie 1FormaAuth={token} Браузерные сессии

Authorization: Bearer {token} → всегда 401. Не использовать.

Стенды vs Production

Аспект Production-окружение Тестовые стенды
PAT Работает Не работает → только JWT
SSL Доверенный сертификат Self-signed → verify=False / -k
Авторизация 1F-Pat: {token} 1FormaAuth: {jwt} через POST /api/auth/token-v2

Python SSL на стендах

Python 3.9 не использует macOS Keychain → ssl.create_default_context() с check_hostname=False, verify_mode=CERT_NONE.

Конфигурация Windows-аутентификации (IIS)

Параметр WinAuthTokenExpiresInMinutes (v2.267.376+)

Время жизни access-токена для Windows-аутентификации (IIS Integrated Windows Authentication) задаётся параметром Auth.WinAuthTokenExpiresInMinutes в appsettings.json.

Поведение: - Если параметр не задан (null) — используется значение из Auth.AuthTokenExpiresInMinutes (default 1500 мин = 25 ч). - Если задан — используется указанное значение (в минутах).

Пример:

{
"Auth": {
"WinAuthTokenExpiresInMinutes": 1500
}
}

Когда настраивать. Параметр добавлен после инцидента, в котором TTL Win-токена был жёстко зашит на 5 минут — это вызывало попап ввода пароля Windows в IIS каждые 5 минут. Параметр позволяет явно выровнять TTL Win-токена с обычным token lifetime.

Связанные документы

  • docs/domains/auth/backend.md
  • docs/domains/auth/data-flow.md
  • docs/domains/system/admin.md
  • docs/reference/security/auth-security-model.md
  • docs/reference/api/auth-operations-guide.md — полный гайд по аутентификации API