АссистентНовый вопросИсторияОбласти знаний
Партнёрские проектыСпецпроектыСтать автором
Сменить язык
О РУВИКИ

WS-SecurityPolicy

WS-SecurityPolicy — спецификация в области веб-служб, разработанная компанией IBM совместно с 12 соавторами. Версия 1.2 стала стандартом организации OASIS в 2007 году, а в 2009 году была опубликована версия 1.3. Спецификация расширяет базовые протоколы безопасности, определённые в WS-Security, WS-Trust и WS-Secure Conversation, предоставляя механизмы для представления возможностей и требований веб-служб в виде политик. Утверждения политики безопасности основаны на каркасе WS-Policy.

Утверждения политики могут использоваться для задания как общих атрибутов безопасности, например, защиты транспортного уровня (<TransportBinding>), защиты на уровне сообщений (<AsymmetricBinding>) или временных меток, так и специфических атрибутов, например, типов токенов.

Большинство утверждений политики классифицируются по следующим категориям:

  • Утверждения о защите — указывают элементы сообщения, которые должны быть подписаны, зашифрованы или присутствовать.
  • Утверждения о токенах — определяют допустимые форматы токенов (SAML, X.509, имя пользователя и др.).
  • Утверждения о привязке безопасности — контролируют основные меры безопасности, такие как защита транспортного уровня и уровня сообщений, наборы криптографических алгоритмов, требуемые временные метки.
  • Утверждения о поддерживающих токенах — добавляют функции, такие как вход пользователя с использованием токена имени пользователя.

Политики могут использоваться как для автоматической генерации исходного кода с заданными функциями средствами разработки, так и для согласования параметров безопасности при работе веб-служб в режиме реального времени. Политики могут быть привязаны к элементам WSDL, таким как сервис, порт, операция или сообщение, как определено в стандарте WS Policy Attachment. В современной архитектуре стандарт сохраняет актуальность для корпоративных SOAP-сервисов и обеспечения сквозной безопасности на уровне сообщений, в то время как в публичных API доминируют архитектура REST и стандарты OAuth 2.0, OIDC и JWT[1].

Основные концепции

Механизмы работы стандарта WS-SecurityPolicy основаны на использовании специальных XML-элементов — утверждений (assertions), которые описывают конкретные правила защиты веб-служб. Ключевыми элементами являются утверждения безопасности (Security Assertions) и утверждения о компоновке (Layout Assertions)[2]. Утверждения безопасности определяют требования к защите сообщений и делятся на следующие основные категории:

  • Утверждения о привязке безопасности (Security Binding Assertions) — определяют основной механизм защиты. Включают такие типы, как TransportBinding (защита на уровне транспортного протокола), SymmetricBinding (использование симметричных ключей) и AsymmetricBinding (использование асимметричной криптографии)[2][3].
  • Утверждения о защите (Protection Assertions) — указывают, какие части сообщения подлежат защите (например, SignedParts для цифровой подписи и EncryptedParts для шифрования)[4].
  • Утверждения о токенах (Token Assertions) — задают форматы токенов для аутентификации и авторизации (например, UsernameToken, X509Token, SamlToken)[2][5].
  • Утверждения о поддерживающих токенах (Supporting Token Assertions) — определяют дополнительные токены, необходимые для поддержки основного механизма безопасности[2][6].

Утверждения о компоновке (Layout Assertions) гарантируют корректное добавление токенов в заголовок безопасности и определяют правила порядка следования элементов. К основным правилам относятся Strict (строгий порядок по принципу «объявление перед использованием») и Lax (свободный порядок, допускающий добавление элементов в любой последовательности, не противоречащей спецификации)[7].

Взаимодействие со смежными стандартами

Спецификация WS-SecurityPolicy тесно взаимодействует с другими стандартами стека WS-*, выступая в роли базового элемента для построения комплексных решений безопасности веб-служб. Сама по себе она не предоставляет полного решения, а используется совместно с такими протоколами, как WS-Trust и WS-SecureConversation[2].

Взаимодействие с протоколом WS-Trust строится на разделении ролей: WS-SecurityPolicy определяет требования к безопасности, а WS-Trust предоставляет механизм их выполнения. В политике безопасности с помощью специальных утверждений (например, IssuedToken) указывается необходимость предоставления определённого типа маркера безопасности, выпущенного доверенной службой (STS — Security Token Service). Обнаружив такое требование, клиент использует протокол WS-Trust для обращения к STS, проходит аутентификацию и получает требуемый маркер. Этот маркер затем включается в заголовок SOAP-сообщения при обращении к целевой веб-службе, тем самым выполняя заявленные в политике требования[8].

Для повышения эффективности обмена серией сообщений между клиентом и службой применяется стандарт WS-SecureConversation, позволяющий установить общий контекст безопасности с сеансовыми ключами вместо ресурсоёмкого асимметричного шифрования каждого отдельного сообщения. В этом случае WS-SecurityPolicy декларирует необходимость использования защищённого сеанса (например, через утверждение SecureConversationToken). В свою очередь, протокол WS-SecureConversation определяет процесс установления этого контекста и получения соответствующего маркера (SCT). После первоначального согласования последующие сообщения защищаются с использованием симметричных сеансовых ключей, что значительно снижает вычислительную нагрузку[9].

Примеры политик

Пространства имён, используемые в нижеприведённых фрагментах XML: 

