Возможность

Федерация идентичности SAML 2.0

Соответствующее стандартам SAML 2.0 подключение к корпоративным IdP и государственным федерациям идентичности.

Многие организации уже используют SAML 2.0 identity provider, такой как AD FS, Entra ID, Okta, Ping, Auth0 или государственную федерацию идентичности. TR7 AAM работает перед приложениями как SAML 2.0 service provider и подключается к существующей корпоративной инфраструктуре идентичности, вместо того чтобы создавать новую базу пользователей. Пользователь перенаправляется к настроенному IdP; аутентификация и, при наличии, проверки MFA завершаются в собственном IdP организации. Затем подписанный SAML response возвращается AAM. AAM проверяет подпись этого response, его целевое приложение, срок действия и условия безопасности; извлекает идентичность пользователя и создаёт собственную сессию доступа. Эта сессия затем работает совместно со слоями AAM, такими как условный доступ, доверие устройства, дополнительная MFA, маршрутизация SSO и Backend SSO. Один шлюз AAM может маршрутизировать разные приложения или разные тенанты к отдельным IdP. Результат: пользователь входит один раз с корпоративной идентичностью; AAM проверяет идентичность соответствующим стандартам образом, ставит её под аудит и безопасно передаёт backend-приложениям.

SAML 2.0

Service provider, соответствующий стандартам: подписанный AuthnRequest, проверенный SAML response, контроль audience и действительности.

2 binding'а

HTTP-Redirect для AuthnRequest, HTTP-POST для ACS.

IdP по тенанту

Множество тенантов на одном шлюзе, отдельный identity provider для каждого тенанта.

SAML по-прежнему один из главных стандартов корпоративной идентичности — но его легко реализовать неправильно

Хотя OIDC всё чаще используется в современных приложениях, SAML 2.0 по-прежнему является критически важным стандартом в корпоративных и государственных интеграциях идентичности. Многие организации запускают свои существующие каталоги за AD FS, Entra ID, Okta, Ping, Auth0 или шлюзом федерации через SAML. На государственной стороне национальные федерации идентичности и связанные с ними SaaS-сервисы тоже чаще всего построены на SAML 2.0.

Поэтому правильный подход для нового или модернизируемого приложения — не создавать отдельную базу пользователей. Приложение должно подключаться к identity provider, которому организация уже доверяет. Для этого слой доступа должен вести себя как SAML 2.0 service provider: перенаправлять пользователя к правильному IdP, проверять входящий SAML response, безопасно извлекать идентичность и преобразовывать её в сессию, которую приложение может использовать.

Однако SAML-интеграция — это не просто работа «возьми XML, прочитай пользователя, открой сессию». При неправильной реализации она порождает серьёзные уязвимости безопасности. Подпись в SAML response должна правильно проверяться, нужно контролировать, какое именно поле действительно подписано, и предотвращать атаки вроде снятия подписи или добавления поддельного assertion. Срок действия, ограничение audience, информация об issuer, формат NameID и сопоставления атрибутов должны не просто читаться; они должны строго применяться.

Операционная сторона столь же важна. Обновление metadata IdP, ротация сертификатов и ключей подписи, маршрутизация к разным IdP по тенанту, разные правила сопоставления для разных приложений и потоки Single Logout — это не мелкие детали, добавляемые позже. Это базовые части того, что заставляет SAML-федерацию работать безопасно и устойчиво.

Одна из самых распространённых ошибок — встраивать отдельную SAML-библиотеку в каждое приложение. Этот подход распределяет ответственность за идентичность по каждому backend. Одно изменение IdP требует отдельного обновления в множестве приложений. MFA, условный доступ, доверие устройства, поведение при выходе и записи аудита пытаются решать заново для каждого приложения. Результат — не централизованная идентичность, а распределённый хаос идентичности.

Правильное место — край доступа. SAML должен завершаться в одной точке; управляться на том же слое, что и аутентификация, MFA, условный доступ, доверие устройства и Backend SSO. Тогда приложения не несут сложность протокола федерации; они получают только проверенную, чистую и доверенную идентичность.

Правильно управлять SAML — это не просто подключиться к IdP. Это проверять доверие к идентичности организации в одной точке, проводить аудит и безопасно передавать его приложениям.

Наш подход

Один шлюз AAM правильно завершает SAML на краю; остальная часть движка доступа надстраивается над этим.

Соответствующий стандартам SAML 2.0 service provider

Подписанный AuthnRequest на выходе, полная проверка assertion на входе — подпись, audience, окно действия, AudienceRestriction, формат NameID. Поддерживаются оба binding'а: HTTP-Redirect и HTTP-POST. Обработка подписи следует существующим правилам соответствия SAML 2.0 для отражения известных SAML-атак.

Маршрутизация IdP по приложению и тенанту

Один шлюз AAM может одновременно маршрутизировать разные приложения к разным IdP и разные тенанты одного приложения к разным IdP. Выбор IdP делается для каждого запроса из контекста приложения — никакого отдельного шлюза на каждый IdP, никакого ручного селектора страницы входа для пользователя.

