Концепции и архитектура

Архитектура системы

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

Основные компоненты

Взаимодействие компонентов

Типичный сценарий входа пользователя в приложение через IDENTYX:

1. Пользователь открывает приложение — приложение перенаправляет на IDENTYX для аутентификации
2. IAM Core проверяет сессию — если пользователь уже авторизован, пропускает шаг входа
3. Authentication Handler обрабатывает вход — проверяет логин/пароль, LDAP или внешнего провайдера (Сбер ID, ЕСИА)
4. Проверка 2FA (если включена) — запрос TOTP кода или отправка кода на email
5. OIDC Provider выдает токены — создается сессия, генерируются Access Token, ID Token и Refresh Token
6. Приложение получает токены — приложение обменивает authorization code на токены
7. Приложение запрашивает данные пользователя — через UserInfo endpoint получает информацию о пользователе и его правах

Модель прав доступа (RBAC)

IDENTYX использует модель управления доступом на основе ролей (Role-Based Access Control, RBAC), которая позволяет гибко настраивать права доступа для пользователей и групп.

Структура системы прав

Система прав в IDENTYX построена на трех ключевых понятиях:

Формат прав доступа

Права в IDENTYX задаются в формате:

объект:действие:тип

Где:

• объект — путь к защищаемому объекту (например, /menu/users)
• действие — операция над объектом (например, /menu/allow)
• тип — allow (разрешение) или deny (запрет)

Примеры прав:

• /menu/users:/menu/allow:allow — разрешить доступ к разделу "Пользователи"
• /iam:/iam/users/edit:allow — разрешить редактирование пользователей
• /org/company-a:/iam/local-admin:allow — дать права локального администратора на организацию "company-a"
• /menu/settings:/menu/allow:deny — запретить доступ к разделу "Настройки"

Наследование прав

