Чтобы успешно интегрироваться с нетривиальным Web-сервисом, необходимо полностью понимать его XML-контракт, а также любые дополнительные требования, возможности и привилегии (также называемые политики). Например, для осуществления успешной интеграции просто знания того, что сервис поддерживает WS-Security, не достаточно. Клиенту нужно знать, действительно ли сервис требует WS-Security. Если да, тогда также необходимо знать, какие маркеры доступа могут обрабатываться (например, Маркер имя пользователя (UsernameToken), мандаты Kerberos или сертификаты) и какие из них предпочтительнее. Клиент также должен определить, требует ли сервис подписанных сообщений. Если да, он должен установить, какой тип маркера должен использоваться для цифровых подписей. И наконец, клиент должен определить, когда кодировать сообщения, какой алгоритм использовать для этого и как обмениваться с сервисом общим ключом. Пытаться интегрироваться с сервисом без понимания этих деталей все равно, что стрелять в темноту. И без стандартного способа передачи политик, разработчикам остается только передавать их как обычно — из уст в уста и через документацию.

Стандартная инфраструктура политики даст возможность разработчикам выражать политики сервисов машинно-считываемым способом. Инфраструктура Web-сервисов могла бы быть усовершенствована для понимания определенных политик и применения их во время выполнения. Например, разработчик может написать политику, утверждающую, что данный сервис требует маркеры Kerberos, цифровые подписи и кодирование. Другие разработчики могли бы использовать информацию политики, чтобы сделать выводы о возможности использования этого сервиса. Кроме того, инфраструктура может реализовать эти требования при том, что разработчику не придется написать ни строчки кода. Итак, инфраструктура политики предоставит не только дополнительный уровень описания, она также предложит разработчикам более декларативную модель программирования.

