Коллеги!

1. Вебсервисами пользовался. Опыт есть. Брал ставки ИПС с адреса http://www.cbr.ru/secinfo/secinfo.asmx. Но там не было никакой авторизации.
Т.е. с авторизацией в вебсервисах не работал!

2. Сейчас третья сторона срочно требует ответ по стратегии интеграции.
В частности, есть вопросы по авторизации:
<<Так же прошу учесть, что авторизацию я планирую делать по Active Directory.
Это удобно? Если нет, можно сделать простой логин и пароль.>>

3. Вопрос. Как вообще устроена авторизация в вебсервисах? Где-то читал, что вроде как на уровне вебсервисов это не решено.
Или надо авторизацию делать через HTTP, на который опирается вебсервис?

Заранее спасибо!

Не знаю про то ли это
.. тебе wsdl, ты подсовываешь delphi ее, генерируются все необходимые классы и типы... если про то, то у меня так авторизация (delphi 6 )
(судя по http в именах, через http и делается, похоже что)

function GetOrdersPortType(aUserName, aPassword: string; UseWSDL: Boolean; Addr: string; HTTPRIO: THTTPRIO): OrdersPortType;

// генерируется ide, что-то правил именно про логин/пароль, не помню что- в основном код уже такой автоматом
const

 defWSDL = 'C:\delphi_work\orders\скаченный wsdl.wsdl';
 defURL  = 'https://ссыль к ним/ws/orders';
 defSvc  = 'Orders';
 defPrt  = 'OrdersS';
var
 RIO: THTTPRIO;
begin
 Result := nil;
 if (Addr = '') then
 begin
   if UseWSDL then
     Addr := defWSDL
   else
     Addr := defURL;
 end;
 if HTTPRIO = nil then
   RIO := THTTPRIO.Create(nil)
 else
   RIO := HTTPRIO;

 RIO.HTTPWebNode.UserName := aUserName;
 RIO.HTTPWebNode.Password := aPassword;

 try
   Result := (RIO as OrdersPortType);
   if UseWSDL then
   begin
     RIO.WSDLLocation := Addr;
     RIO.Service := defSvc;
     RIO.Port := defPrt;
   end else
     RIO.URL := Addr;
 finally
   if (Result = nil) and (HTTPRIO = nil) then
     RIO.Free;
 end;
end;

> Тимохов Дима ©   (12.09.16 15:12) 

в принципе, Indy поддерживает и один и другой тип авторизации.

> ВладОшин ©   (12.09.16 16:29) [1]

Посмотрел.
HTTPWebNode - реализован поверх WinINe.
Т.е. я чего хочу сказать - что тут речь, про то, что авторизация идет не на уровне SOAP, а на более низком уровне HTTP. А на уровне SOAP как таковом авторизации нет? Верно?


> Eraser ©   (12.09.16 17:20) [2]
> > Тимохов Дима ©   (12.09.16 15:12) 
> в принципе, Indy поддерживает и один и другой тип авторизации.

Тут, понимаешь, вопрос даже немного теоретический.
Я правильно понимаю, что авторизация идет на уровне HTTP, а не на уровне SOAP как такового?

> Тимохов Дима ©   (12.09.16 17:43) [3]

насчет NTLM точно сказать не могу, возможно есть разные варианты реализации, но что касается basic и digest, то это именно в стандарте предусмотрено http://www.ietf.org/rfc/rfc2617.txt

> что авторизацию я планирую делать по Active Directory.
> Это удобно?
это невозможно. авторизация подразумевает логон в систему с логином-паролем, а Active Directory это просто "база" данных по учеткам, и т.д. не система, дополнение, в котором можно посмотреть данные любой учетки (если прав у текущей хватит), но не авторизоваться.

> Как вообще устроена авторизация в вебсервисах?
сервер в винде будет? ну так проверяй результат LogonUser (логин в винду, будет виндовая) на сервере типа: (юзер и домен раздельно, выделяются из прислаонного)
if not LogonUser(PChar(User(ARequestInfo.AuthUsername)), PChar(Domain(ARequestInfo.AuthUsername)), PChar(ARequestInfo.AuthPassword ), LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, um) then
begin
   AResponseInfo.AuthRealm   := 'Login';
   AResponseInfo.ResponseText:= 'test';
   Exit;
end;

> Тимохов Дима ©
на более низком уровне HTTP

видимо так

> с авторизацией в вебсервисах не работал


