WS-Security с использованием файла ASMX в ASP.NET 3.5 - PullRequest
Новая
       28

WS-Security с использованием файла ASMX в ASP.NET 3.5

1 голос
/ 27 марта 2010

В основном мне нужно настроить файл ASMX, чтобы при его открытии в браузере для отображения спецификации WebMethod заголовок Soap соответствовал этому формату: 

<soap:Header>
   <wsse:Security>
      <wsse:UsernameToken wsu:Id='SecurityToken-securityToken'>
         <wsse:Username>Username</wsse:Username>
         <wsse:Password>Password</wsse:Password>
         <wsu:Created>Timestamp</wsu:Created>
      </wsse:UsernameToken>
   </wsse:Security>
</soap:Header>

Предыстория: я интегрируюсь с клиентским приложением, которое уже создано (и принадлежит другой компании). По сути, у этого клиентского приложения уже есть свои мыльные сообщения, созданные с прошлых интеграций с другими компаниями. Поэтому мы решили просто создать веб-сервис с использованием файла ASMX, который соответствует WSDL, который они уже настроили для использования.

Возможно ли заставить WS-Security работать с файлом ASMX или ASMX слишком упрощен, и мне нужно перейти на WFC (что я действительно не хочу делать)?

Ответы [ 3 ]

3 голосов
/ 27 марта 2010

Возможно ли заставить WS-Security работать с файлом ASMX или ASMX слишком упрощен, и мне нужно перейти на WFC (что я действительно не хочу делать)?

Да, это возможно при использовании Расширения веб-служб 3 (дополнение для Visual Studio 2005 и ASMX). См. Эту страницу MSDN для учебника по WSE-3 и используйте утверждение usernameOverTransportSecurity, отметив, что это , а не фактически безопасно, если соединение не происходит через защищенный транспорт (т.е. SSL).

Однако, не рекомендуется , чтобы вы делали это, и я не могу понять, почему вы не захотите "обновить до WCF", если у вас есть выбор. Обратите внимание на следующие очень важные ограничения ASMX / WSE:

  • WSE больше не поддерживается продуктом. Хотя он по-прежнему работает , он больше не получает обновлений или даже исправлений ошибок .

  • Ни одна версия WSE не будет успешно интегрирована в Visual Studio 2008 или даже Visual Studio 2005, работающую в Windows Vista x64 или более поздней версии.

  • WCF делает много хлопот, чтобы обеспечить потокобезопасные клиентские операции и позволяет прокси существовать в течение длительного периода времени (что, в свою очередь, обеспечивает значительные преимущества производительности для каждой операции). С другой стороны, WSE-прокси являются одноразовыми объектами, не поддерживающими потоки, которые требуют времени установки при каждом удаленном вызове метода (даже при использовании безопасного разговора). Это также делает их в значительной степени непригодными для внедрения зависимостей и многих других широко используемых шаблонов.

Это лишь некоторые из причин, по которым не следует больше использовать WSE. Причины, по которым следует использовать WCF на стороне клиента, разнообразны, включая, помимо прочего, разделение модели и прокси-серверов, использование служб на основе REST и лучшую обработку сбора. типы.

Если вы действительно не должны продолжать использовать ASMX, пожалуйста, пересмотрите ваш отказ перейти на WCF - если служба не делает много необычных вещей с сериализацией XML, потребуется не более 5 минут, чтобы переключатель.

2 голосов
/ 27 марта 2010

Нет, устаревшие веб-службы ASMX не поддерживают WS-Security или любые другие стандарты WS- *.

Поскольку Microsoft теперь считает веб-службы ASMX «устаревшей технологией», вам следует выполнять эту работу с использованием WCF.

Другой ответ предлагает использовать WSE. Это еще меньше решения. WSE совершенно устарел и должен использоваться только в качестве крайней меры.

1 голос
/ 27 марта 2010

Вы можете реализовать службу SOAP / WS-Security, используя классические веб-службы. Вот учебник от MSDN.

Все это проще в WCF.

EDIT:

вытащил не ту ссылку. Вот один , который я намеревался вставить (учебник по CodeProject, использующий WSE 2, хотя WSE 3 является последней версией, и я использовал эту версию исключительно перед WCF).

...