AX 2012: Авторизация при вызове сервисов

[cherv]

Добрый день, пытаюсь решить следующую проблему с авторизацией при вызове сервисов в AX 2012 (build 6.0.1108.670).
Из приложения на C# в Visual Studio вызываю любой Ax-овский сервис (сделал свой кастомный), например:

PHP код:

WX_CommonServiceClient com = new WX_CommonServiceClient();
string s = com.getPhoneTypes(null); 


Если данное C#-приложение выполняется под пользователем, который обладает достаточными правами в AX, все проходит успешно, если же, например, пользователь в AX не заведен, происходит ошибка

System.ServiceModel.FaultException: Failed to logon to Microsoft Dynamics AX.

То есть, авторизация осуществляется по вызывающему сервис пользователю.

Решить проблему можно следующим образом (в мануалах по сервисам такого не нашел, опытным путем определилось) - добавить следующий код:

PHP код:

WX_CommonServiceClient com = new WX_CommonServiceClient();
com.ClientCredentials.Windows.ClientCredential.UserName = "user";
com.ClientCredentials.Windows.ClientCredential.Domain = "domain.ru";
com.ClientCredentials.Windows.ClientCredential.Password = "pass";
string s = com.getPhoneTypes(null); 


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

Но данный вариант не очень нравится - хранить в коде или в конфигурационном файле учетные данные о пользователе с довольно широкими правами в AX.

При этом в настройке сервиса (в конфигурационной утилите в Configure Services) для каждого сервиса можно указать учетные данные (UserPrincipalName - по умолчанию заполняется данными учетной записи, под которой зарущен AOS; либо ServicePrincipalName и т.д.), и потом эта настройка копируется в C#-приложении - создается app.config, включающий в том числе и эти строки

PHP код:

<identity>
<userPrincipalName value="user@domain.ru" />
</identity> 


Но это все не дает никакого эффекта - можно везде заполнить эти значения, либо просто стереть - результат не меняется.

Есть ли у кого каеи мысли на этот счет - это просто недоделка пока в AX 2012 (ведь если настройки по userprincipalname есть, значит, они должны использоваться), либо я что-то не так настраиваю?

[Maximin]

Курите binding в сборке, из которой вы обращаетесь к AX.
Вкратце - Basic binding не позволит указать параметры авторизации.
Используйте WSHttp binding - там можно указать, кем вы собираетесь представляться сервису.
Нужно также будет настроить IIS и сервис в Аксе соответствующим образом.

Есть два пути - либо прописать нужный binding в config для сборки, либо собрать его в runtime с нужными параметрами.

[cherv]

Maximin, спасибо за ответ.
По умолчанию, AX-овский сервис создается со следующими параметрами в app.config в C#-приложении:

PHP код:

<endpoint address="net.tcp://server:8201/DynamicsAx/Services/WX_UserServices"
binding="netTcpBinding" bindingConfiguration="NetTcpBinding_WX_CommonService"
contract="UserServ.WX_CommonService" name="NetTcpBinding_WX_CommonService">
<identity>
<userPrincipalName value=user@qdomain.ru />
</identity>
</endpoint> 


То есть, это не basic binding, а net tcp binding. К сожалению, в биндингах я не очень разбираюсь - но я так понял, что nettcpbinding позволяет в identity как раз указать, под кем сервис должен работать, так? Сами сервисы сейчас хостятся на AOS, поэтому опять же хотел уточнить - есть ли необходимость настройки IIS?
В-общем, получается, что binding прописан в config для сборки, но в таком варианте не работает?

[Maximin]

Вам вы еще тогда разобраться - у вас message level security или transport level?
Anyway, реквизиты доступа автоматом из Конфига грузиться не будут, вам нужно сделать это в коде, взяв его из config или откуда-то еще (ConfigurationManager.AppSettings ??).
Вообще, пожелание довольно странное - с одной стороны, вы не хотите давать пароль end-userу, а с другой - вам неоткуда взять пароль, как только из самого приложения-клиента, что в общем-то тоже самое, пусть он там и будет зашифрован. Или же вы хотите заставить AX WCF сервис из IIS представляться Аксапте каким-то заранее определенным пользователем?
И я что-то не совсем понимаю - что значит

Цитата:

По умолчанию, AX-овский сервис создается со следующими параметрами в app.config в C#-приложении:

Так речь идет о клиенте сервиса или о самом AX сервисе? И там и там есть config. В обоих должны совпадать привязки и типы используемого шифрования/аутентификации.

