WS-Federation

WS-Federation — это протокол федеративного управления идентификацией, разработанный консорциумом OASIS (Organization for the Advancement of Structured Information Standards) в рамках семейства спецификаций Web Services (WS-*). Он предназначен для организации единого входа (Single Sign-On, SSO) между различными доменами безопасности, позволяя делегировать аутентификацию и авторизацию между поставщиками удостоверений (Identity Provider, IdP) и поставщиками услуг (Service Provider, SP). Протокол определяет механизмы обмена токенами безопасности (security tokens) и метаданными о доверии, обеспечивая возможность работы в гетерогенных средах, включая Microsoft Active Directory Federation Services (AD FS), где он является ключевым компонентом.

История и развитие

Протокол WS-Federation был впервые опубликован в 2003 году компаниями IBM, Microsoft, VeriSign и RSA Security как часть набора стандартов WS-*. Его создание было ответом на потребность в стандартизированном способе федеративного доступа к веб-ресурсам и сервисам, где аутентификация пользователя выполняется в одном домене (например, корпоративной сети), а доступ к ресурсу предоставляется в другом (например, облачном сервисе). В 2006 году спецификация была передана в OASIS, где в 2007 году был принят стандарт WS-Federation 1.1. Позднее, в 2009 году, вышла версия 1.2, которая уточнила форматы токенов и механизмы пассивного (на основе HTTP-редиректов) и активного (на основе SOAP-сообщений) профилей.

Протокол получил широкое распространение в корпоративных средах, особенно в экосистеме Microsoft. Однако с появлением более простых и веб-ориентированных протоколов, таких как OAuth 2.0 и OpenID Connect, его использование постепенно сокращается. Тем не менее, WS-Federation остаётся востребованным в унаследованных (legacy) системах и в сценариях, где требуется поддержка сложных политик безопасности, например, в государственных и финансовых учреждениях.

Архитектура и принцип работы

WS-Federation основан на модели треугольника доверия (trust triangle), включающей три стороны:

• Пользователь (User) — субъект, запрашивающий доступ к ресурсу.
• Поставщик услуг (Service Provider, SP) — сторона, предоставляющая защищённый ресурс (веб-приложение, API).
• Поставщик удостоверений (Identity Provider, IdP) — сторона, аутентифицирующая пользователя и выпускающая токен безопасности.

Процесс аутентификации в пассивном профиле (наиболее распространённом) выглядит следующим образом:

1. Пользователь пытается получить доступ к защищённому ресурсу на SP.
2. SP перенаправляет пользователя на IdP с запросом аутентификации (через HTTP 302 Redirect).
3. IdP аутентифицирует пользователя (например, по имени и паролю, сертификату или смарт-карте).
4. После успешной аутентификации IdP создаёт токен безопасности (обычно в формате SAML 2.0 или SAML 1.1) и перенаправляет пользователя обратно на SP вместе с этим токеном.
5. SP проверяет токен (подпись, срок действия, аудиторию) и предоставляет пользователю доступ.

В активном профиле взаимодействие происходит напрямую между клиентским приложением (например, WCF-клиентом) и IdP через SOAP-сообщения, без участия веб-браузера.

Ключевые компоненты

Токены безопасности

WS-Federation поддерживает несколько форматов токенов, но наиболее распространённым является SAML (Security Assertion Markup Language) — язык разметки утверждений безопасности. Токен содержит утверждения (assertions) об атрибутах пользователя (имя, роль, адрес электронной почты) и условиях его использования (время действия, целевой сервис). Также могут использоваться токены Kerberos, X.509 и собственные форматы.

Метаданные федерации

Для установления доверия между IdP и SP используются метаданные федерации (Federation Metadata) — XML-документы, описывающие конечные точки, сертификаты и поддерживаемые типы токенов. Эти метаданные обычно публикуются на URL-адресах и автоматически импортируются системами.

Пассивный и активный профили

• Пассивный профиль (Passive Requestor Profile): предназначен для веб-браузеров и использует HTTP-редиректы. Пользователь не участвует в обмене токенами напрямую.
• Активный профиль (Active Requestor Profile): предназначен для приложений, которые могут напрямую взаимодействовать с IdP через SOAP. Клиент сам получает токен и передаёт его SP.

Применение

WS-Federation активно используется в следующих сценариях:

• Корпоративная федерация: объединение учётных записей между различными подразделениями или компаниями. Например, сотрудник компании A может получить доступ к ресурсам компании B без создания отдельной учётной записи.
• Облачная интеграция: использование корпоративного IdP (например, AD FS) для аутентификации в облачных сервисах (Microsoft 365, Azure, Salesforce). В этом случае WS-Federation выступает в роли протокола для обмена токенами между локальным IdP и облачным SP.
• Государственные информационные системы: в ряде стран, включая Россию, WS-Federation применялся в системах межведомственного электронного взаимодействия (СМЭВ) для аутентификации должностных лиц. Однако в последние годы происходит переход на более современные протоколы.
• Унаследованные системы: многие старые приложения, написанные на платформе .NET, используют WS-Federation для интеграции с AD FS.

Критика и ограничения

Несмотря на свою функциональность, WS-Federation имеет ряд недостатков:

• Сложность реализации: протокол требует глубокого понимания XML, SOAP и криптографии. Настройка метаданных и политик доверия может быть трудоёмкой.
• Низкая производительность: использование тяжёлых XML-токенов и SOAP-сообщений увеличивает задержки по сравнению с JSON-форматами.
• Проблемы с мобильными и SPA-приложениями: пассивный профиль плохо адаптирован для одностраничных приложений (SPA) и мобильных клиентов, где требуется работа с JavaScript и локальным хранилищем.
• Вытеснение более простыми протоколами: OAuth 2.0 и OpenID Connect предлагают аналогичные возможности, но с меньшей сложностью и лучшей поддержкой в современных веб- и мобильных средах. Microsoft, ранее активно продвигавшая WS-Federation, в последних версиях Azure AD рекомендует использовать OpenID Connect.

Сравнение с другими протоколами

Интересные факты

• WS-Federation является одним из немногих стандартов, который поддерживает как пассивный, так и активный профили в рамках одной спецификации.
• Протокол лёг в основу механизма федерации в Microsoft Active Directory Federation Services (AD FS), который до сих пор используется в корпоративных средах.
• В России WS-Federation применялся в ранних версиях системы «Электронный бюджет» и в некоторых региональных порталах государственных услуг, но впоследствии был заменён на SAML 2.0.

Источники

1. OASIS Standard: Web Services Federation Language (WS-Federation) Version 1.2, 2009.
2. Microsoft Docs: Active Directory Federation Services (AD FS) Overview.
3. IBM DeveloperWorks: Understanding WS-Federation.
4. RFC 7519: JSON Web Token (JWT).
5. OASIS Standard: Security Assertion Markup Language (SAML) V2.0.