Сопоставление NameID и атрибутов — с идентичностью сессии AAM

Правила сопоставления на каждый IdP преобразуют NameID и заявления атрибутов SAML-assertion в канонические поля, используемые остальной частью AAM — имя пользователя, email, группы, отображаемое имя, пользовательские атрибуты. То же сопоставление питает gating MFA, выражения условного доступа, журналы аудита и инъекции Backend SSO.

Согласовано с MFA, условным доступом, доверием устройства и Backend SSO

SAML-аутентификация не работает сама по себе — она компонуется с edge MFA (если IdP не применил step-up), выражениями условного доступа, непрерывной оценкой доверия и инъекцией Backend SSO в backend. SAML-assertion становится входом в сессию AAM; не всей сессией.

Возможности

Соответствующий стандартам SAML 2.0 SP плюс операционные функции, делающие федерацию безопасной и управляемой в масштабе.

SP-initiated SSO с подписанным AuthnRequest

Пользователь приходит в приложение, AAM перенаправляет его к настроенному IdP с подписанным SAML AuthnRequest, пользователь входит в IdP, и IdP возвращает подписанный assertion на эндпоинт Assertion Consumer Service AAM. Поддерживаются оба binding'а: HTTP-Redirect для исходящего запроса и HTTP-POST для входящего assertion.

IdP-initiated SSO с учётом RelayState

Для развёртываний, где отправной точкой пользователя является IdP — портал-стартовая площадка в IdP, каталог приложений, государственный портал идентичности — принимается IdP-initiated SSO. RelayState несёт целевой пункт назначения приложения; так пользователь оказывается на правильной странице после получения assertion.

Полная проверка assertion — подпись, audience, действительность, ограничение

Подпись assertion проверяется по настроенному сертификату подписи IdP; audience совпадает с настроенным идентификатором SP AAM; NotBefore и NotOnOrAfter определяют окно действия; применяется AudienceRestriction. Известные SAML-атаки (signature wrapping, signature stripping, дрейф NotBefore) явно отражаются, а не тихо терпятся.

Опциональное шифрование assertion с обработкой приватного ключа

Когда IdP шифрует assertion (xmlenc), AAM расшифровывает assertion настроенным приватным ключом SP до проверки. Шифрованные assertion'ы распространены для государственной федерации идентичности и для IdP, не желающих, чтобы содержимое assertion было читаемым на слое binding. Ключи шифрования хранятся зашифрованными в хранилище конфигурации и никогда не логируются.

Выбор формата NameID и сопоставление атрибутов на каждый IdP

Каждый IdP может быть настроен с предпочтительным форматом NameID (persistent, transient, email-address, unspecified) и сопоставлением имён атрибутов SAML с полями сессии AAM. Разные IdP могут представлять идентичность по-разному — национальный идентификатор, email, уникальный непрозрачный идентификатор — и всё равно создавать один и тот же канонический формат сессии AAM.

Привязка IdP по тенанту для мультитенантных развёртываний

Один шлюз AAM, держащий впереди множество тенантов, может маршрутизировать каждый тенант к собственному IdP. Выбор делается в момент запроса из контекста приложения или тенанта — никакого отдельного шлюза на каждый IdP, никакого селектора на каждого пользователя. Один и тот же шлюз может одновременно нести государственную федерацию идентичности для одного тенанта и частный корпоративный IdP для другого.

Single Logout (SLO), согласованный с очисткой сессии AAM

Когда IdP инициирует выход, AAM принимает SAML LogoutRequest, завершает сессию AAM и сигнализирует backend'ам, получающим инъекцию Backend SSO. Когда приложение инициирует выход, AAM отправляет подписанный LogoutRequest в сторону IdP и ждёт LogoutResponse, прежде чем объявить сессию завершённой. Front-channel SLO поддерживается.

Операционная глубина

Механика, которая держит SAML-федерацию безопасной, актуальной и наблюдаемой.

Обмен metadata IdP — загрузка, получение по URL или ручная конфигурация

Metadata IdP может быть загружена путём загрузки предоставленного IdP metadata XML, настройкой metadata URL, который AAM получает и кэширует, или ручным вводом эндпоинтов и сертификатов. Ручная конфигурация — реалистичный вариант для IdP, не публикующих metadata, соответствующую стандартам; там, где работают, два других метода предпочтительнее.

Публикация metadata SP для онбординга IdP

AAM публикует собственный документ metadata SP по стабильному URL; так оператор IdP может импортировать его в хранилище доверия IdP, вместо ручной передачи эндпоинтов и сертификатов. Metadata отражает живую конфигурацию SP — текущий ACS URL, текущий сертификат подписи, текущий эндпоинт SLO.

Ротация ключей подписи и сертификатов без простоя