А в чем проблема ? Вот ты на этом сайте как-то авторизуешься, веб-сервис несильно отличается. Я со своей дилетантской колокольни полагаю, что ты перед началом использования функций, требующих авторизации, передаешь методу авторизации веб-сервиса credentials пользователя, она тебе возвращает некий его идентификатор (cookie), и ты этот идентификатор используешь в запросах к тем функциям, которые требуют авторизованного доступа.

> sniknik ©   (12.09.16 19:02) [5]


Ты не мог бы пояснить подробнее о чем речь тут?
Не могу врубиться в то, что сказал...


> > Как вообще устроена авторизация в вебсервисах?
> сервер в винде будет? ну так проверяй результат LogonUser
> (логин в винду, будет виндовая) на сервере типа: (юзер и
> домен раздельно, выделяются из прислаонного)



> Игорь Шевченко ©   (12.09.16 22:33) [7]


Да вроде как на уровне уже вызовов веб-сервиса никаких авторизационных действий нет - методы это просто методы с параметрами. А вот вся авторизация идет ниже. Пока я понял, что на уровне HTTP.

это невозможно.

это возможно. иногда.

цайт налабан на асп.нет
проверка подлинности включена доменная.
обработчик вебсервиса лежит в таком каталоге.
сам он допустим ничего не просит кроме прикладных данных, но пост на него не получится если юзер не доменный.

но опять таки это никак не связано с "авторизацией в вебсервисах"

> iop ©   (13.09.16 11:55) [10]
> но опять таки это никак не связано с "авторизацией в вебсервисах"

Я думаю, что сотрудник с той стороны подразумевает, что в его интранет-сервер, реализующий вебсервис, просто будут добавлены юзера с паролями из Active Directory. И я должен буду, при реализации HTTP-авторизации, передавать юзера и текущий пароль (откуда его брать только не знаю).
Спросил. Жду, чего ответит.

они всегда что-то подразумевают. и всегда что-то хотят не обязательно совпадающее с подразумеваемым.

веб сервис на пальцах если - самый обычный веб-ресурс на который могут не пускать анонимно. абсолютно точно так же как и к фотке с котиками.

плюс сам этот веб-ресурс-веб-сервис может иметь параметры логина/пароля в своих сугубо вебсервисных методах.

добавить если, то круче
"послать набор байт на удаленный порт"
не придумали еще )

сервисы-шмервисы.. все равно им на 80(если не переопределено) й порт шлёпнется что-то вроде s : string = 'http 1.0 Content-Type: application/x-www-form' и т.п.
откуда прилетит Cookie: твоя сессия ['{B3DA3A91-5CEC-4A52-AE8C-924D00C40E3A}']
и потом ты неявно всегда postом шлёшь еще один параметр
s : = s + Cookie, подтверждая, что ты это ты.
ну, или 150 параметров )

и все эти soap, библиотеки - просто некое форматирование этой строки s : string
что наглядно можно доказать, формируя текст запроса именно простым s := s +

как то понадобилось на какой то сервер тоже лазить, пишу им узнать как должно быть, какой обмен - какой IN|OUT - ничего не понял в итоге, какие-то версии какой-то библиотеки надо поставить пишут..
В снифере посмотрел обмен, сформировал s := s + и Port.Send(s);
Когда что-то приходит, распарсиваю и  s := s +ЧтоВернулось +  и Port.Send(s);
в общем, обычный TTCPClient вполне работает.
Безусловно, неудобно. Но.. вот прям ща я буду ставить эти библиотеки, php и прочее, ради одного запроса в сутки..

В общем решилось в итоге так:
1. Компьютер, где стоит IIS, добавлен в Active Directory.
2. Юзер и пароль будут передаваться в ходе NTLM авторизации.
От меня вообще ничего не требуется. Они все сами настроят.

Всем спасибо)

ЗЫ От вебсервисов вообще, кстати, отказались - будет HTTP GET-запрос с параметрами через URL с возвратом XML.

ЗЗЫ Пока ответа ждал наваял себе тестовый вебсервис и клиента к нему с передачей любых данных (в т.ч. и XML). Клево это в дельфи сделано! Жаль, что раньше не приходилось работать.
С удивлением обнаружил хорошую статью для старта на этом же сайте http://www.delphimaster.ru/articles/web_delphi/index3.html
Может, полезно будет.

очень полезно.

особенно с учетом того, что будет гет с xml в респонсе, статья помогает избежать ужасно длинного кода

with CoDomDocument.Create do
begin
 async := false;  
 if load(<get_url>) then ShowMessage(xml);
end