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

Пользователи и группы (расширенная функциональность)

Группы

Обзор

Группы пользователей позволяют массово задать права и авторизации пользователей.

Поле Название Описание Обязательное
name Имя Уникальное имя группы Да
permissions Разрешения Список разрешений группы

Разрешения

Для каждого объекта в системе создаются разрешения can_add, can_change, can_delete (подробнее в описании самих объектов).

Для каждого параметра в системе автоматически создаются разрешения на просмотр ("can view" + название параметра) и редактирование ("can_edit" + название параметра), которые также настраиваются через разрешения группы (доступны в общем списке).

Замечание: В следующих версиях планируется реализовать другой подход к разрешению на редактирование параметров

Профиль группы

Область видимости

В профиле группы прописана "область видимости" группы - это ограничения в терминах иерархии, в рамках которых пользователи группы могут работать с данными.

Например,

для группы "Бренд-менеджер Stickers" доступны товары бренда Stickers во всех клиентах,

для группы "Бренд-менеджер Stars" доступны товары бренда "Stars" во всех клиентах,

для группы "Менеджер по работе с клиентом X5" доступны все товары всех брендов в клиенте X5 и т.д.

Область видимости группы может быть более сложной

Например,

для группы "Планировщик Stickers/X5" доступны товары бренда "Stickers" в клиенте "X5"

Пользователь может принадлежать к нескольким группам, в этом случае разрешения и области видимости будут складываться по логическому правилу "ИЛИ" (если хотя бы в одной группе есть разрешение, пользователь получает его независимо от разрешений других групп)

Например,

если пользователь принадлежит к группам "Планировщик Stickers/X5" и "Планировщик Stars/Dixy",

то ему будут доступны товары бренда "Stickers" в клиенте "X5" и товары бренда "Stars" в клиенте "Dixy"

Обратите внимание: некоторые сочетания могут приводить к "неожиданным результатам"

Например,

пользователь с группами "Планировщик Stickers/X5" и "Менеджер по работе с клиентом X5",

получит доступ КО ВСЕМ товарам для клиента "X5",

так как права будут складываться через "или", а группа "Менеджер по работе с клиентом X5" не содержит ограничений на товары

Пользователь с группами "Планировщик Stickers/X5" и "Менеджер по работе с клиентом Dixy",

получит доступ к товарам бренда "Stickers" в клиенте "X5", и ко всем товарам в клиенте "Dixy"

Пользователь с группами "Планировщик Stickers" и "Менеджер по работе с клиентом X5"

получит доступ к товарам бренда "Stickers" во всех клиентах и всем товарам в клиенте "Dixy"

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

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

Шаблоны групп

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

Например,

Бренд-менеджер {brand}

Менеджер клиента {client}

Планировщик {brand}/{client}

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

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

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

Создание групп по шаблону из интерфейса администратора

В списке групп выберите шаблон, кликнув по окошку слева от названия группы (для выбора можно воспользоваться текстовым поиском в верхней части экрана). В выпадающем списке "Действия" выберите "Создать группы по шаблону", после чего нажмите кнопку "Выполнить" справа от выпадающего меню. Дождитесь обновления страницы, группы по шаблону будут созданы.

Создание групп по шаблону с помощью сценария

Для создания группы по шаблону из консоли или через API можно использовать сценарий "Создать группы по шаблону" (запуск через пользовательский интерфейс для этого сценария не реализован).

Сценарий принимает следующие аргументы:

"""
:param id:
    int. id группы.
:param name:
    str. Имя группы или шаблона.
:param ids:
    list of int. Список id групп (если нужно экстрактировать из нескольких).
:param names:
    str. Список имён групп (если нужно экстрактировать из нескольких).
"""

Комментарий для разработчика: planiqum.core.authcustom.scripts.extract_groups_from_template.extract_groups_from_template

Пользователи

Профили пользователей доступны в разделе Пользователи и группы (расширенная функциональность) > Пользователи панели администратора.

Описание полей

