Привет

Сначала рассмотрим такую ситуацию:
IIS (web) <-> IE.
Можно сделать так, что по требованию сервера браузер пошлёт user's windows credentials и сервер сможет его имперсонифицировать.

Теперь меняем ситуацию. Имеем
IIS (web service) <-> Web Service Client on .NET.
Как добиться того же, т.е. как поиметь возможность имперсонифицировать клиента в этом случае?

Стандартными средствами HTTP, как же ещё.
С этой точки зрения никакой разницы между двумя приведёнными ситуациями нет.

yocto писал(а):Стандартными средствами HTTP, как же ещё.
С этой точки зрения никакой разницы между двумя приведёнными ситуациями нет.

А поподробней?

В первом случае я либо запрещаю anonymous access в IIS, либо возвращаю HTTP ишибку программно, вместе с запросом in HTTP header, и требую повторного запроса с пересылкой credentials. Но чтобы всё это работало, нужна поддержка со стороны IE, которая, хвала Аллаху, присутствует. В каком-нить неуставном браузере это работать не будет.

Во втором случае на сервере я, разумеется, могу сделать то же самое. Но вот как сконфигурить клиента, чтобы он не поперхнулся запросом с сервера, требуещим credentials? На клиенте всё должно быть сделано с минимальными усилиями - генерим proxy из WSDL файла, и пишем простенькую программу на C#. Никаких вручную-сформированных HTTP headers быть не должно. Может, это как-нить с помощью аттрибутов или установок в app.config можно сделать?

myService.Credentials = new NetworkCredentials(....) ??
or
myService.Credentials = CredentialCache.DefaultCredentials ??

Вы хотите, чтоб ваш kлиент без проблем работал и с анонимус и с интегратед аутхентицатион? У вас будет куча проблем.
Во-первых, WebService+IntegratedAuth=VeryPoorPerformance.
WebService clients unlike browsers don't reuse the authenticated connection for subsequent requests. Each request will authenticate against the domain controller.
(this was acked by MS and hopefully will be fixed in the next service pack)

Second, if the server was set up for anonymous access when you generated your proxy, but later it's been reconfigured to use integrated auth, your proxy will never send credentials and will simply timeout until you do "update web reference".

Посмотрите здесь: Securing XML Web Services Created Using ASP.NET.

Vovka писал(а):А поподробней?

Без проблем.

Общие соображения.
Серверная часть общается с клиентом при помощи протокола HTTP (предположим). Если вы хотите осушествлять authentication только лишь стандартными средствами этого протокола, то для сервера будет неважен тип клиента. В пределе, этого даже нельзя будет определить.
NTLM authentication не является стандартом для не-Windows части вселенной. Если такое ограничение вас не волнует - всё ОК.

Понятно, что ответственность за предоставление authentication data лежит на клиенте, если это - browser, то он сделает это за вас, если это - custom client, возможна ситуация, что реализовать обмен данными придётся вручную.
Если за каждой попыткой обращения к Web-service будет стоять живой человек, которого можно будет попросить ввести имя и пароль для указанного домена (хотя бы раз) - ситуация упрощается. Если же нет - хуже. Вам придётся где-то хранить имя и пароль реального пользователя, а это чревато.

Я бы посоветовал не пользоваться authenication вообще для Web-service. Если же это очень надо, то использовать для этого client certificates. Особенно в тех случаях, когда речь идёт об automated clients.

yocto писал(а):Серверная часть общается с клиентом при помощи протокола HTTP (предположим).

На это можно положиться, HTTP и SOAP поверх него.

yocto писал(а):Если вы хотите осушествлять authentication только лишь стандартными средствами этого протокола, то для сервера будет неважен тип клиента. В пределе, этого даже нельзя будет определить.
NTLM authentication не является стандартом для не-Windows части вселенной. Если такое ограничение вас не волнует - всё ОК.

Это для меня вообще не ограничение.
Более того, Windows Me всякие там я тоже не поддерживаю, так что NTLM должна быть, на это тоже можно положиться.

yocto писал(а):Понятно, что ответственность за предоставление authentication data лежит на клиенте, если это - browser, то он сделает это за вас, если это - custom client, возможна ситуация, что реализовать обмен данными придётся вручную.

Очень бы не хотелось, чтобы вручную клиенту что-нить приходилось бы делать. Кстати, я даже не знаю, а как Web Service client может вручную писать HTTP-заголовки запроса?

