Расширения Web-сервисов для Microsoft .NET версии 2.0 включают ряд расширений по сравнению с более ранними версиями WSE, предназначенных для упрощения использования политики безопасности, установления продолжительных безопасных сеансов обмена сообщениями. Некоторые из этих расширений, такие как поддержка WSE 2.0 для вновь утвержденной стандартной версии WS-Security под названием Oasis, означают, что WSE 2.0 не может обмениваться SOAP-сообщениями с WSE 1.0. Положительный момент в том, что в одних и тех же приложениях вы можете использовать и сборки WSE 2.0, и сборки WSE 1.0, таким образом, одно приложение сможет общаться как с WSE 1.0, так и с WSE 2.0 Web-сервисами. Обзор других возможностей и вопросов версий приведен ниже:

Этот раздел описывает новые и расширенные возможности, входящие в WSE 2.0.

Политика

Версия 2.0 WSE позволяет разработчикам использовать файлы конфигурации для определения требований на получение и отправку сообщений. Раньше приложение, получающее SOAP-сообщение, должно было включать код для проверки требований на получение сообщений, таких как было ли SOAP-сообщение подписано с помощью цифровой подписи или закодировано. Подобным образом, разработчик приложения, посылающего SOAP-сообщение, должен был знать требования получателя сообщения и добавлять соответствующий код в отправляющее приложение. Теперь эти требования, известные как утверждения политики, могут быть выражены в файле конфигурации. Когда утверждения политики конфигурированы, среда выполнения WSE проверяет поступающие и исходящие SOAP-сообщения на соответствие этим утверждениям политики; в случае несоответствия, среда выполнения WSE возвращает SOAP-ошибку. В WSE есть ряд предопределенных утверждений политики, например, требование того, чтобы тело SOAP-сообщения было подписано с помощью сертификата X.509. Кроме того, система политики может быть расширена и дополнена специальными утверждениями политики.

WS-Trust и маркеры безопасности

Поддержка WSE спецификаций WS-Trust и WS-SecureConversation обеспечивает возможность программно запрашивать маркер безопасности с помощью SOAP-сообщения, и этот маркер может использоваться для передачи ряда SOAP-сообщений между отправителем SOAP-сообщения и Web-сервисом. WSE позволяет вам создать службу по присваиванию маркеров безопасности или конфигурировать ту, которая выпускает маркеры безопасности. Если он конфигурирован на выпуск маркеров безопасности, отправитель SOAP-сообщения может использовать маркер для подписания и/или кодирования серий SOAP-сообщений, известных как сеанс обмена сообщениями, между отправителем SOAP-сообщения и Web-сервисом.

Маркеры доступа Kerberos

WSE поддерживает использование маркеров доступа, основанных на мандатах Kerberos. Мандаты Kerberos могут использоваться для создания цифровой подписи и кодирования SOAP-сообщений, а также санкционирования доступа к Web-сервису на основании маркера доступа Kerberos.

Ролевая система безопасности с использованием маркеров доступа

WSE поддерживает для SOAP-сообщений ролевой принцип авторизации через создание принципала из маркера доступа в SOAP-сообщении, подобного тому, который используется для создания цифровой подписи SOAP-сообщения. Поскольку в SOAP-сообщении может быть несколько маркеров доступа, WSE разрешает приложению конфигурировать то, какой маркер доступа использовать для аутентификации и авторизации. Когда этим маркером доступа являются имя пользователя и пароль или мандат Kerberos, содержимое маркера доступа используется для аутентификации учетной записи Windows. Если удостоверения аутентифицированы, создается принципал Windows и назначается свойству Principal маркера доступа, используемого для подписания SOAP-сообщения. С помощью свойства Principal код метода Web-сервиса может решить, является ли данная роль авторизованной для выполнения всего или только частей метода Web-сервиса. В качестве альтернативы, с помощью политики ролевая система безопасности может быть установлена декларативно.

Подписание с помощью цифровой подписи и кодирование маркеров доступа

Когда маркер доступа добавляется в SOAP-сообщение, он добавляется в форме элемента XML в SOAP-заголовке WS-Security. Этот XML-элемент теперь может быть закодирован или подписан с помощью цифровой подписи. Это может быть очень полезным, когда маркером доступа является UsernameToken, который создается на базе имени пользователя и пароля, особенно если пароль посылается как открытый текст. А когда вы используете ролевую систему безопасности с UsernameToken, пароль должен передаваться как открытый текст. Следовательно, кодирование UsernameToken, содержащего пароль в виде открытого текста, может усложнить посреднику задачу по похищению пароля пользователя.

