Кажется, что DefaultCredentials не передает заполненный объект Credential в службу WCF через канал - PullRequest
Новая
       63

Кажется, что DefaultCredentials не передает заполненный объект Credential в службу WCF через канал

0 голосов
/ 01 ноября 2019

У меня есть приложение WPF, которое запускается через браузер. При запуске все кажется, что аутентификация просто отлично, и приложение работает как задумано. После некоторого простоя, когда приложение не находится в фокусе, кажется, что таймаут учетных данных и следующий вызов, который открывает канал, завершаются неудачно с кодом состояния 401.2, возвращенным службой, работающей в IIS.

Я обнаружил, что еслиЯ переопределяю ChannelFactory.Credentials.Windows.ClientCredentials новым NetworkCredential, жестко закодированным в моей учетной записи AD, он работает независимо от времени простоя. Поэтому я подумал, что при открытии канала я могу переопределить это с помощью DefaultCredentials / DefaultNetworkCredentials из CredentialCache, и учетные данные будут там, и все будут довольны.

Похоже, что CredentialCache в общем случае не заполнен. Я знаю, что не смогу получить к ним доступ через непосредственное окно, но они, похоже, тоже ничего не передают в WCF.

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

public ServiceFactory(string EndpointURL, string EndpointName)
            : base(EndpointName)
        { 
            this.Endpoint.Address = new EndpointAddress(EndpointURL);
            this.Endpoint.Behaviors.Add(new MessageHeaderBehavior());

            System.Net.ServicePointManager.SecurityProtocol |= System.Net.SecurityProtocolType.Tls11 | System.Net.SecurityProtocolType.Tls12;
            this.Credentials.Windows.ClientCredential = System.Net.CredentialCache.DefaultNetworkCredentials as NetworkCredential;

Конфигурация приложения использует HTTPS и проверку подлинности Windows, хотя я почти уверен, что здесь это не имеет значения, но вот эта информация на всякий случай. 

<security mode="Transport">
    <transport clientCredentialType="Windows" proxyCredentialType="Windows" realm="" />
    <message clientCredentialType="Windows" algorithmSuite="Default" />
</security>

Я также попытался получить WindowsIdentity текущего пользователя и найти способ принудительно вставить это в новый экземпляр NetworkCredentials ... безрезультатно.

  1. Итак, есть ли способ для меня создать объект учетных данных, который можно прикрепить к этому каналу? Запрашивать у пользователя учетные данные, очевидно, не может быть и речи.

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


РЕДАКТИРОВАТЬ 1 :
Итак, я обнаружил, что если я перенесу службу для загрузки клиентского приложения WPF на тот же сервер, что и служба WCFпри прослушивании вызовов я никогда не сталкиваюсь с этой проблемой аутентификации после периода простоя (который, я думаю, определяется в пределах connectionTimeout в пределах IIS). Надеюсь, это временная работа. это все еще не решает фактическую проблему получения правильных учетных данных к службе.

Указывает ли это на проблему олицетворения?

...