Вообще, задача очень практическая, очень конкретная. Под клиентам понимаю программу на C#, которая создаётся следующим образом:
1. Генерится прокси из WSDLя.
2. Программа создаёт объект прокси и вызывает его метод, как обычный класс. Ничего другого я от клиента требовать не могу. На клиенте допустимо использование только декларативных (аттрибуты) или административных (какие-нить настройки безопасности) средств, никакого специального программирования.

На всякие там стандарты, совместимости и переносимости мне наплевать. Надо, чтобы работал выше описанный сценарий.

Кстати пытаюсь прикрутить тут .Net клиента к JAX-RPC (Tomcat)
никак не выходит каменный цветок Притом с тем же WSDL
J2EE -SOAP- J2EE фунциклирует, J2EE -SOAP - .Net Remoting (IIS)
фунциклирует, даже .Net Remoting - SOAP - .Net Remoting (IIS)
фунциклирует ! Все время получаю ошибку
connection closed. Кто нибудь скрещивал успешно этого ужа с ежом ?

Vovka писал(а):Очень бы не хотелось, чтобы вручную клиенту что-нить приходилось бы делать. Кстати, я даже не знаю, а как Web Service client может вручную писать HTTP-заголовки запроса?

А писать заголовки и не надо. Надо ими управлять. Про способы управления тут уже до меня сказали.

Vovka писал(а):Вообще, задача очень практическая, очень конкретная. Под клиентам понимаю программу на C#, которая создаётся следующим образом:

Понятно. Я под клиентом имел в виду не способ создания кода, а тот процесс, который этот код будет исполнять на удалённом компьютере.
Если это interactive user, тогда можно (теоретически) заставить всё это работать, используя NetwoкkCredentials и NTLM. Если же это некий автономный процесс, то можно заставить его выступать от имени реального пользователя. Проблемы есть и тут, и там.
Одна из проблем (для меня лично - самая важная) - придётся где-то хранить имя пользователя и его пароль в recoverable виде. Если это не волнует, то те ссылки, которые тут дали, всё объяснят.

Есть и другой способ.
Можно вынести authentication за рамки сетевого траспорта и делать это в вызываемом сервисе. Это не совсем красиво по некоторым причинам, но если красота не важна, то использовать можно. Это избавит от проблем, специфичных для HTTP и IIS, поскольку с их точки зрения все запросы будут anonymous, однако проблема с хранением credentials останется.
Вариант с client certificates многие проблемы решает, но также создаёт массу новых.

JustMax писал(а):Кстати пытаюсь прикрутить тут .Net клиента к JAX-RPC (Tomcat)
никак не выходит каменный цветок Притом с тем же WSDL
J2EE -SOAP- J2EE фунциклирует, J2EE -SOAP - .Net Remoting (IIS)
фунциклирует, даже .Net Remoting - SOAP - .Net Remoting (IIS)
фунциклирует ! Все время получаю ошибку
connection closed. Кто нибудь скрещивал успешно этого ужа с ежом ?

Сто лет назад игрался с .NET - вызывал JAX-RPC (сановской имплементации) крутившийся на Weblogic, фунциклировало с полпинка. Может случай был очень простой

Bobo писал(а):myService.Credentials = new NetworkCredentials(....) ??
or
myService.Credentials = CredentialCache.DefaultCredentials ??

Bobo, спасибо - как раз то, что мне нужно. Вчера вечером как-то и не заметил - точнее, не понял просто.

Bobo писал(а): Вы хотите, чтоб ваш kлиент без проблем работал и с анонимус и с интегратед аутхентицатион? У вас будет куча проблем.
Во-первых, WebService+IntegratedAuth=VeryPoorPerformance.

Пока-что это надо для одной отдельно взятой ф-ции, а не повсеместно.

Bobo писал(а): Second, if the server was set up for anonymous access when you generated your proxy, but later it's been reconfigured to use integrated auth, your proxy will never send credentials and will simply timeout until you do "update web reference".

Я не конфирурированием сервера это делаю - там anonymous разрешён - а программно запрашиваю credentials, потому что они нужны только для одной ф-ции.

Vovka писал(а):Сначала рассмотрим такую ситуацию:
IIS (web) <-> IE.
Можно сделать так, что по требованию сервера браузер пошлёт user's windows credentials и сервер сможет его имперсонифицировать.

Теперь меняем ситуацию. Имеем
IIS (web service) <-> Web Service Client on .NET.
Как добиться того же, т.е. как поиметь возможность имперсонифицировать клиента в этом случае?

WSE - SOAP Envelops и SecurityTokens, если я правильно понял вопрос.