WCF Proxy и userPrincipalName

Question

У нас есть довольно большое приложение, которое я и моя команда разрабатываем и которое содержит ряд служб на основе WCF NetTCP. Служба Windows, под которой будет работать эта система, будет не локальной учетной записью, а обычным пользователем домена (с правами администратора на серверах, на которых размещается служба). В середине тестирования подключения я столкнулся с проблемой сбоя вызовов SSPI. Основываясь на нескольких часах исследований, это привело меня к тому, что я пропустил следующую строку в моей конфигурации клиента:

<identity>
     <userPrincipalName value="MACHINE\user" />
</identity>

Проблема с использованием этого заключается в том, что я не использую VS или svcutil для генерации клиента / прокси для этой службы - используемые прокси полностью написаны в коде и наследуют System.ServiceModel.ClientBase. Я полагаю, что первоначальная причина, по которой был выбран этот вариант, заключалась в том, чтобы мы могли использовать одни и те же объекты DataMember, которые проходят через службы по обе стороны забора - сторонним группам не нужно подключаться к нашим службам, поэтому это не было проблемой .

Кто-нибудь знает, как мне установить userPrincipalName в клиенте (код или через конфигурацию), когда у меня нет конечных точек, указанных в стандартном разделе конфигурации system.serviceModel?

Вот как выглядит мой клиентский web.config для справки:

    <system.serviceModel>
    <diagnostics>
        <messageLogging logEntireMessage="true" logMalformedMessages="true"
         logMessagesAtServiceLevel="true" logMessagesAtTransportLevel="true" />
    </diagnostics>
    <behaviors>
        <serviceBehaviors>
            <behavior name="includeExceptions">
                <serviceDebug includeExceptionDetailInFaults="true"/>
                <dataContractSerializer maxItemsInObjectGraph="2147483647"/>
            </behavior>
        </serviceBehaviors>
    </behaviors>
    <bindings>
        <netTcpBinding>
            <binding name="NetTcpBinding_Default" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="Infinite" sendTimeout="01:00:00" portSharingEnabled="true" transferMode="Buffered" maxReceivedMessageSize="2147483647">
                <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
                <security mode="Transport">
                    <transport clientCredentialType="Windows" protectionLevel="EncryptAndSign"/>
                </security>
            </binding>
        </netTcpBinding>
    </bindings>

</system.serviceModel>

Answer 1

Создание прокси вручную не мешает помещать конфигурацию в файл конфигурации; вам просто нужно предоставить правильную перегрузку конструктора в прокси-классе, производном от ClientBase, который делегирует правильный конструктор в ClientBase, который принимает имя конечной точки для поиска в конфигурации.

При этом вы, конечно, можете заполнить идентификатор конечной точки с помощью кода, вам просто нужно создать правильный тип класса, производного от EndpointIdentity, и присоединить его к объекту EndpointAddress, который вы используете при создании экземпляра прокси-класса. Как то так:

EndpointIdentity epid = EndpointIdentity.CreateUpnIdentity("user@domain.fqdn");
EndpointAddress epaddr = new EndpointAddress(uri, epid);

MyClient client = new MyClient(epaddr);

Answer 2

Хотя я, вероятно, не отвечаю на ваш вопрос напрямую, чтобы использовать один и тот же элемент данных с обеих сторон ограждения, вам не нужно создавать прокси вручную. Что вы делаете, это то, что вы генерируете свои прокси, используя svcutil, и вы передаете dll, в котором есть ваш датаблок, как / r

* 1003 например *

svcutil http://localhost/service/service.svc /r:AssemblyThatHasDataMembers.dll /out:ServiceProxy.cs

При этом типы файлов данных не повторяются в вашем файле ServiceProxy.cs. Вы можете широко настроить это, передав wsdl / xsd (подход по настоящему контракту в первую очередь), настроить типы коллекций с помощью / ct и т. Д. И т. Д.

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