Метод аутентификации службы WCF

В данный момент я создаю службу WCF SOAP. Мне, конечно, потребуется некоторая аутентификация на сервисе.

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

Было бы хорошо, если бы я мог гарантировать, что пользователи будут взаимодействовать со службой через клиента на основе метаданных, предоставляемых WCF (по сути, что-то вроде клиента, написанного на C# со ссылкой на веб-службу). Однако я не могу этого гарантировать!

Мне по-прежнему нужно разрешить пользователям общаться только с необработанным (незашифрованным) XML.

Итак, вопросы:

  1. Позволяет ли привязка wsHttp вводить необработанный XML?
  2. If not, would I be wiser to
    • Implement two separate authetication points? One for raw XML input and one for encrypted input Or
    • Разрешить вводу из wsHttp возвращаться к некоторой проверке в методе, которая будет использоваться совместно с необработанным вводом XML?
  3. Разумно ли разрешать пользователям передавать свои учетные данные в необработанном XML-запросе?

РЕДАКТИРОВАТЬ: Похоже, я что-то недопонял или неправильно понял в своем исходном сообщении, поэтому здесь я поясню, что я имею в виду под «необработанным XML».

Под необработанным XML я подразумеваю только пакет SOAP и сопутствующие заголовки HTTP, которые я мог бы отправить из soapUI или Fiddler. Насколько я понимаю, сообщения по привязке wsHttp шифруются при генерации клиента из WSDL (например, на C#).

Если это не так, то как мне прикрепить такие же учетные данные к необработанному XML-запросу (из-за отсутствия лучшего термина), как я делаю запрос, выполняемый через клиента? Прикреплены ли они как заголовки HTTP? Элементы XML в конверте SOAP?


authentication wcf endpoints
person Andy Hunt    schedule 28.07.2011    source источник

Ответы (1)


arrow_upward
0
arrow_downward

wsHttp — это привязка SOAP, что означает, что ваш контент помещается в конверт SOAP, возможно, с заголовками, относящимися к сообщению, и различными используемыми спецификациями WS-*.

Я хотел бы спросить, почему вам нужно поддерживать необработанный XML? Сегодня большинство платформ поддерживают обмен сообщениями SOAP, и вся идея SOAP заключается в обеспечении взаимодействия между различными платформами. На большинстве платформ разработать SOAP-клиент так же просто, как и необработанный XML-клиент. В большинстве случаев достаточно просто взять WSDL и создать клиент. Если вы хотите использовать стандартные средства, такие как аутентификация и шифрование сообщений, то это гораздо лучший способ.

В настоящее время нет ловушек для функциональной проверки подлинности для необработанного XML. Для этого вам придется придумать свой механизм, и он будет нестандартным. Для пользователей вашего веб-сервиса это означает, что это, вероятно, повлечет за собой больше усилий по разработке, чем если бы вы просто использовали SOAP.

person Phil Degenhardt    schedule 29.07.2011
comment
Спасибо. Похоже, я что-то недопонял или неправильно понял. Я отредактирую свой исходный пост, чтобы попытаться уточнить - person Andy Hunt; 29.07.2011