Ключи подписи и сертификаты SP имеют ограниченный срок жизни. AAM поддерживает ротацию ключей с перекрытием — в течение окна rollover и старый, и новый ключ проверяются против кэшированной metadata IdP. Операторы планируют ротацию заранее; runtime принимает оба в течение периода перекрытия, и ротация вступает в силу чисто.

Допуск на расхождение часов с ограниченным окном дрейфа

Assertion'ы несут временные метки NotBefore и NotOnOrAfter. Реальные часы дрейфуют; AAM применяет настраиваемое окно допуска; так небольшой дрейф не отклоняет действительные assertion'ы, а большой дрейф (индикатор неверной конфигурации или повторного воспроизведения) всё равно отклоняется. Допуск задаётся на каждый IdP; хорошо синхронизированный IdP получает узкое окно, проблемный IdP — задокументированное послабление.

Аудит и корреляция с жизненным циклом сессии AAM

Каждое SAML-событие — исходящий AuthnRequest, входящий assertion, результат проверки подписи, SLO LogoutRequest, LogoutResponse — записывается с correlation ID, привязанным к сессии AAM, стоящим за ней backend(ам) и идентичности пользователя. Вопрос «кто, через какой IdP и когда вошёл в систему» отвечается одним запросом.

Какие команды используют

Государственная федерация идентичности

Приложения, которым нужно принимать IdP национальной федерации идентичности — типично для государственных развёртываний, регулируемых отраслей и SaaS-сервисов, контрактуемых для государственных заказчиков. AAM завершает SAML-федерацию на краю и представляет стоящему за ним приложению чистую, проверенную идентичность.

Корпоративные IdP (AD FS, Entra ID, Okta, Ping, Auth0)

Существующие корпоративные IdP, уже авторизующие рабочую силу. AAM подключается как SAML SP, не требуя от команды IdP что-либо менять. Новые приложения присоединяются к федерации, добавляя запись в AAM, а не новую SAML-библиотеку в каждую кодовую базу.

Мультитенантные развёртывания с IdP на каждый тенант

SaaS-приложения, где каждый клиент приносит свой собственный IdP. Один шлюз AAM держит все тенанты впереди; трафик каждого тенанта маршрутизируется к IdP этого тенанта. Добавить тенант — это не развёртывание, а добавление записи IdP в хранилище конфигурации.

Edge MFA и условный доступ поверх IdP, не применяющего MFA и условный доступ

Некоторые IdP аутентифицируют, но не применяют step-up MFA или условный доступ — особенно устаревшие шлюзы федерации. AAM принимает аутентификацию IdP, затем надстраивает над ней собственную MFA, выражения условного доступа и непрерывную оценку доверия перед предоставлением доступа к приложению.

Часто задаваемые вопросы

С какими IdP AAM федерируется?

С любым SAML 2.0 IdP, соответствующим стандартам. На практике сюда входят AD FS, Entra ID (Azure AD), Okta, Ping, Auth0, локальные каталоги за шлюзом федерации и IdP государственной федерации идентичности. Может предоставляться загрузкой metadata XML, получением с metadata URL или ручной конфигурацией.

Как AAM защищается от известных SAML-атак?

Подпись assertion проверяется по настроенному сертификату подписи IdP; signature wrapping, signature stripping и игры с namespace явно отражаются, а не тихо терпятся. NotBefore и NotOnOrAfter применяются с ограниченным допуском на расхождение часов. AudienceRestriction обязан называть настроенный SP AAM. Шифрованные assertion'ы расшифровываются приватным ключом SP только после прохождения проверок на уровне binding.

Может ли один шлюз AAM маршрутизировать разные тенанты или приложения к разным IdP?

Да. Выбор IdP делается для каждого запроса из контекста приложения или тенанта. Один и тот же шлюз может одновременно маршрутизировать один тенант к IdP государственной федерации идентичности, а другой — к частному корпоративному IdP; каждый тенант получает своё сопоставление NameID и атрибутов. Добавить тенант — это не развёртывание, а изменение конфигурации.

Поддерживает ли AAM Single Logout (SLO)?

Front-channel SLO поддерживается в обоих направлениях — IdP-initiated LogoutRequest завершает сессию AAM и сигнализирует backend'ам; application-initiated выход отправляет подписанный LogoutRequest в сторону IdP и ждёт LogoutResponse, прежде чем объявить сессию завершённой.

Что происходит с идентичностью после того, как AAM получает assertion?

NameID и настроенные атрибуты сопоставляются с каноническими полями сессии AAM (имя пользователя, email, группы, отображаемое имя, пользовательские атрибуты). Остальная часть движка доступа рассуждает над этой сессией — gating MFA, выражения условного доступа, непрерывная оценка доверия, инъекция Backend SSO в backend. Приложение получает идентичность через Backend SSO в ожидаемом им виде; протокол SAML останавливается на краю AAM.

SAML, сделанный правильно, на краю

Подключим AAM к вашему IdP — корпоративному или государственной федерации идентичности — и надстроим остальную часть движка доступа над assertion с MFA, условным доступом, доверием устройства и Backend SSO.