Использование WCF для использования сервиса и получение различных ошибок в зависимости от конфигурации привязки - PullRequest
0 голосов
/ 16 декабря 2009

Я пытаюсь использовать веб-службу интрасети с WCF. Я добавил ссылку на службу через функцию Добавить ссылку на службу в VS2008. При этом у меня запросили сетевые учетные данные для доступа к предоставленной мной услуге, и была добавлена ​​ссылка на службу.

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

FooServiceClient proxy = new FooServiceClient();
bool isValid = proxy.ValidateBar(baz);

Когда я использую этот код, я получаю исключение:
HTTP-запрос не авторизован с помощью схемы аутентификации клиента 'Negotiate'.
Заголовок аутентификации, полученный от сервера, был 'Basic realm = "Kerberos" '.

Какую же ошибку я получаю при использовании любого из двух приведенных ниже примеров кода.

FooServiceClient proxy = new FooServiceClient();
proxy.ClientCredentials.UserName.UserName = "USERNAME";
proxy.ClientCredentials.UserName.Password = "PASSWORD";
bool isValid = proxy.ValidateBar(baz);

или

FooServiceClient proxy = new FooServiceClient();

NetworkCredential creds = new NetworkCredential("USERNAME", "PASSWORD");

proxy.ClientCredentials.Windows.AllowedImpersonationLevel =
  TokenImpersonationLevel.Identification;
proxy.ClientCredentials.Windows.AllowNtlm = false;
proxy.ClientCredentials.Windows.ClientCredential = creds;

bool isValid = proxy.ValidateBar(baz);

Моя интуиция говорит мне, что у меня неправильно настроен режим безопасности. По словам менеджера сервера, конечная точка, к которой я пытаюсь привязаться, - это поиск базовых учетных данных Http через SSL. Что после прочтения о WCF-BasicHttp Transport Properties привело меня к мысли, что я должен использовать эту конфигурацию:

<security mode="Transport">
  <transport clientCredentialType="Windows" />
  <message clientCredentialType="UserName" algorithmSuite="Default" />
</security>

К сожалению, я продолжал получать ту же ошибку.

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

Ответы [ 3 ]

2 голосов
/ 16 декабря 2009

Вы должны действительно понимать, на что настроена конечная точка на другом конце. Если он размещен самостоятельно и работает по протоколу SSL, то он должен быть Transport , но если он работает под IIS с SSL, то это может быть TransportWithMessageCredentials , а учетные данные транспорта могут быть «Нет». .

Очень сложно заставить это связываться правильно.

Насколько вы получаете исключение

Предоставленная схема URI «https» недействительным; ожидаемый http параметр Имя:

Когда вы используете TransportCredentialOnly , вы должны использовать HTTP-привязку, а не HTTPS, и я уверен, что вы не изменили адрес своей конечной точки на HTTP, потому что это не то, что является ссылкой на службу.

1 голос
/ 16 декабря 2009

Какую привязку вы используете для сценария интрасети? Рекомендуется использовать NetTCP с транспортной безопасностью и учетными данными Windows (при условии, что все ваши абоненты являются клиентами интрасети с учетной записью в корпоративном Active Directory)

Это позволит избежать любого беспорядка http / https.

Однако для размещения netTcp вам либо нужен WAS (сервер активации Windows), который является частью IIS7 и работает только на Windows Server 2008 (Vista Server) или 2008 R2 (Win7 Server). Или вам нужно разместить свой сервис самостоятельно, например, NT Service.

Много информации по-прежнему отсутствует! Пожалуйста, обновите ваш вопрос соответственно. Спасибо!

0 голосов
/ 22 декабря 2009

Приведенная ниже конфигурация связывания WCF оказалась решением.

<security mode="Transport">
  <transport clientCredentialType="Basic" proxyCredentialType="None"
     realm="" />
  <message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
...