Корпоративная инфраструктура идентичности не сводится к одному протоколу.
Архитектура идентичности современных организаций неоднородна. Пока одна команда использует централизованный каталог, другое бизнес-подразделение может нуждаться в старой системе проверки на базе RADIUS, внешняя группа пользователей — в социальной идентичности, а приложение, оказывающее государственную услугу, — в национальной электронной идентификации (e-ID). В проектах fintech, здравоохранения и государственного сектора часто встречаются и кастомные REST-сервисы идентичности.
Традиционные платформы доступа часто обрабатывают это разнообразие по отдельности. Для каждого провайдера возникает своя интеграция, свой audit-след, своё поведение при ошибке и свой поток MFA. В итоге политика безопасности фрагментируется; оператор вынужден управлять одним и тем же пользователем в разных системах по-разному.
Legacy-системы — отдельная проблема. Менять годами работающую инфраструктуру проверки на базе RADIUS или web form и дорого, и рискованно. Но без добавления перед этими системами слоя MFA, условного доступа, lockout, IP-контроля и аудита выйти на современный уровень zero-trust невозможно.
Кастомные API идентичности показывают тот же пробел. Если собственная система проверки клиентов, OTP или мобильной идентификации организации предоставляет HTTP-эндпоинт, платформа доступа должна уметь использовать его как провайдер идентичности. Иначе каждое приложение вынуждено писать собственную интеграцию.
TR7 AAM объединяет разные модели провайдеров идентичности в едином слое authentication provider; он связывает провайдеры RADIUS, OAuth2, HTTP API, Web Form, LocalDB и Portal с одним и тем же движком доступа, MFA и audit.
Наш подход
TR7 AAM запускает разные источники идентичности под единой моделью провайдера и переносит результат каждой проверки в одну и ту же цепочку принятия решения о доступе.
Единая модель authentication provider объединяет всех провайдеров
Провайдеры RADIUS, OAuth2, HTTP API, Web Form, LocalDB и Portal определяются как один и тот же объект провайдера. Движок потока обрабатывает каждого провайдера одинаково — с переходами успеха, ошибки, lockout и MFA.
RADIUS модернизирует legacy-проверку, не меняя её
С поддержкой PAP и CHAP существующие сервисы RADIUS можно поставить за AAM. Имеющаяся система проверки сохраняется; поверх неё добавляются MFA, условный доступ, lockout и audit.
OAuth2 связывает социальные и государственные идентичности с потоком доступа
Встроенные провайдеры OAuth2 и кастомные конфигурации OAuth2 могут быть подключены к AAM. Сценарии вроде ограничения по домену Google Workspace и маппинга полей национальной e-ID включаются в единый движок доступа.
Коннектор HTTP API подключает кастомные системы идентичности
Собственный REST-сервис идентичности, система OTP или эндпоинт проверки клиентов организации могут использоваться как провайдер AAM. Настройка method, header, body и условий успеха снижает потребность в дополнительной разработке.
Возможности
Дополнительные интеграции провайдеров идентичности переносят разные источники идентичности — от legacy-систем проверки до кастомных REST API — в общую модель безопасности AAM.
Поддержка RADIUS PAP и CHAP охватывает legacy-инфраструктуры
TR7 AAM поддерживает на стороне RADIUS типы проверки PAP и CHAP. PAP обеспечивает более простую legacy-совместимость; CHAP предлагает поведение проверки на основе challenge. Существующую инфраструктуру RADIUS можно поставить перед AAM без её изменения. Это практичный путь модернизации для telco, NAC, старых VPN и корпоративных систем доступа.
Общий секретный ключ RADIUS устанавливает безопасную связь с провайдером
Для каждого сервиса RADIUS может быть определён отдельный общий секретный ключ. Так связь проверки между AAM и сервером RADIUS разделяется по провайдерам. В средах с несколькими RADIUS каждая интеграция имеет собственную границу безопасности. Операционные изменения управляются через единую централизованную конфигурацию.
Поддержка нескольких серверов RADIUS обеспечивает поведение failover
Под одним провайдером можно определить несколько серверов RADIUS. Если первичный сервер не отвечает, может вступить вторичный. Эта структура работает с коротким timeout и быстрым переключением, соответствующим UDP-природе RADIUS. Legacy-система идентичности становится ближе к модели высокой доступности.
Ограничение Google OAuth2 по hosted-domain ограничивает корпоративные входы
Провайдер Google OAuth2 может быть ограничен определённым доменом Workspace. Так обеспечивается вход только пользователей домена, принадлежащего организации. Поведение access type и prompt может быть настроено в рамках потока OAuth2. Внешняя социальная идентичность становится контролируемой корпоративной политикой доступа.
OAuth2 национальной e-ID обеспечивает вход через государственную идентичность
Провайдер OAuth2 национальной электронной идентификации (e-ID) работает со встроенными маппингами полей для сценариев государственной идентичности. Поля вроде идентификационного номера, имени, фамилии, e-mail, телефона и даты рождения могут переноситься в объект пользователя AAM. Поток с поддержкой PKCE повышает безопасность аутентификации. В приложениях, оказывающих государственные услуги, гражданская идентичность подключается к цепочке доступа AAM.
Кастомные провайдеры OAuth2 подключаются с полным определением эндпоинтов
В режиме custom OAuth2 можно отдельно определить authorization URL, token URL, userinfo URL, logout URL и revocation URL. Настраиваются Client ID, secret, scope, response type, grant type и поведение PKCE. Так кастомные корпоративные системы идентичности, говорящие на стандартном OAuth2, включаются в AAM. Интеграция управляется в рамках единой модели провайдера.
Аутентификация Web Form использует legacy-экраны входа
Некоторые старые приложения не предоставляют стандартного протокола; у них есть только web login-форма. TR7 AAM может определить с провайдером web form login URL, поля формы и условия успеха. Успех может распознаваться по поведению redirect, cookie или status code. Так экран входа старого приложения можно взять в цепочку контроля AAM.
Провайдер HTTP API использует кастомные REST-системы идентичности
Провайдер HTTP API превращает любой REST-эндпоинт в источник аутентификации. Могут использоваться методы GET, POST или PUT; типы body JSON, multipart, URL-encoded или raw. Условие успеха может оцениваться по status code, наличию cookie или redirect URL. Системы банковского OTP, проверки клиентов или кастомной мобильной верификации могут быть подключены по этой модели.
Локальная база пользователей покрывает offline и внешние пользовательские сценарии
Провайдер LocalDB использует локальное хранилище пользователей, управляемое внутри AAM. Он подходит для сред без подключения к интернету, тестовых систем, учётных записей внешних партнёров или доступа, независимого от централизованного хранилища идентичности. Могут применяться базовые контроли безопасности, такие как история паролей. Это облегчает независимые и self-hosted сценарии использования.
Провайдер Portal может сделать другой портал AAM источником идентичности
Провайдер Portal может использовать другой portal gateway AAM как источник аутентификации. Эта структура поддерживает SSO-подобные сценарии перехода между несколькими порталами или разными точками доступа. Пользователь проходит проверку в единой цепочке AAM и может быть перенесён к другим точкам доступа. В крупных корпоративных развёртываниях это упрощает архитектуру порталов.
Маппинг пользователей преобразует всех провайдеров в стандартный объект идентичности
Каждый провайдер может возвращать разные имена полей. С помощью TR7 userMapping значения source attribute маппируются на стандартные поля AAM. Например, идентификационный номер, e-mail, группа, телефон или display name переносятся в общий объект пользователя. MFA, условный доступ и инъекция SSO в backend работают через этот стандартный объект.
Политика lockout на уровне провайдера снижает риск brute force
Каждый authentication provider может наследовать, расширять или переопределять собственное поведение lockout. Так провайдеры вроде RADIUS, HTTP API или LocalDB могут иметь разный порог неудачных входов. Защита от brute force не зажата в единую глобальную настройку. Политика определяется в соответствии с профилем риска провайдера идентичности.
Операционная глубина
Дополнительные провайдеры идентичности должны проектироваться вместе с поведением протокола, сетевым доступом, маппингом пользователей, управлением неудачными входами и audit-следами.
Поведение RADIUS UDP
RADIUS работает на базе UDP; у него нет классической логики пула TCP-соединений. Значения timeout должны планироваться короткими, а поведение failover — быстрым. Если определяется несколько серверов RADIUS, время отклика и порядок должны выбираться внимательно.
OAuth2 state и PKCE
В потоках OAuth2 state и PKCE снижают риски CSRF и повторного воспроизведения. В государственных или мобильно-ориентированных сценариях поведение PKCE особенно важно. При настройке провайдера должны сохраняться безопасные предположения.
Условия успеха HTTP
Провайдер HTTP API не обязан смотреть только на status code. Могут использоваться дополнительные условия успеха, такие как наличие cookie или redirect URL. Это обеспечивает адаптацию к разному поведению успеха кастомных сервисов идентичности.
Инъекция smart variable
В полях HTTP path, body, header и Web Form могут использоваться вводы пользователя или переменные AAM. Имя пользователя, OTP или другие поля ввода могут динамически добавляться в запрос идентичности. Это поведение должно использоваться с тщательной валидацией.
Выбор сетевой области
Некоторые типы провайдеров должны выходить из правильной сетевой области для доступа к внешнему провайдеру идентичности. Провайдеры OAuth2, OIDC или Web Form могут нуждаться в разных route table. Выбор сети на уровне провайдера критичен для успеха интеграции.
Audit и SIEM-след
Каждая попытка провайдера должна записываться в audit log с результатом «успешно», «неудачно» или «заблокировано». Тип провайдера, пользователь, исходный IP и информация о результате могут передаваться в SIEM. Это обеспечивает объединённый аудит в фрагментированной инфраструктуре идентичности.
В каких сценариях применяется
Модернизация legacy-инфраструктуры RADIUS с помощью MFA
Старая система проверки RADIUS, работающая в среде telco или ISP, сохраняется. Поставив перед ней TR7 AAM, добавляют MFA, условный доступ и централизованный audit.
Вход в государственное приложение через национальную e-ID
Муниципальный или государственный портал может выполнять вход граждан через OAuth2 национальной e-ID. Поля идентичности переносятся в сессию AAM, а доступ к услуге управляется правилами условного доступа.
Совместное использование Google, каталога и RADIUS в гибридной организации
Разные регионы или команды могут использовать разные системы идентичности. TR7 AAM объединяет этих провайдеров под единым gateway и единой моделью аудита.
Превращение банковского REST API идентичности в провайдер
Если сервис проверки клиентов или OTP банка предоставляет REST API, AAM может вызывать его как HTTP-провайдер. Успех проверяется по условию status code, cookie или redirect.
Использование локальной базы пользователей для внешних партнёров
Учётные записи партнёров, которые не будут заведены в централизованный корпоративный каталог, можно управлять в AAM LocalDB. К этим учётным записям применяются отдельные MFA, lockout и политика доступа.
Часто задаваемые вопросы
Какие типы authentication provider поддерживает TR7 AAM?
Нужно ли мне менять существующий сервис RADIUS?
Как работает интеграция OAuth2 национальной e-ID?
Какие условия успеха поддерживает провайдер HTTP API?
Как нормализуются поля пользователя, поступающие от разных провайдеров?
Можно ли определить разную политику lockout для каждого провайдера?
Подключите любой источник идентичности к единому движку доступа
Запустите RADIUS, OAuth2, HTTP API и локальную базу пользователей в одном потоке условного доступа, MFA и аудита. Рассмотрим на живой установке в вашей собственной среде.