IDENTYX поддерживает wildcard права с использованием символа /* для распространения прав на все дочерние объекты:

• /menu/*:/menu/allow:allow — разрешить доступ ко всем пунктам меню
• /org/*:/iam/local-admin:allow — дать права локального администратора на все организации
• /*:/*:allow — суперадминистратор (полные права на всё)

При проверке прав система проверяет не только точное совпадение, но и права с wildcard по всей иерархии объектов.

Приоритет deny над allow

Пример:

• Пользователь входит в группу "Администраторы" с правом /menu/*:/menu/allow:allow (доступ ко всему меню)
• Но пользователю индивидуально назначено право /menu/settings:/menu/allow:deny (запрет настроек)
• Результат: пользователь видит всё меню кроме раздела "Настройки"

Субъекты безопасности

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

Пользователь — это индивидуальная учетная запись в системе IDENTYX. Каждый пользователь имеет:

• username — уникальное имя для входа (логин)
• display_name — отображаемое имя пользователя
• email — адрес электронной почты
• Пароль — для локальной аутентификации (хранится в зашифрованном виде)
• Методы аутентификации — привязанные способы входа (LDAP, OAuth провайдеры, WebAuthn)
• Группы — членство в группах для наследования прав
• Организации — назначение в одну или несколько организаций
• Индивидуальные права — правила доступа, назначенные напрямую пользователю

Группы

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

Типы групп:

Тип группы	Описание	Примеры
Локальные группы	Создаются и управляются в IDENTYX	Бухгалтеры, Разработчики, Менеджеры
Системные группы	Предустановленные группы с особым поведением	"Все" (все пользователи), "Администраторы IAM" (полные права)

Наследование прав через группы:

• Пользователь может входить в несколько групп одновременно
• Права от всех групп суммируются
• Индивидуальные права пользователя добавляются к групповым правам
• Правило deny имеет приоритет работает и при наследовании прав

Организации

Организации позволяют разделять пользователей, группы и приложения по отделам, филиалам или компаниям. Это полезно для:

• Ограниченного администрирования — назначение локальных администраторов для конкретных организаций
• Разделения прав — предоставление доступа только к ресурсам своей организации
• Структурирования данных — логическая группировка пользователей и групп

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

Процесс аутентификации в IDENTYX включает несколько этапов, которые обеспечивают безопасность и гибкость входа пользователей.

Этапы аутентификации

1. Выбор метода входа

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

   • Логин и пароль (локальная база данных)
   • Вход через LDAP/Active Directory
   • Внешние провайдеры (Сбер ID, ЕСИА, Яндекс ID, VK ID, Telegram)
   • Электронная подпись (КриптоПро)
   • WebAuthn (биометрия или ключи безопасности)
2. Первичная проверка учетных данных

   Authentication Handler проверяет предоставленные учетные данные:

   • Для локальной аутентификации проверяется логин и пароль в базе данных
   • Для LDAP выполняется запрос к LDAP-серверу
   • Для OAuth провайдеров происходит перенаправление на провайдера и обмен кодом авторизации
3. Проверка блокировки учетной записи

   Система проверяет, не заблокирован ли пользователь:

   • Ручная блокировка администратором
   • Автоматическая блокировка при превышении попыток неправильного ввода пароля
   • Блокировка из-за истечения срока действия пароля
4. Двухфакторная аутентификация (2FA)

   Если для пользователя или глобально включена 2FA, запрашивается второй фактор:

   • TOTP — пользователь вводит код из приложения-аутентификатора
   • Email — система отправляет код на email пользователя
   • Пропуск 2FA — при использовании WebAuthn (если настроено)
5. Создание IAM сессии

   После успешной аутентификации создается сессия пользователя:

   • Генерируется уникальный идентификатор сессии
   • Сохраняется информация о пользователе, IP-адресе, времени входа
   • Ограничивается количество одновременных сессий (если настроено)
6. Согласие с офертой (если требуется)

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

7. Выдача токенов (для OIDC)

   OIDC Provider создает токены для доступа к приложению:

   • Authorization Code — временный код для обмена на токены
   • Access Token — токен для доступа к защищенным ресурсам
   • ID Token (JWT) — токен с информацией о пользователе
   • Refresh Token — токен для обновления Access Token
8. Перенаправление в приложение

   Пользователь перенаправляется обратно в приложение с authorization code. Приложение обменивает код на токены и получает доступ к данным пользователя через UserInfo endpoint.

OIDC протокол в IDENTYX

OpenID Connect (OIDC) — это протокол аутентификации, построенный на основе OAuth 2.0. IDENTYX выступает в роли OIDC Provider (сервера аутентификации), а приложения являются OIDC клиентами.

Authorization Code Flow

IDENTYX использует Authorization Code Flow — наиболее безопасный способ аутентификации для веб-приложений:

1. Приложение инициирует вход

   Приложение перенаправляет пользователя на IDENTYX с параметрами:

   GET /login/oidc?
     response_type=code
     &client_id=ваш_client_id
     &redirect_uri=https://ваше-приложение/callback
     &scope=openid profile email permissions
     &state=случайная_строка

2. Пользователь проходит аутентификацию

   IDENTYX показывает форму входа, пользователь вводит учетные данные, проходит 2FA (если требуется) и дает согласие на доступ к данным.

3. IDENTYX выдает authorization code

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

   HTTP 302 Found
   Location: https://ваше-приложение/callback?code=aTeMpOrArYcOdE&state=случайная_строка

4. Приложение обменивает код на токены

   Приложение отправляет запрос на Token Endpoint:

   POST /api/service/oidc/token
   Content-Type: application/x-www-form-urlencoded
   
   grant_type=authorization_code
   &client_id=ваш_client_id
   &client_secret=ваш_client_secret
   &redirect_uri=https://ваше-приложение/callback
   &code=aTeMpOrArYcOdE

5. IDENTYX возвращает токены

   {
     "access_token": "случайная_строка_32_символа",
     "token_type": "Bearer",
     "expires_in": 3600,
     "refresh_token": "другая_случайная_строка",
     "id_token": "JWT_токен_с_информацией_о_пользователе"
   }

6. Приложение получает данные пользователя

   Используя Access Token, приложение запрашивает UserInfo Endpoint:

   GET /api/service/oidc/userinfo
   Authorization: Bearer access_token

   Ответ содержит информацию о пользователе:

   {
     "sub": "идентификатор_пользователя",
     "name": "Иван Иванов",
     "email": "ivan@example.com",
     "username": "ivanov",
     "permissions": [
       "/app1:/access:allow",
       "/app1:/admin:allow"
     ]
   }

Типы токенов

Токен	Назначение	Срок действия
Access Token	Используется для доступа к защищенным ресурсам (например, UserInfo endpoint)	По умолчанию 3600 секунд (1 час)
ID Token (JWT)	Содержит информацию о пользователе и событии аутентификации. Представлен в формате JSON Web Token	Не имеет срока действия (проверяется по дате выдачи)
Refresh Token	Используется для получения нового Access Token без повторной аутентификации пользователя	По умолчанию 86400 секунд (1 день)

Scopes (области доступа)

IDENTYX поддерживает следующие scopes:

• openid — обязательный scope для OIDC, указывает что это OpenID Connect аутентификация
• profile — доступ к профилю пользователя (имя, отображаемое имя)
• email — доступ к email пользователя
• permissions — доступ к правам пользователя (массив прав доступа в формате ACL)

Пример запроса с scopes:

scope=openid profile email permissions

Обновление токенов

Когда Access Token истекает, приложение может получить новый токен используя Refresh Token:

POST /api/service/oidc/token
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&client_id=ваш_client_id
&client_secret=ваш_client_secret
&refresh_token=ваш_refresh_token

В ответ IDENTYX выдает новый Access Token и, при необходимости, новый Refresh Token.

Завершение сессии (Logout)

IDENTYX поддерживает Backchannel Logout — механизм завершения сессии во всех приложениях одновременно. Когда пользователь выходит из IDENTYX или администратор принудительно завершает сессию, IDENTYX отправляет уведомления всем приложениям, где пользователь был авторизован.

Резюме

В этом разделе вы познакомились с ключевыми концепциями IDENTYX:

• Модульная архитектура — система состоит из независимых компонентов (IAM Core, OIDC Provider, Proxy, Authentication Handlers)
• RBAC модель прав — права задаются через объекты, действия и субъекты в формате объект:действие:тип
• Иерархия и наследование — wildcard права (/*) распространяются на дочерние объекты
• Приоритет deny — правила запрета всегда имеют приоритет над разрешениями
• Поток аутентификации — многоэтапный процесс с поддержкой 2FA и различных методов входа
• OIDC протокол — стандартный способ интеграции приложений с использованием Authorization Code Flow и токенов