Обмен SOAP-сообщениями

Обменом SOAP-сообщениями WSE поддерживает гибкий и легковесный механизм для отправки и получения SOAP-сообщений. Этот механизм позволяет приложениям относительно просто переключаться между транспортными протоколами TCP и HTTP. Когда используется транспортный протокол TCP, SOAP-сообщения могут отправляться и получаться без использования Web-сервера. Web-сервер, который обрабатывает только HTTP-запросы, работает согласно требования спецификации HTTP о том, что каждый HTTP-запрос получает HTTP-ответ. Эта модель запрос/ответ при отправке сообщений не всегда нужна; отправителю SOAP-сообщения может понадобиться отправить несколько сообщений и, возможно, он не нуждается или не ожидает каких-либо ответных SOAP-сообщений. Механизм обмена SOAP-сообщениями в WSE использует этот тип обмена сообщениями и к тому же предоставляет возможность разработчикам использовать преимущества других возможностей WSE, например, поддержку цифровой подписи и кодирования.

Пример кода на Visual Basic .NET

QuickStarts и пример кода по всей документации предоставлен как на Visual Basic, так и на C#.

Поддержка маркеров доступа XML

Теперь WSE 2.0 предоставляет поддержку для маркеров доступа XML, таких как маркеры доступа XrML и SAML. Чтобы использовать маркеры доступа XML, вы должны создать и конфигурировать специальный маркер доступа XML.

Расширения Web-сервисов делают попытку сохранять степень обратной совместимости между версиями. Однако с внесением изменений в WSE, которые помогают улучшить безопасность, корректность или функциональность, возникает требование переписать части кода при переходе на самые последние версии WSE.

Далее следует список областей, в которых имеются нарушающие совместимость отличия между WSE 1.0 и WSE 2.0.

SOAP-сообщения WSE 1.0 и 2.0 не могут взаимодействовать

Сообщения, отправленные между приложениями, работающими под WSE 1.0 и 2.0, генерируют SOAP-ошибку. Эта ошибка возникает потому, что WSE 1.0 и 2.0 реализовывают разные спецификации архитектуры Web-сервисов. В частности, WSE 1.0 реализовывает спецификации WS-Routing и WS-Security, в то время как WSE 2.0 реализовывает WS-Addressing и OASIS WS-Security.

Одновременное выполнение нескольких версий WSE

На одной машине одновременно может быть установлено и выполняться несколько версий WSE. Однако Web-сервис, выполняющийся на этой машине, может использовать только одну из версий. Один клиент Web-сервиса может взаимодействовать с Web-сервисами, выполняющими WSE 1.0, и с Web-сервисами, выполняющими WSE 2.0. однако клиент должен использовать в коде полные имена, чтобы указать, какая версия WSE используется. Например, клиент мог бы и не определять SoapContext, но должен будет указать или Microsoft.Web.Services.SoapContext, или Microsoft.Web.Services2.SoapContext.

Получение SoapContext из Web-сервиса

Чтобы получить SoapContext из Web-сервиса в WSE 2.0, используйте статическое (Shared в Visual Basic) свойство Current класса RequestSoapContext или ResponseSoapContext для SOAP-запроса или SOAP-ответа, соответственно. Для WSE 1.0 статические (Shared) методы RequestSoapContext и ResponseSoapContext класса HttpSoapContext используются для получения SoapContext из Web-сервиса.

Интерфейс IPasswordProvider больше не нужен

Вам больше не надо создавать класс, реализовывающий интерфейс IPasswordProvider, и конфигурировать этот класс, если учетная запись пользователя Windows используется с UsernameToken. Теперь WSE для UsernameToken поддерживает аутентификацию Windows. Когда учетные записи Windows отправляются в UsernameToken, не надо создавать и конфигурировать класс. Однако когда учетная запись пользователя Windows не используется с UsernameToken, должен быть создан и конфигурирован класс, производный от SecurityTokenManager.

Класс DecryptionKeyProvider больше не нужен

Кодирование с общими секретами (также известное как симметричное кодирование) теперь осуществляется с помощью маркера доступа, созданного на основании симметричного ключа, и не просто на одном симметричном ключе. Маркеры безопасности, которые создаются сервисами маркеров доступа, основываются на симметричном ключе, который может использоваться для кодирования SOAP-сообщений.

Использование специальных двоичных маркеров доступа в WSE 2.0

Чтобы использовать в WSE 2.0, специальные двоичные маркеры доступа, созданные с помощью WSE 1.0, необходимо модифицировать.