Компании Microsoft, IBM, BEA и SAP недавно выпустили спецификацию Инфраструктура политик Web-сервисов (Web Services Policy Framework - WS-Policy) (http://msdn.microsoft.com/ws/2002/12/Policy/), чтобы удовлетворить потребность в универсальной инфраструктуре политик. WS-Policy определяет универсальную модель и синтаксис для описания и реализации взаимодействия политик Web-сервиса. В этой статье сделан обзор WS-Policy и других смежных спецификаций.

Для описания большого разнообразия политик Web-сервисов WS-Policy (http://msdn.microsoft.com/ws/2002/12/Policy/) определяет универсальную инфраструктуру, которая может использоваться и расширяться другими спецификациями Web-сервисов. WS-Policy дает определение политики как набора одного или более утверждений политики (policy assertions) (см. Рис.1).

Рис. 1. Обзор политики

Утверждение политики (policy assertion) представляет отдельные предпочтение, требование, возможность или другую общую характеристику. Существует еще две дополнительные спецификации, определяющие стандартные наборы утверждений политики, которые могут использоваться в выражении политики. Спецификация Язык утверждений политик Web-сервисов (http://msdn.microsoft.com/ws/2002/12/PolicyAssertions/) (Web Services Policy Assertions Language - WS-PolicyAssertions) определяет набор общих утверждений сообщений, и спецификация Язык политик безопасности Web-сервисов (http://msdn.microsoft.com/ws/2002/12/ws-security-policy/) (Web Services Security Policy Language - WS-SecurityPolicy) определяет ряд обычных утверждений, касающихся обеспечения безопасности.

WS-Policy обеспечивает гибкую и расширяемую грамматику для выражения политик в понятном для машин XML-формате. Представление политики в XML называется выражением политики (policy expression). Выражение политики связано с субъектом политики (policy subject) или, иначе говоря, с описываемыми им ресурсами (например, конечная точка Web-сервиса). Механизм ассоциирования выражения политики с одним или более субъектами политики называется назначением политики (policy attachment).

Спецификация WS-Policy определяет общую модель и синтаксис выражений политики и утверждений политики, но лишь коротко останавливается на том, как располагаются или назначаются политики Web-сервиса. Авторы WS-Policy собираются посвятить различным вариантам решения этого вопроса другие спецификации. Спецификация Назначение политики Web-сервисов (http://msdn.microsoft.com/ws/2002/12/PolicyAttachment/) (Web Services Policy Attachment - WS-PolicyAttachment) — одна из таких спецификация, которая определяет, как прикрепить выражения политики к XML-элементам, WSDL-описаниям и UDDI-записям.

Таблица 1. Терминология политики

Далее эта статья углубляется в эти различные концепции и показывает, как они поддерживаются сегодня в Расширениях Web-сервисов для Microsoft .NET версии 2.0 (WSE 2.0). В Таблице 1 кратко представлена терминология политики, используемая нами в этой статье.

Выражение политики является XML-представлением политики. Использование XML для представления политик обеспечивает возможность взаимодействия гетерогенных платформ и инфраструктуры Web-сервисов. WS-Policy предоставляет нормативное описание XML Schema, которая выражает структуру выражения политики. Схема WS-Policy (http://schemas.xmlsoap.org/ws/2002/12/policy) определяет все конструкции, которые могут использоваться в выражении политики, и также включает описания для WS-PolicyAssertions и WS-PolicyAttachment.

Схема WS-Policy также основывается на универсальной Схеме использования Web-сервисов (http://schemas.xmlsoap.org/ws/2002/07/utility/) (Web services utility schema), включающей различные конструкции, которые могут использоваться в различных спецификациях Web-сервисов (например, wsu:Id). Существует также схема для WS-SecurityPolicy (http://schemas.xmlsoap.org/ws/2002/12/secext), которая описывает структуру утверждений системы безопасности (security assertions), а WSE 2.0 определяет некоторые дополнительные элементы, используемые только ее инфраструктурой. В Таблице 2 приведены все пространства имен схемы (и определенные для них префиксы), которые мы используем в этой статье.

Таблица 2. Пространства имен политики

Элемент wsp:Policy представляет выражение политики. Согласно этой схеме, базовая структура wsp:Policy следующая:

<wsp:Policy xmlns:wsp="..." xmlns:wsu="..."
    wsu:Id="..." Name="..." TargetNamespace="...">
    <!—- здесь находятся утверждения политики --> 
</wsp:Policy>

Элемент wsp:Policy выступает в роли контейнера для утверждений политики. Вы можете присвоить выражению политики ID, имя или и то, и другое. Атрибут wsu:Id присваивает выражению политики значение ID в форме URI. Полный ID политики формируется из базового URI выражения политики, за которым следуют # и значение wsu:Id (например, base#Id). В качестве примера рассмотрим следующее выражение политики:

<wsp:Policy xmlns:wsp="..." xmlns:wsu="..."
    wsu:Id="MyPolicies" >
    ...</wsp:Policy>

Принимая за базовый URI — http://skonnard.com/invoices/policy.xml, полный ID этой политики будет http://skonnard.com/invoices/policy.xml#MyPolicies. Вы используете полный ID, когда ссылаетесь на политику из других элементов через Id, как показано здесь:

...
<wsp:PolicyReference xmlns:wsp="..."
   URI="http://skonnard.com/invoices/policy.xml#MyPolicies"/>
...

Или в ситуациях, когда вы ссылаетесь на политику из того же документа (имеется ввиду, что у него тот же базовый URI), вы можете использовать просто #MyPolicies.

Также вы можете присвоить выражению политики имя, ограниченное пространством имен (namespace-qualified). Необязательные атрибуты Name и TargetNamespace вместе идентифицируют выражение политики как уникальное значение QName, где Name представляет локальное имя в определенном TargetNamespace. Например, рассмотрим следующее выражение политики:

<wsp:Policy xmlns:wsp="..." Name="MyPolicies" 
  TargetNamespace="http://skonnard.com/policies"
>...</wsp:Policy>

В этом случае имя политики — {http://skonnard.com/policies}MyPolicies. Чтобы сослаться на эту политику по имени, вам нужно описание пространства имен, которое позволяет вам обращаться к MyPolicies в пространстве имен http://skonnard.com/policies, как показано здесь:

...
<wsp:PolicyReference xmlns:wsp="..."
   xmlns:p="http://skonnard.com/policies" 
   Ref="p:MyPolicies"/>
...

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

Утверждение политики представляет отдельное предпочтение, способность или другую характеристику и является основным строительным блоком выражения политики. Утверждение политики представляется XML-элементом с хорошо известным именем и значением, обычно определенным другой спецификацией (как WS-PolicyAssertions и WS-SecurityPolicy).

Выражение политики просто содержит ряд элементов утверждений политики, как показано здесь:

<wsp:Policy xmlns:wsp="..." xmlns:wsu="..."
    wsu:Id="..." Name="..." TargetNamespace="..." >
    <Assertion wsp:Usage="..." wsp:Preference="..." /> 
    <Assertion wsp:Usage="..." wsp:Preference="..." /> 
    <Assertion wsp:Usage="..." wsp:Preference="..." /> 
    ...
</wsp:Policy>

Некоторые утверждения определяют требования и возможности, которые, в конечном счете, проявятся при передаче, такие как наличие цифровых подписей или кодирование. Эти утверждения требуют взаимодействия двух сторон. Другие утверждения не имеют проявлений при передаче, но обеспечивают дополнительную информацию для помощи в выборе сервиса (например, поддержка политик, качество политик сервиса, и т.д.). Эти утверждения не оказывают влияния на сообщение — они просто выступают в роли соглашения между двумя сторонами.

WS-Policy предоставляет спецификатор применения (usage qualifier), чтобы помочь распознавать различные типы утверждений и то, как они должны обрабатываться. Вы используете атрибут wsp:Usage, чтобы показать применение утверждения. Возможные значения wsp:Usage включают Обязательный (Required), Необязательный (Optional), Непригодный (Rejected), Рассматриваемый (Observed) и Проигнорированный (Ignored) (смотрите Таблицу 3). Каждый элемент утверждения политики должен иметь значение wsp:Usage — оно может быть объявлено или в самом элементе утверждения, или может быть унаследовано от элемента-предка, как вы вскоре увидите.

Таблица 3. Значения wsp:Usage

Спецификаторы wsp:Required, wsp:Rejected и wsp:Optional свидетельствуют о том, что утверждение обязательное, не поддерживается и необязательное, соответственно. Спецификатор wsp:Observed определяет, что утверждение было принято обеими сторонами и будет рассмотрено, даже в случает отсутствия такового. Спецификатор wsp:Ignored определяет, что утверждение политики полностью игнорируется.

Например, рассмотрим следующее выражение политики, которое содержит два утверждения политики, определенные спецификацией WS-SecurityPolicy:

<wsp:Policy xmlns:wsp="..." xmlns:wsse="...">
  <wsse:SecurityToken wsp:Usage="wsp:Required">
    <wsse:TokenType>wsse:Kerberosv5ST</wsse:TokenType>
  </wsse:SecurityToken>
  <wsse:Integrity wsp:Usage="wsp:Required">
    <wsse:Algorithm Type="wsse:AlgSignature"
        URI="http://www.w3.org/2000/09/xmlenc#aes" />
  </wsse:Integrity>
</wsp:Policy>

Выражение политики объявляет, что субъект требует маркер мандата сервиса Kerberos V5 и цифровую XML-подпись. Следующее выражение политики, с другой стороны, объявляет, что субъект не поддерживает ни один из типов маркеров доступа Kerberos, указывая на то, что Kerberos не должен использоваться для аутентификации:

<wsp:Policy xmlns:wsp="..." xmlns:wsse="...">
  <wsse:SecurityToken wsp:Usage="wsp:Rejected">
    <wsse:TokenType>wsse:Kerberosv5ST</wsse:TokenType>
  </wsse:SecurityToken>
  <wsse:SecurityToken wsp:Usage="wsp:Rejected">
    <wsse:TokenType>wsse:Kerberosv5TGT</wsse:TokenType>
  </wsse:SecurityToken>
</wsp:Policy>

Следующее выражение политики объявляет, что субъект поддерживает как сертификаты x509, так и UsernameTokens, но они оба необязательны:

<wsp:Policy xmlns:wsp="..." xmlns:wsse="...">
  <wsse:SecurityToken wsp:Usage="wsp:Optional">
    <wsse:TokenType>wsse:UsernameToken</wsse:TokenType>
  </wsse:SecurityToken>
  <wsse:SecurityToken wsp:Usage="wsp:Optional">
    <wsse:TokenType>wsse:x509v3</wsse:TokenType>
  </wsse:SecurityToken>
</wsp:Policy>

В ситуациях, когда существует множество вариантов выбора для данной возможности, атрибут wsp:Preference может использоваться для определения предпочтений сервиса как целое значение, в котором большее число означает большее предпочтение. Отсутствие этого атрибута равнозначно нулевому предпочтению. Например, следующее выражение политики показывает, что для данного субъекта предпочтительнее использование сертификатов x509, а не UsernameTokens:

<wsp:Policy xmlns:wsp="..." xmlns:wsse="...">
  <wsse:SecurityToken wsp:Usage="wsp:Optional">
    <wsse:TokenType>wsse:UsernameToken</wsse:TokenType>
  </wsse:SecurityToken>
  <wsse:SecurityToken wsp:Usage="wsp:Optional" wsp:Preference="1">
    <wsse:TokenType>wsse:x509v3</wsse:TokenType>
  </wsse:SecurityToken>
</wsp:Policy>

Вы можете определить собственные утверждения политики, но чтобы они были полезны, все стороны должны понимать, что они означают. Поэтому имеет смысл определять стандартные наборы утверждений политики, которые понятны всем Web-сервисам. Это именно то, что определяют для нас спецификации WS-PolicyAssertions и WS-SecurityPolicy.

Спецификация WS-PolicyAssertions определяет четыре основных утверждения политики, которые могут применяться к любому субъекту. Этими утверждениями являются wsp:TextEncoding, wsp:Language, wsp:SpecVersion и wsp:MessagePredicate (смотрите Таблицу 4). Как обсуждалось в предыдущем разделе, применение оказывает влияние на то, что на самом деле означает это утверждение.

Таблица 4. Основные утверждения политики, определенные WS-PolicyAssertions

Например, следующее выражение политики показывает, что субъекту требуется 1) кодировка UTF-8, 2) любая форма английского языка (например, en-us, en-gb и т.д.) и 3) SOAP, версия 1.1:

<wsp:Policy xmlns:wsse="...">
   <wsp:TextEncoding wsp:Usage="wsp:Required" Encoding="utf-8"/>
   <wsp:Language wsp:Usage="wsp:Required" Language="en"/>
   <wsp:SpecVersion wsp:Usage="wsp:Required" 
       URI="http://www.w3.org/TR/2000/NOTE-SOAP-20000508/" />
   ...
</wsp:Policy>

Утверждение wsp:MessagePredicate отличается тем, что оно позволяет вам использовать произвольные ограничения сообщений, определенные диалектом выражения. Стандартный диалект выражения — XPath 1.0. WS-PolicyAssertions также определяет ряд функций расширения XPath, которые могут использоваться в этих выражениях (например, wsp:GetBody, wsp:GetHeader и т.д.). Например, следующая политика требует, чтобы в элементе soap:Body существовал именно один элемент заголовка wsse:Security и именно один дочерний элемент:

<wsp:Policy xmlns:wsp="..." xmlns:wsse="...">
  <wsp:MessagePredicate wsp:Usage="wsp:Required">
    count(wsp:GetHeader(.)/wsse:Security) = 1
  </wsp:MessagePredicate>
  <wsp:MessagePredicate wsp:Usage="wsp:Required">
    count(wsp:GetBody(.)/*) = 1
  </wsp:MessagePredicate>
  ...
</wsp:Policy>

WS-PolicyAssertions также определяет другой диалект для идентификации простого списка частей сообщения. Этот диалект называется http://schemas.xmlsoap.org/2002/12/wsse#part и поступает с двумя функциями поддержки, wsp:Body и wsp:Header. Например, следующее выражение политики гарантирует, что сообщение содержит элемент вместе soap:Body с элементами заголовка wsse:Security и x:MyHeader:

<wsp:Policy xmlns:wsp="..." xmlns:wsse="...">
  <wsp:MessagePredicate wsp:Usage="wsp:Required"
    Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part"
  >
    wsp:Body() wsp:Header(wsse:Security) wsp:Header(x:MyHeader)
  </wsp:MessagePredicate>
  ...
</wsp:Policy>

Кроме этих универсальных утверждений сообщения, спецификация WS-SecurityPolicy определяет набор утверждений политики, касающихся обеспечения безопасности (смотрите Таблицу 5). Эти утверждения позволяют вам определять типы маркеров доступа, форматы подписей и поддерживаемые алгоритмы кодирования, обязательные или отвергаемые данным субъектом. Выше я приводил несколько примеров этих утверждений политики. Для получения более подробной информации смотрите Спецификацию WS-SecurityPolicy (http://msdn.microsoft.com/ws/2002/12/ws-security-policy/).

Таблица 5. Утверждения политики безопасности, описанные WS-SecurityPolicy

WS-Policy определяет набор операторов политики (policy operators), которые могут использоваться для комбинирования многих утверждений различными способами (смотрите Таблицу 6). Все из ранее показанных примеров выражений политики предполагали, что все утверждения политики должны быть удовлетворены, что является стандартным поведением и эквивалентно окружению утверждений политики оператором wsp:All.

Таблица 6. Операторы политики

Вы можете окружить группу утверждений оператором wsp:OneOrMore, если хотите, чтобы было выполнено, по крайней мере, одно из утверждений. Или вы можете окружить группу утверждений оператором wsp:ExactlyOne, если хотите, чтобы выполнялось именно одно утверждение, как показано здесь:

<wsp:Policy xmlns:wsp="..." xmlns:wsse="...">
  <wsp:ExactlyOne wsp:Usage="Required">
     <wsse:SecurityToken>
       <wsse:TokenType>wsse:UsernameToken</wsse:TokenType>
     </wsse:SecurityToken>
     <wsse:SecurityToken wsp:Preference="10">
       <wsse:TokenType>wsse:x509v3</wsse:TokenType>
     </wsse:SecurityToken>
     <wsse:SecurityToken wsp:Preference="1">
       <wsse:TokenType>wsse:Kerberosv5ST</wsse:TokenType>
     </wsse:SecurityToken>
  </wsp:ExactlyOne>
</wsp:Policy>

Это означает, что субъекту требуется именно один маркер доступа: или UsernameToken, или Kerberos, или x509. Значения предпочтения показывают, что предпочтительным типом маркера является x509, за ним следует Kerberos, а далее идет UsernameToken.

Как показано выше, вы также можете комментировать операторы политики атрибутом wsp:Usage, чтобы контролировать использование помещенных в нем утверждений (если только они явно не переопределены самим утверждением). Также вы можете вкладывать операторы друг в друга, чтобы создавать гибкие комбинации, как показано здесь:

<wsp:Policy xmlns:wsp="..." xmlns:wsse="...">
  <wsp:All wsp:Usage="Required">
   <wsp:ExactlyOne>
     <wsse:SecurityToken>
       <wsse:TokenType>wsse:UsernameToken</wsse:TokenType>
     </wsse:SecurityToken>
     <wsse:SecurityToken wsp:Preference="10">
       <wsse:TokenType>wsse:x509v3</wsse:TokenType>
     </wsse:SecurityToken>
     <wsse:SecurityToken wsp:Preference="1">
       <wsse:TokenType>wsse:Kerberosv5ST</wsse:TokenType>
     </wsse:SecurityToken>
   </wsp:ExactlyOne>
    <wsp:All>
     <wsse:Integrity>
      <wsse:Algorithm Type="wsse:AlgSignature"
        URI="http://www.w3.org/2000/09/xmlenc#aes" />
     </wsse:Integrity>
     <wsp:TextEncoding Encoding="utf-8"/>
     <wsp:SpecVersion 
        URI="http://www.w3.org/TR/2000/NOTE-SOAP-20000508/" />
    </wsp:All>
</wsp:Policy>

Это выражение политики показывает, что субъект требует маркеры доступа UsernameToken, x509 или Kerberos, и что сообщения должны иметь следующие характеристики: 1) кодировка UTF-8, 2) SOAP 1.1 и 3) цифровую подпись.

WS-Policy предоставляет механизм совместного использования утверждений политики различными выражениями политики через элемент wsp:PolicyReference. Элемент wsp:PolicyReference ссылается на другое выражение политики, и может использоваться везде, куда бы вы обычно хотели поместить элемент утверждения. Содержимое используемого выражения политики мысленно заменяет элемент wsp:PolicyReference и «заворачивается» в оператор wsp:All. Следующий пример иллюстрирует синтаксис wsp:PolicyReference:

<wsp:Policy xmlns:wsp="...">
  ...
  <wsp:PolicyReference URI="..." 
                       Ref="..." 
                       Digest="..." 
                       DigestAlgorithm="..." />
  ...
</wsp:Policy>

Вы можете ссылаться на политику по ID или QName, используя атрибуты URI или Ref, соответственно (более детально о присваивании имен политикам и их использовании смотрите в разделе Выражения политики). Хотя каждый из атрибутов — необязательный, вы должны определить хотя бы один из них. вы также можете определить (но это необязательно) base64 значение Digest (вместе с DigestAlgorithm), чтобы гарантировать, что вы получили ожидаемую, неподделанную политику. Следующий пример иллюстрирует то, как распределять политику (с помощью ID маркеров) между двумя другими политиками:

<wsp:Policy wsu:Id="tokens" xmlns:wsp="..." xmlns:wsse="...">
  <wsp:ExactlyOne wsp:Usage="Required">
     <wsse:SecurityToken>
       <wsse:TokenType>wsse:UsernameToken</wsse:TokenType>
     </wsse:SecurityToken>
     <wsse:SecurityToken wsp:Preference="10">
       <wsse:TokenType>wsse:x509v3</wsse:TokenType>
     </wsse:SecurityToken>
     <wsse:SecurityToken wsp:Preference="1">
       <wsse:TokenType>wsse:Kerberosv5ST</wsse:TokenType>
     </wsse:SecurityToken>
  </wsp:ExactlyOne>
</wsp:Policy>

<wsp:Policy wsu:Id="tokensWithSignature" 
   xmlns:wsp="..." xmlns:wsse="...">
  <wsp:PolicyReference URI="#tokens" />
  <wsse:Integrity wsp:Usage="wsp:Required">
    ...
  </wsse:Integrity> 
</wsp:Policy>

<wsp:Policy wsu:Id="tokensWithEncryption" 
   xmlns:wsp="..." xmlns:wsse="...">
  <wsp:PolicyReference URI="#tokens" />
  <wsse:Confidentiality wsp:Usage="Required">
    ...
  </wsse:Confidentiality>
</wsp:Policy>

Теперь, когда мы рассмотрели основы создания выражений и утверждений политики, нам надо коротко обсудить то, как ассоциировать выражения политики в субъектами.

Спецификация WS-PolicyAttachment определяет несколько механизмов ассоциирования выражений политики с субъектами. В частности, она определяет, как ссылаться на выражения политики из XML-элементов, WSDL-описаний и UDDI-сущностей. Она завершает это описанием пары глобальных атрибутов, wsp:PolicyURIs и wsp:PolicyRefs, которые могут использоваться, чтобы ссылаться на выражения политики из любого XML-элемента.

Атрибут wsp:PolicyURIs должен содержать список URI, разделенных пробелами, политики, в то время как атрибут wsp:PolicyRefs должен содержать список разделенных пробелами QNames политики. Следующий пример показывает, как ассоциировать пару политик с произвольным элементом:

<SomeElement xmlns:wsp="..."
  wsp:PolicyURIs="http://skonnard.com/policies#tokensWithSignature
     http://skonnard.com/policies#tokensWithEncryption" />

Спецификация также обозначает, как использовать эти атрибуты в WSDL-описаниях, особенно то, что касается сообщения, portType и связывающих структурных компонентов. Наряду с интеграцией с WSDL, спецификация определяет то, как ассоциировать выражения политики и UDDI-сущностями через широко известные описания tModel. Кроме этих техник, WS-PolicyAttachment также определяет элемент wsp:PolicyAttachment для связывания конечной точки Web-сервиса с выражением политики, без необходимости внесения каких-либо изменений в определения Web-сервиса. Следующий элемент иллюстрирует работу этого элемента:

<wsp:PolicyAttachment>
  <wsp:AppliesTo>
    <wsa:EndpointReference xmlns:s="...">
      <wsa:Address>http://skonnard.com/someendpoint</wsa:Address>
      <wsa:PortType>s:SomePortType</wsa:PortType>
      <wsa:ServiceName>s:SomeService</wsa:ServiceName>
    </wsa:EndpointReference>
  </wsp:AppliesTo>
  <wsp:PolicyReference URI="http://skonnard.com/policy.xml" />
  <wsse:Security>
     <ds:Signature> ... 
     </ds:Signature> 
  </wsse:Security>
</wsp:PolicyAttachment>

Хотя WS-PolicyAttachment охватывает наиболее общие ситуации назначения, другие спецификации вольны определять собственные дополнительные механизмы.

Различные касающиеся политик спецификации (WS-Policy, WS-PolicyAttachment, WS-PolicyAssertions и WS-SecurityPolicy) определяют стандартную инфраструктуру, которая дает возможность разработчикам выражать разнообразные требования, возможности и предпочтения способным к взаимодействию, понятным для машин способом. Политики позволяют разработчикам и приложениям размышлять по поводу сервисов и выбирать их более осмысленно. Используя политики, инфраструктура также может предоставлять автоматическую поддержку стандартных утверждений.

Расширения Web-сервисов для Microsoft .NET версия 2.0 (Web Services Enhancements for Microsoft .NET version 2.0 - WSE 2.0) предоставляют основную поддержку дл инфраструктуры политики, как было описано в этой статье, и нескольких утверждений WS-SecurityPolicy, включая wsp:SecurityToken, wsp:Integrity, wsp:Confidentiality и wsp:MessageAge. Кроме поддержки этих стандартных утверждений, инфраструктура политики WSE 2.0 позволяет вам определять и поддерживать специальные утверждения путем реализации обработчика утверждения политики. WSE 2.0 в настоящее время не поддерживает WS-PolicyAttachment, но предоставляет собственный механизм назначения через специальный уровень преобразования.