Нашел у себя ссылки на полезные темы (особенно первая, может наведет на мысль):
http://www.ksaelen.be/wordpresses/dy...n-wcf-service/
http://stackoverflow.com/questions/9...iguration-file

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

[cherv]

Maximin, спасибо.
Вообще, пытался разобраться, как в принципе правильно работать с веб-сервисами - если другого варианта, кроме как в любом случае в коде грузить учетные данные, нет, то этого достаточно.

Цитата:

Или же вы хотите заставить AX WCF сервис из IIS представляться Аксапте каким-то заранее определенным пользователем?

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

Цитата:

И я что-то не совсем понимаю - что значит
"По умолчанию, AX-овский сервис создается со следующими параметрами в app.config в C#-приложении: "

- после добавления ссылки (add reference) на AX-овский сервис в C#-приложении, в клиентском проекте создается автоматом файл app.config с этими параметрами. А так - да, есть настройка identity и в самом AX-сервсие. Меня, честно говоря, в этой всей истории смущает только - а зачем есть возможность и в настройках сервиса, и в настройках конфига клиента указать либо UserPrincipalName, либо ServicePrincipalName (либо другие значения - dns, certificate и т.д.), и при этом автоматической авторизации сервиса в Ax под указанным пользователем не происходит.

В той же настройке сервиса в AX есть описание этих параметров - например, напротив UserPrincipalName описание следующее:
Specifies settings that enable the client to authenticate the service. At the client, the identity element allows a developer to specify the expected identity of the service. In the security authentication process between the client and service, WCF ensures that the identity of the service matches the value of this element. When set, this element specifies the expected actual principal name of the service. Only one of the settings in this section can have a value. When used in a service endpoint, the identity element defines the identity of the service in WSDL.

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

[Maximin]

UserPrincipalName и ServicePrincipalName - это уже для того, чтобы клиентское приложение могло удостовериться, что оно общается не с "левым" сервисом а именно тем, который был в конкретном WSDL. И чтобы Kerberos смог понять, что какая-то служба на конкретном порту/хосте ассоциируется с своим конкретным пользователем. Это почти не имеет отношения к авторизации клиента. Клиент просто должен указать в userPrincipalName такой же SPN, какой установлен у службы.
См. http://blogs.iis.net/brian-murphy-bo...palname-s.aspx
http://www.osp.ru/win2000/2007/04/4315478/

А что касается вашей идеи о едином пользователе "трое из сервиса, одинаковы с лица", то это нужно делать несколько по-другому, в Аксе несколько другая концепция относительно того, чего вы хотите. Все направлено на сохранение identity пользователя, запустившего клиентское приложение.
В общем-то, для того и настраивается delegation чтобы эта вот identity сохранилась на всем пути: Хост с клиентом -> WCF компонента (IIS) -> AOS.
Соответственно, если вы хотите чтобы все пользователи под кем бы не подсоединялись к Аксовскому сервису, выглядели одним и тем же - то настройте в Аксе trusted delegation user, заведите в домене бесправную запись с заранее известным паролем (по типу .NET Proxy user), заведите его в Аксе и поставьте в соответствие этому trusted delegation user наряду с остальными пользвателями. Залейте в app.config клиента его имя/пароль, и пусть клиенты всегда соединяются с этим логином/паролем который вы в runtime будете присваивать Windows.ClientCredential. Вообще говоря, если кроме этого псевдопользователя никто со своими учетными данными к сервису ходить не будет, тогда можно и без trusted delegation - напрямую завести нашего бесправного пользователя в Аксе. Но фактически, это почти равносильно отсутствию пароля вовсе, т.к. пароль все равно доступен кому-то извне, пусть и зашитым в приложение-клиент.
Кстати, если у вас появятся мысли о доступе вообще без пароля - имейте в виду, что Dynamics AX позволяет доступ без авторизации только к конечной точке по умолчанию. Для всех остальных точек нужно иметь другой тип привязки, чтобы иметь возможность указать конечную точку, а в любом из этих типов нужно указывать credentials.

P.S. Кстати, попробуйте перед своим com.ClientCredentials.Windows.ClientCredential.UserName = ... поставить вывод текущего UserName и посмотрите что там лежит. Просто ради интереса.

[cherv]

Общую идею понял, спасибо за ссылки и подробный ответ, буду дальше изучать.

Цитата:

P.S. Кстати, попробуйте перед своим com.ClientCredentials.Windows.ClientCredential.UserName = ... поставить вывод текущего UserName и посмотрите что там лежит. Просто ради интереса.

Посмотрел, перед присвоением UserName = null - я пока не вкурил, что это значит .