<p:Policy 
   xmlns:p="http://www.w3.org/ns/ws-policy"
   xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802">
   ...
</p:Policy>

Добавление временной метки: 

<sp:IncludeTimestamp />

Использование либо защиты транспортного уровня (HTTPS), либо защиты на уровне сообщений (XML Dsig/XML Enc): 

<ExactlyOne>
  <sp:TransportBinding>...</sp:TransportBinding>
  <sp:AsymmetricBinding>...</sp:AsymmetricBinding >
</ExactlyOne>

Определение утверждения SAML как токена безопасности: 

<sp:IssuedToken>
  <sp:RequestSecurityTokenTemplate>
    <wst:TokenType>...#SAMLV2.0</wst:TokenType>
  </sp:RequestSecurityTokenTemplate>
</sp:IssuedToken>

Утверждение о выданном токене ссылается на STS и определяет необходимый формат токена: 

<sp:IssuedToken>
  <sp:Issuer>
    <wsa:EndpointReference>
      <wsa:Address>http://sampleorg.com/sts</wsa:Address>
     </wsa:EndpointReference>
  </sp:Issuer>
  <sp:RequestSecurityTokenTemplate>
    <wst:TokenType>
       http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID
    </wst:TokenType>
        ...
  </sp:RequestSecurityTokenTemplate>
  ...
</sp:IssuedToken>

Указание, что заголовок и тело сообщения должны быть подписаны, а вложения могут оставаться неподписанными:[2] 

<sp:SignedParts xmlns:sp="..." ... >
  <sp:Body />?
  <sp:Header Name="Dx:NCName"? Namespace="Xd:anyURI" ... />*
...
</sp:SignedParts>

Программные реализации и применение

Стандарт WS-SecurityPolicy имеет программные реализации в популярных Java-фреймворках для создания веб-служб. В фреймворке Apache CXF поддержка стандарта позволяет декларативно описывать требования безопасности непосредственно в WSDL-документе, автоматически настраивая компоненты библиотеки Apache WSS4J[10]. Веб-сервисный стек Metro, включающий эталонную реализацию JAX-WS, также использует политики из WSDL-файла для настройки безопасности, что дополнительно обеспечивает совместимость с платформой Microsoft .NET[11].

В экосистеме .NET уровень поддержки стандарта существенно различается в зависимости от версии платформы. Классический .NET Framework через технологию Windows Communication Foundation (WCF) предоставляет полноценную встроенную поддержку WS-SecurityPolicy, позволяя автоматически конфигурировать механизмы защиты[12]. В то же время в современных версиях платформы (.NET Core и выше) клиентские библиотеки WCF имеют ограниченную поддержку стандарта, и для реализации сложных сценариев безопасности разработчикам приходится прибегать к ручному формированию заголовков или использованию прокси-сервисов[13].

Практическое применение WS-SecurityPolicy активно продолжается в корпоративных системах, использующих протокол SOAP. При этом для новых проектов, основанных на архитектуре REST, стандарт не используется — в таких случаях применяются альтернативные технологии обеспечения безопасности, включая OAuth 2.0 и JSON Web Tokens (JWT)[1].

Другие языки политик WS

Термин «язык политик безопасности веб-служб» (Web Services Security Policy Language) используется в отношении двух различных основанных на XML языков:

  1. Как описано выше — на базе каркаса WS-Policy, определено в[14], опубликовано как версия 1.3 в феврале 2009 года.
  2. WSPL, основанный на профиле XACML для веб-служб, который не был финализирован[15].

Примечания

  1. ↑ 1 2 Сравнение SOAP и REST. Amazon Web Services. Дата обращения: 28 мая 2026.
  2. ↑ 1 2 3 4 5 6 WS-SecurityPolicy 1.3 Specification. OASIS. Дата обращения: 28 мая 2026.
  3. ↑ WS-SecurityPolicy Assymetric Binding Explained. Thilina Blog (19 августа 2009). Дата обращения: 28 мая 2026.
  4. ↑ Security Policy Assertions. Oracle Documentation. Дата обращения: 28 мая 2026.
  5. ↑ WS-SecurityPolicy. VBNet.ru. Дата обращения: 28 мая 2026.
  6. ↑ WS-Security Supporting Tokens. Akana Documentation. Дата обращения: 28 мая 2026.
  7. ↑ Layout Assertion. Oracle Documentation. Дата обращения: 28 мая 2026.
  8. ↑ WS-Trust: The Web Services Trust Language. XML.com (24 июня 2003). Дата обращения: 28 мая 2026.
  9. ↑ WS-SecureConversation. Apache CXF. Дата обращения: 28 мая 2026.
  10. ↑ WS-SecurityPolicy. Apache CXF. Дата обращения: 28 мая 2026.
  11. ↑ Metro Web Services Stack. javaee.github.io. Дата обращения: 28 мая 2026.
  12. ↑ WCF Security Implementation. C# Corner. Дата обращения: 28 мая 2026.
  13. ↑ How to Add WS-Security to .NET Core SOAP Headers Without WCF. landonhemsley.com. Дата обращения: 28 мая 2026.
  14. ↑ WS-SecurityPolicy (англ.). OASIS (февраль 2009). Дата обращения: 28 мая 2026.
  15. ↑ Web-services policy language use cases and requirements (draft) (англ.). OASIS. Дата обращения: 28 мая 2026.

Ссылки

Категории