Поле Название Описание
username Имя Уникальное имя пользователя.
sso SSO Используемая единая система аутентификации (подробнее см SSO
sso_login Имя пользователя SSO Имя пользователя для единой системы аутентификации
ldap_username Имя пользователя LDAP Имя пользователя, используемое при аутентификации через LDAP (подробнее см LDAP
password Пароль Хэш пароля пользователя.
first_name Имя Имя пользователя.
last_name Фамилия Фамилия пользователя.
email Email Электронная почта пользователя.
is_staff Статус персонала Логический флаг, определяющий, является ли пользователь членом персонала.
is_active Активный Логический флаг, определяющий активность учетной записи пользователя.
is_superuser Статус суперпользователя Логический флаг, определяющий наличие у пользователя прав суперпользователя.
groups Группы Список групп, к которым относится пользователь (разрешения объединяются через ИЛИ)
permissions Права пользователя Права доступа к объектам системы и права на просмотр/редактирование параметров
date_joined Дата регистрации Дата регистрации пользователя.
last_login Последний вход Время последнего входа пользователя в систему.

Разделение прав на просмотр и редактирование параметров

В разделе "группы" определяется список групп, к которым относится пользователь. В группах задаются "зоны видимости", которые определяют "к каким разделам иерархии у пользователя есть доступ" (например, "Планировщик Стикерс/X5", "Бренд-менеджер Старс", "Менеджер клиента Dixy" и т.д.) Может ли пользователь только просматривать или просматривать и редактировать данные в конкретном параметре в рамках "зоны видимости" определяется наличием или отсутствием у него прав can_view/can_edit для этого параметра.

Система позволяет ограничить "область редактирования" для пользователя. В разделе "Зона редактирования (группы)" можно указать группы, которые ограничат область редактирования пользовтеля по сравнению с областью видимости (для параметров с разрешением can_edit). Если в этом разделе пусто "зона редактирования" совпадает с "зоной видимости"

Замечание: В настоящий момент ведётся работа над функциональностью, которая позволит выдвать пользователям разные "зоны видимости" и "зоны редактирования" для разных параметров или мер

Есть возможность указать область видимости и область редактирования непосредственно для пользователя, не используя механизм групп.

Предупреждение: Этот механизм будет отключён в следующих версиях

Используйте группы для определения "области видимости" и "области редактировния"

Аутентификация пользователей

Способы аутентификации

В системе поддерживается несколько способов аутентификации пользователей:

  1. Локальная база данных (стандартная аутентификация)
  2. Single Sign-On (SSO)
  3. LDAP
  4. Azure Active Directory
  5. Omada IDM
  6. LDAP через переменные окружения (устаревший способ)

Настройка SSO

Добавление способа аутентификации

Для настройки нового способа аутентификации через SSO:

  1. В панели администратора перейдите в раздел "SSO"
  2. Нажмите "Добавить SSO"
  3. Заполните основные поля:
  4. Имя - уникальное название для этого способа аутентификации
  5. Тип - выберите один из доступных типов:
    • LDAP
    • Azure AD
    • Omada IDM
  6. Исключительно - если включено, этот способ будет использоваться для всех пользователей
  7. Нажмите "Сохранить и продолжить редактирование"
  8. После сохранения появятся дополнительные поля для настройки выбранного типа SSO:
Настройки для LDAP
  • Server URI - URI LDAP-сервера (например, ldap://localhost:389)
  • Base DN - базовый DN для поиска пользователей
Настройки для Azure AD
  • Tenant ID - ID тенанта Azure AD
  • Client ID - ID клиентского приложения
  • Client Secret - секретный ключ приложения
Настройки для Omada IDM
  • Server URL - URL сервера Omada
  • Client ID - ID клиента
  • Client Secret - секретный ключ

Определение имени пользователя

При аутентификации через SSO система определяет имя пользователя в следующем порядке:

  1. sso_login - приоритетное поле для всех типов SSO
  2. ldap_username - только для LDAP (устаревшее поле, рекомендуется использовать sso_login)
  3. username - базовое поле пользователя

Важно: Поле email НЕ используется для определения имени пользователя при аутентификации через SSO. Email используется только как fallback при неудачной аутентификации по username.

Fallback на email

Если аутентификация по username не удалась, система автоматически попробует аутентификацию по email (если SSO-провайдер поддерживает такую возможность):

  • LDAP: Поддерживает аутентификацию по email
  • Azure AD: Поддерживает аутентификацию по email
  • Omada IDM: Поддерживает аутентификацию по email

При fallback на email в журнале попыток аутентификации будет зафиксировано: - auth_method: "email" - login_value: email пользователя - sso_server: настройки SSO-сервера

Привязка SSO к пользователю

После создания SSO его можно привязать к пользователю:

  1. В панели администратора перейдите в раздел "Пользователи"
  2. Выберите пользователя или создайте нового
  3. В форме редактирования пользователя:
  4. Заполните поле "SSO" - выберите созданный ранее способ аутентификации
  5. Для LDAP укажите "Имя пользователя LDAP"
  6. Для Azure AD и Omada укажите "SSO Login"
  7. Сохраните изменения

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

Использование LDAP через переменные окружения

!!! warning "Устаревший способ" Этот способ настройки LDAP является устаревшим. Рекомендуется использовать настройку через SSO:

1. Создайте новый SSO с типом "LDAP"
2. Укажите в настройках:
   - Server URI (аналог AUTH_LDAP_SERVER_URI)
   - Base DN (аналог AUTH_LDAP_BASE_DN)
3. Если требуется использовать LDAP для всех пользователей, включите опцию "Исключительно"
4. Для пользователей укажите их LDAP-имена в поле "Имя пользователя LDAP"

Процесс аутентификации

  1. Заполнение формы входа Пользователь вводит имя пользователя и пароль в форму входа на сайте.

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

  3. Выбор метода аутентификации На основе конфигурации системы выбирается метод аутентификации:

  4. Эксклюзивная SSO-система: Если в настройках указан эксклюзивный SSO-провайдер (приоритет 1)
  5. Привязанная SSO-система: Если у пользователя есть привязанный SSO-провайдер (приоритет 2)

  6. Локальная база данных: Если пользователь не привязан к системе SSO (приоритет 3)

  7. Определение имени пользователя для аутентификации

  8. Для SSO: sso_login → ldap_username (только LDAP) → username

  9. Для локальной аутентификации: только username (поле sso_login игнорируется)

  10. Аутентификация через SSO

  11. Первая попытка: Аутентификация по определенному username
  12. Fallback на email: Если первая попытка не удалась и SSO поддерживает email-аутентификацию

  13. Типы SSO:

    • LDAP: Подключение к серверу LDAP
    • Azure Active Directory: Запрос к Microsoft Graph API
    • Omada IDM: Запрос через Omada API

  14. Результат аутентификации

  15. При успехе пользователь получает доступ к системе
  16. При ошибке выводится сообщение об ошибке
  17. Все попытки логируются в журнал аутентификации

Настройка профиля пользователя

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

Поле Имя Комментарий
username Имя пользователя Уникальное имя для входа в систему
password Пароль Для локальной аутентификации
ldap_username Имя пользователя LDAP Для LDAP-аутентификации
sso_login Имя пользователя SSO Для Azure AD, Omada и LDAP
email Email Может использоваться как имя пользователя для LDAP
sso SSO Выбор способа аутентификации
force_password_change Принудительная смена пароля Запрос смены пароля при входе

При аутентификации через LDAP система определяет имя пользователя в следующем порядке: 1. Значение поля sso_login, если оно заполнено 2. Значение поля ldap_username, если оно заполнено 3. Значение поля email, если оно заполнено 4. Значение поля username как последний вариант

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

Регистрация событий информационной безопасности (ИБ)

В системе регистрируются события ИБ, связанные с изменениями профилей пользователей (включая пароль), разрешений на уровне групп, а также привязки пользователя к группам.

Комментарий для разработчика: planiqum/core/authcustom/signals.py

ИБ Уровни критичности

Для событий информационной безопасности может быть определён "уровень критичности". Для каждого уровня критичности может быть установлен флаг "Регистрировать событие", события с таким уровнем критичности будут регистрироваться в журнале событий ИБ. На данный момент этот показатель используется только для фильтрации событий информационной безопасности в журнале событий. Пользователь с соответствующими правами может добавлять, редактировать и удалять уровни критичности. Уровни критичности могут быть присвоены существующим в системе ключам событий информационной безопасности.

ИБ Ключи событий

Список событий информационной безопасности закреплён в системе и не подлежит изменению. Администратор может только присваивать уровни критичности ключам событий информационной безопасности.

Название Комментарий Уровень критичности по уолчанию
group_permissions_changed Изменение набора разрешений для группы Критичность 2
user_groups_changed Изменение набора групп для пользователя Критичность 2
user_permissions_changed Изменение набора разрешений пользователя Критичность 2
user_deleted Удаление пользователя Критичность 2
user_created Создание нового пользователя Критичность 1
user_changed Изменение данных пользователя (любое из полей, включая пароль) Критичность 1

ИБ Журнал событий

События ИБ, перечисленные в предыдущем пункте регистрируются в журнале событий ИБ.

Поле Название Комментарий Обязательное
id ID Уникальный идентификатор, автоматически присваивается системой Да
key Ключ события Связь с моделью InfoSecureEventKey, определяет тип события Да
name Название Название события Да
changed_by Внес изменения Связь с пользователем, который внёс изменения Нет
changed_by_ip Внес изменения (IP) IP-адрес пользователя, внёсшего изменения Нет
changed_date Дата изменения Дата и время, когда были внесены изменения (автоматически) Да
description Описание Дополнительное описание события Нет

Сессии

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

Поле Название Описание
pk Уникальный идентификатор Первичный ключ сессии
user Пользователь Ссылка на пользователя
ip IP IP-адрес устройства
device Устройство Информация об устройстве
os ОС Операционная система устройства
browser Браузер Используемый браузер
last_activity Последняя активность Время последней активности сессии

Управление замещениями пользователя

Временный доступ и замещение

Временное членство в группе

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

Настройка временного доступа

  1. Перейдите в раздел "Пользователи и группы > Временное членство в группе"
  2. Нажмите "Добавить временное членство в группу"
  3. Заполните поля:
  4. Пользователь - выберите пользователя
  5. Группа - выберите группу
  6. Дата начала - с какого числа предоставить доступ
  7. Дата окончания - до какого числа предоставить доступ
  8. Права - выберите права, которые будут предоставлены
  9. Параметры - выберите параметры, к которым будет предоставлен доступ

Особенности временного доступа

  • Временный доступ может быть предоставлен как к правам, так и к параметрам
  • Можно указать только дату начала (доступ будет предоставлен бессрочно)
  • Можно указать только дату окончания (доступ будет предоставлен с момента создания)
  • Если не указаны ни дата начала, ни дата окончания, доступ будет предоставлен бессрочно
  • Права и доступ к параметрам предоставляются только на период действия временного членства

Замещение пользователей

Система позволяет настроить замещение одного пользователя другим на определенный период.

Настройка замещения

  1. Перейдите в раздел "Пользователи и группы > Замещения"
  2. Нажмите "Добавить замещение"
  3. Заполните поля:
  4. Замещаемый пользователь - пользователь, которого замещают
  5. Замещающий пользователь - пользователь, который замещает
  6. Дата начала - с какого числа действует замещение
  7. Дата окончания - до какого числа действует замещение

Особенности замещения

  • Замещающий пользователь получает все права и доступ к параметрам замещаемого пользователя
  • Замещение может быть настроено как с датами, так и бессрочно
  • В период замещения замещающий пользователь может выполнять все действия от имени замещаемого
  • Замещение не влияет на права, полученные замещающим пользователем через группы

Проверка прав доступа

Система автоматически проверяет: 1. Действительность временного членства в группе 2. Действительность замещения 3. Наличие необходимых прав у пользователя

При проверке прав учитываются: - Постоянные права из групп - Временные права из временного членства - Права, полученные через замещение

Примеры использования

Временное членство

# Пример предоставления временного доступа к параметру
membership = UserGroupMembership.objects.create(
    user=user,
    group=group,
    start_date='2024-03-01',
    end_date='2024-03-31',
    parameters=[(parameter.id, None, None)]
)

Замещение

# Пример настройки замещения
substitution = UserSubstitution.objects.create(
    user=substituted_user,
    substitute=substituting_user,
    start_date='2024-03-01',
    end_date='2024-03-31'
)

Ограничения

  1. Временное членство:
  2. Нельзя предоставить доступ к параметрам, к которым у пользователя нет базового доступа

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

  4. Замещение:

  5. Замещающий пользователь должен иметь базовые права на работу в системе
  6. Замещение не может быть настроено для суперпользователя
  7. Нельзя настроить циклическое замещение (A замещает B, B замещает A)

Управление замещениями через профиль пользователя

В административной панели (Django Admin) замещения можно просматривать и редактировать прямо из профиля пользователя:

  • На странице редактирования пользователя отображаются две таблицы:
  • Замещается — список замещающих выбранного пользователя
  • Замещает — список пользователей, которых замещает выбранный пользователь
  • В этих таблицах можно добавлять, изменять и удалять замещения без перехода в отдельный раздел
  • Это позволяет быстро управлять замещениями непосредственно при работе с профилем пользователя

Данная возможность реализована с помощью inline-таблиц (OriginalUserInline и SubstituteUserInline) в настройках админки

Для разработчика

Архитектура аутентификации

Система аутентификации построена на основе нескольких бэкендов, каждый из которых отвечает за свой метод аутентификации:

  1. Django ModelBackend (CustomModelBackend)
  2. Стандартная аутентификация Django
  3. Проверяет учетные данные в локальной базе данных

  4. Используется как fallback, если другие методы недоступны

  5. LDAP Backend (LDAPBackend)

  6. Реализован в authentification_ldap.py
  7. Использует библиотеку python-ldap

  8. Поддерживает конфигурацию через переменные окружения

  9. SSO Backend (SSOBackend)

  10. Реализован в authentification_sso.py
  11. Поддерживает несколько провайдеров SSO
  12. Использует стратегию выбора провайдера на основе конфигурации

Модели данных

  1. SSO 

    class SSO(Model):
    TYPE_CHOICES = [
        ('ldap', 'LDAP'),
        ('azure', 'Azure AD'),
        ('omada', 'Omada IDM')
    ]
    name = models.CharField(max_length=255)
    type = models.CharField(max_length=50, choices=TYPE_CHOICES)
    exclusive = models.BooleanField(default=False)

  2. Провайдер-специфичные модели

  3. SSOLDAP: Настройки LDAP-подключения
  4. SSOAzure: Настройки Azure AD
  5. SSOOmada: Настройки Omada IDM

Процесс аутентификации

  1. Инициализация
  2. Система получает учетные данные пользователя

  3. Проверяет наличие пользователя в базе данных

  4. Выбор метода 

    def authenticate(self, request, username=None, password=None, **kwargs):
    user = User.objects.get(username=username)
    exclusive_sso = SSO.objects.filter(exclusive=True).first()

    if exclusive_sso:
        return self._authenticate_sso(user, password, exclusive_sso)
    elif user.sso:
        return self._authenticate_sso(user, password, user.sso)
    else:
        return self._authenticate_local(user, password)

  5. SSO-аутентификация

  6. Каждый провайдер имеет свой метод аутентификации
  7. Реализовано через отдельные методы в SSOBackend
  8. Поддерживает расширение для новых провайдеров

Добавление нового провайдера SSO

Для добавления нового провайдера SSO необходимо:

  1. Создать модель настроек провайдера: 

    class SSONewProvider(models.Model):
    sso = models.OneToOneField(SSO, on_delete=models.CASCADE, primary_key=True)
    # Специфичные для провайдера поля

  2. Добавить тип в SSO.TYPE_CHOICES

  3. Реализовать метод аутентификации в SSOBackend: 

    def _authenticate_new_provider(self, sso_login, password, provider_settings):
    # Логика аутентификации

  4. Обновить метод _authenticate_sso для поддержки нового провайдера

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

  1. Хранение учетных данных
  2. Пароли никогда не хранятся в открытом виде
  3. Секретные ключи провайдеров хранятся в зашифрованном виде

  4. Поддерживается история паролей

  5. Защита от атак

  6. Реализована защита от брутфорс-атак
  7. Ведется журнал попыток входа

  8. Поддерживается блокировка по IP

  9. Аудит

  10. Все действия с аутентификацией логируются
  11. Поддерживается отслеживание активных сессий
  12. Реализован механизм принудительного завершения сессий

Настройка профиля пользователя в панели администратора Django

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

Поля профиля пользователя

Поле Имя Комментарий
username Имя пользователя Уникальное имя для входа в систему
password Пароль Для локальной аутентификации
ldap_username Имя пользователя LDAP Для LDAP-аутентификации
sso_login Имя пользователя SSO Для Azure AD, Omada и LDAP
email Email Может использоваться как имя пользователя для LDAP
sso SSO Выбор способа аутентификации
force_password_change Принудительная смена пароля Запрос смены пароля при входе

Рекомендации по настройке

  1. Выбор метода аутентификации
  2. Для локальной аутентификации достаточно заполнить username и password
  3. Для LDAP необходимо указать ldap_username

  4. Для SSO нужно выбрать провайдера в поле sso и указать sso_login при необходимости

  5. Эксклюзивный режим SSO

  6. Если в системе настроен эксклюзивный SSO, он будет использоваться для всех пользователей
  7. Локальные пароли в этом режиме игнорируются

  8. Можно настроить только один эксклюзивный SSO

  9. Безопасность

  10. Регулярно проверяйте настройки SSO-провайдеров
  11. Используйте принудительную смену пароля при первом входе
  12. Следите за журналом попыток входа

Добавление способов аутентификации

В этой модели хранятся именованные способы реализации SSO, которые можно использовать в профиле пользователя. Этот механизм только проверяет пароль пользователя во внешней системе согласно настройкам. Он не создаёт пользователей на основании данных из внешних систем.

Поле Название Описание Обязательное
name Имя Уникальное имя метода аутентификации Да
type Тип Тип аутентификации ('LDAP', 'Azure AD', 'Omada IDM') Да
exclusive Исключительно Если True, этот SSO будет использоваться для всех пользователей Нет

Настройка провайдеров SSO

  1. LDAP
  2. server_uri: URI LDAP-сервера (например, ldap://localhost:389)

  3. base_dn: Базовый DN для поиска пользователей

  4. Azure AD

  5. tenant_id: ID тенанта Azure AD
  6. client_id: ID клиентского приложения

  7. client_secret: Секретный ключ приложения

  8. Omada IDM

  9. server_uri: URI сервера Omada
  10. client_id: ID клиента
  11. client_secret: Секретный ключ

При создании новой конфигурации SSO: 1. Укажите "Тип" и сохраните изменения 2. После сохранения появятся дополнительные поля для выбранного типа 3. Заполните все обязательные поля для выбранного провайдера 4. Проверьте работоспособность аутентификации с тестовым пользователем

Журнал попыток аутентификации

В системе реализован отдельный журнал для аудита всех попыток входа пользователей (локальная и SSO-аутентификация).

Где искать журнал

Журнал доступен в административной панели Django:

  • Раздел: Пользователи и группы (расширенная функциональность) > Журнал попыток аутентификации (модель AuthAttemptLog).
  • Также может называться "Журнал попыток входа" или "Authentication Attempts" в зависимости от локализации.

Какие колонки содержит

В журнале отображаются основные поля:

  • Пользователь — ссылка на профиль пользователя (если найден).
  • Имя пользователя — логин, использованный при попытке.
  • SSO — использованный SSO-провайдер (если применимо).
  • Информация об аутентификации — JSON-структура с деталями:
  • auth_method: способ аутентификации ("username" или "email")
  • login_value: фактическое значение, использованное для входа
  • sso_server: настройки SSO-сервера (без секретных данных)
  • Настройки SSO — параметры подключения (например, server_uri, base_dn для LDAP; tenant_id, client_id для Azure и т.д.).
  • IP-адрес — адрес, с которого была совершена попытка.
  • User-Agent — строка браузера/клиента.
  • Результат — успешна ли попытка (да/нет).
  • Тип ошибки — классифицированный тип ошибки (connection, credentials, timeout и др.).
  • Сообщение об ошибке — оригинальный текст ошибки, если попытка не удалась.
  • Время — дата и время попытки.

Доступные фильтры

Можно фильтровать журнал по:

  • пользователю;
  • имени пользователя (логину);
  • SSO-провайдеру;
  • успешности попытки (да/нет);
  • дате/времени;
  • IP-адресу;
  • наличию ошибок.

Как происходит регистрация попыток

Каждая попытка входа (успешная и неуспешная) автоматически фиксируется системой. В журнале сохраняется:

  • Способ аутентификации: "username" или "email" (в зависимости от того, что использовалось)
  • Фактический логин: значение, которое было использовано для входа (определяется по приоритету)
  • Настройки SSO: параметры подключения к SSO-серверу (без секретных данных)
  • Результат: успех/ошибка
  • Классификация ошибок: тип ошибки (connection, credentials, timeout, server_error, technical, user_not_found, unknown)
  • Оригинальное сообщение об ошибке: полный текст ошибки для детального анализа
  • Технические детали: IP-адрес, user-agent, время попытки
  • Ссылка на пользователя: если пользователь найден в системе

Типы ошибок в журнале

Система автоматически классифицирует ошибки аутентификации:

  • connection — ошибки подключения к серверу (соединение отклонено, сеть недоступна)
  • timeout — таймауты соединения (превышено время ожидания)
  • credentials — неверные учетные данные (неправильный логин или пароль)
  • user_not_found — пользователь не найден в системе
  • server_error — ошибки сервера (5xx HTTP коды)
  • technical — технические ошибки системы
  • unknown — неклассифицированные ошибки (оригинальное сообщение сохраняется)

Это позволяет отслеживать все попытки входа, выявлять подозрительную активность, расследовать инциденты и проводить аудит безопасности.

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