escaper_,

К сожалению, мы в подобной же ситуации вынуждены были просто использовать другой способ аутентификации на сервисе. Но там был наш сервис и нам не сложно было включить basic-аутентификацию...

Я так понимаю, в вашем случае это не сработает?

Тогда из запасных вариантов мы рассматривали еще такой:
Разработать на .Net 3.0 (кстати, не исключено, что хватило бы и 2.0, WSE уже с версии 2.0 поддерживает все, что надо) маленькую библиотеку, которая будет всего лишь работать с нашим сервисом. Саму библиотеку реализовать в виде COM-библиотеки и уже использовать из унаследованного кода.
Основным недостатком было требование наличия .Net.

К сожалению, время тогда поджимало, и ничего особо искать мы не стали. Но при беглом осмотре мне не удалось найти ни одной приличной native библиотеки с поддержкой полного стека WS-* спецификаций, ни для Delphi, ни в виде COM. Встречались C++, но там активно использовались шаблоны т.е. бинарной совместимости не было и в помине (да и нет до сих пор уверенности, что именно они позволяли делать).

escaper_Не сработает, сервис не нашей разработки. Пока в качестве временного решения просто отключили аутентификацию на сервере (чтобы реализовать функционал). Но это не выход.

Я не знаю всей вашей специфики, но возможно (в некоторых случаях это даже оправдано), можно попробовать использовать Proxy-сервис.
Т.е. вы разрабатываете сервис, который выполняет ровно 2 вещи: аутентификацию ваших пользователей, и прокидывание вызова до нужного вам сервиса. А тот сервис полностью доверяет вашему proxy-сервису (т.е. там либо аутентификация от фиксированной записи, либо просто с определенного адреса разрешен анонимный вход, ...).

Однако этот вариант возможен лишь при условии, что:
1. Сервис находится во внутренней сети (чтобы можно было доверять proxy).
2. Сервис не делит права по пользователям.

Потенциально предложенный мною вариант можно развить до "proxy авторизует по одному протоколу, затем из некоторого защищенного хранилища достает credential для указанного пользователя и уже прокидывает дальше запрос с этими параметрами".
Подход в целом не такой уж и редкий - большинство реализаций SSO так и сделано (и если у вас уже есть некоторое SSO-решение, можно использовать его базу). Но сами понимаете, что у вас появляется дополнительная головная боль и все заради обращения к одному сервису...

Могу еще добавить, что в WCF 4.0 появляется специальный тип сервиса Routing Service, который потенциально предназначен для подобных задач (т.е. перенаправлять запросы не зная их схемы и семантики). Не знаю, можно ли там решить конкретно вашу задачу, но посмотрите на всякий случай здесь

escaper_,

Спасибо, что нашли время и рассказали о результатах (если честно, спустя 2 годя я даже не ожидал - приятно!).
По правде говоря, я уже больше года не работаю в компании, в которой вставала подобная проблема - а в нынешней, использование Delphi практически отсутствует (хотя компания аутсорсер).

escaper_,

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

Alex Sне подтверждается )
Увы, как показывает данный топик - проблемы есть.
Причем в первую голову, не хватает инструментов для создания многозвенных распределенных систем. А это - основа крупного корпоративного ПО сегодня.