Неподдерживаемые сценарии
По различным причинам Windows Communication Foundation (WCF) не поддерживает некоторые конкретные сценарии безопасности. Например, Windows XP Home Edition не реализует протоколы проверки подлинности SSPI или Kerberos, поэтому WCF не поддерживает запуск службы с проверка подлинности Windows на этой платформе. Другие механизмы проверки подлинности, такие как имя пользователя и пароль и встроенная проверка подлинности HTTP/HTTPS, поддерживаются при запуске WCF в Windows XP Home Edition.
Сценарии олицетворения
Олицетворенные удостоверения могут не выполняться, когда клиенты делают асинхронные вызовы
Если клиент WCF выполняет асинхронные вызовы службы WCF, используя проверку подлинности Windows при олицетворении, может иметь место проверка подлинности с удостоверением клиентского процесса, а не олицетворенным удостоверением.
Windows XP и защищенный файл cookie маркера контекста включен
WCF не поддерживает олицетворение и InvalidOperationException вызывается при наличии следующих условий:
Операционная система — Windows XP.
Режим проверки подлинности имеет результатом удостоверение Windows.
Свойство Impersonation объекта OperationBehaviorAttribute имеет значение Required.
Создан маркер контекста безопасности с отслеживанием состояния (SCT) (по умолчанию создание отключено).
Маркер SCT с отслеживанием состояния создается только с использованием пользовательской привязки. Дополнительные сведения см. в разделе "Практическое руководство. Создание маркера контекста безопасности для безопасного сеанса".) В коде маркер включен путем создания элемента привязки безопасности (SymmetricSecurityBindingElementили) с помощью SecurityBindingElement.CreateSspiNegotiationBindingElement(Boolean) метода или SecurityBindingElement.CreateSecureConversationBindingElement(SecurityBindingElement, Boolean) параметра requireCancellation false.AsymmetricSecurityBindingElement Параметр относится к кэшированию маркера SCT. Задание значения false включает функцию маркера SCT с отслеживанием состояния.
Кроме того, в конфигурации маркер включен путем создания <customBinding>, а затем добавления <security> элемента и задания атрибута authenticationMode в SecureConversation и атрибута requireSecurityContextCancellation true.
Примечание.
Эти требования зависят от конкретной ситуации. Например, метод CreateKerberosBindingElement создает элемент привязки, который имеет результатом удостоверение Windows, однако не устанавливает маркер SCT. Поэтому его можно использовать с параметром Required в Windows XP.
Возможный конфликт ASP.NET
WCF и ASP.NET могут включать или отключать олицетворение. Если ASP.NET размещает приложение WCF, конфликт может существовать между параметрами конфигурации WCF и ASP.NET. В случае конфликта параметр WCF имеет приоритет, если Impersonation свойство не задано NotAllowed, в этом случае параметр олицетворения ASP.NET имеет приоритет.
Загрузка сборок может завершиться ошибкой при олицетворении
Если олицетворенный контекст не имеет прав доступа для загрузки сборки и если это первая попытка загрузки этой сборки в среде CLR для этого домена приложения, в AppDomain кэшируется ошибка. Последующие попытки загрузки сборки (или сборок) также окажутся неудачными, даже если олицетворение отменено, а восстановленный контекст имеет права доступа для загрузки сборки. Это связано с тем, что среда CLR не повторно обрабатывает нагрузку после изменения контекста пользователя. Для восстановления после сбоя необходимо повторно запустить домен приложения.
Примечание.
Свойство AllowedImpersonationLevel класса WindowsClientCredential имеет значение по умолчанию Identification. В большинстве случаев контекст олицетворения уровня идентификации не имеет прав на загрузку дополнительных сборок. Это значение по умолчанию, поэтому необходимо учитывать это очень распространенное условие. Олицетворение на уровне идентификации также происходит, когда процесс олицетворения не имеет привилегии SeImpersonate. Дополнительные сведения см. в разделе "Делегирование и олицетворение".
Для делегирования требуется согласование учетных данных
Для использования протокола проверки подлинности Kerberos с делегированием необходимо реализовать протокол Kerberos с согласованием учетных данных (иногда называется многоступенчатой проверкой подлинности Kerberos). Если проверка подлинности Kerberos реализована без согласования учетных данных (иногда называется одноступенчатой проверкой подлинности Kerberos), возникает исключение. Дополнительные сведения о реализации согласования учетных данных см. в разделе "Отладка ошибок проверки подлинности Windows".
Шифрование
SHA-256 поддерживается только для использования симметричного ключа
WCF поддерживает различные алгоритмы создания дайджеста шифрования и подписи, которые можно указать с помощью набора алгоритмов в предоставленных системой привязках. Для повышения безопасности WCF поддерживает алгоритмы secure Hash Algorithm (SHA) 2, в частности SHA-256, для создания хэшей хэшей сигнатуры. Этот выпуск поддерживает алгоритм SHA-256 только для симметричных ключей (например, ключей Kerberos) и случаев, когда сертификат X.509 не используется для подписи сообщения. WCF не поддерживает подписи RSA (используемые в сертификатах X.509) с использованием хэша SHA-256 из-за текущего отсутствия поддержки RSA-SHA256 в WinFX.
Хэши, совместимые с FIPS-256, не поддерживаются
WCF не поддерживает хэши, совместимые с SHA-256 FIPS, поэтому наборы алгоритмов, использующие SHA-256, не поддерживаются WCF в системах, где требуется использование алгоритмов, совместимых с FIPS.
Алгоритмы, совместимые с FIPS, могут завершиться ошибкой, если реестр редактируется
Включать и отключать FIPS-совместимые алгоритмы можно с помощью оснастки «Локальные параметры безопасности» консоли управления (MMC). Кроме того, можно получить доступ к этому параметру в реестре. Обратите внимание, что WCF не поддерживает использование реестра для сброса параметра. Задание значения, отличного от 1 или 0, может привести к противоречивым результатам в среде CLR и операционной системе.
Ограничение шифрования AES, совместимое с FIPS
Шифрование AES, совместимое с FIPS, не работает в дуплексных обратных вызовах под олицетворением уровня идентификации.
Сертификаты CNG/KSP
API шифрования: следующее поколение (CNG) является долгосрочной заменой cryptoAPI. Этот API доступен в неуправляемом коде в Windows Vista, Windows Server 2008 и более поздних версиях Windows.
платформа .NET Framework версии 4.6.1 и более ранних версий не поддерживают эти сертификаты, так как они используют устаревшую версию CryptoAPI для обработки сертификатов CNG/KSP. Использование этих сертификатов с платформа .NET Framework 4.6.1 и более ранними версиями приведет к исключению.
Узнать, используется ли в сертификате KSP, можно двумя способами.
Сделайте платформозависимый вызов
p/invokeфункцииCertGetCertificateContextPropertyи проверьте свойствоdwProvTypeвозвращенного объектаCertGetCertificateContextProperty.certutilИспользуйте команду из командной строки для запроса сертификатов. Дополнительные сведения см. в разделе "Задачи Certutil" для устранения неполадок с сертификатами.
Безопасность сообщений завершается ошибкой, если требуется использование олицетворения ASP.NET и совместимость ASP.NET
WCF не поддерживает следующее сочетание параметров, так как они могут препятствовать проверке подлинности клиента:
включена олицетворение ASP.NET. Это делается в файле конфигурации
<identity>Web.config, задавimpersonateатрибут элементаtrueв значение .ASP.NET режим совместимости включен путем задания
aspNetCompatibilityEnabledатрибута <serviceHostingEnvironment>true.Используется режим безопасности сообщения.
Для этого необходимо отключить режим совместимости ASP.NET. Или, если требуется режим совместимости ASP.NET, отключите функцию олицетворения ASP.NET и используйте олицетворение, предоставленное WCF. Дополнительные сведения см. в разделе "Делегирование и олицетворение".
Сбой адреса литерала IPv6
Если клиент и служба находятся на одном компьютере, а для службы используются литеральные адреса IPv6, происходит сбой запросов безопасности.
Литеральные адреса IPv6 можно использовать, если служба и клиент находятся на разных компьютерах.
Сбои извлечения WSDL с федеративными отношениями доверия
WCF требует ровно одного документа WSDL для каждого узла в федеративной цепочке доверия. Следует быть внимательным, чтобы не создать замкнутый цикл при задании конечных точек. Например, замкнутый цикл появляется при использовании загрузки WSDL федеративной цепи доверия с несколькими ссылками в одном документе WSDL. Типичной ситуацией, в которой может возникать эта проблема, служит федеративная служба, в которой сервер маркера безопасности и служба находятся в одном узле ServiceHost.
Ниже приведен пример службы с тремя адресами конечных точек:
http://localhost/CalculatorService/service(служба)http://localhost/CalculatorService/issue_ticket(STS)http://localhost/CalculatorService/mex(конечная точка метаданных)
В этом случае создается исключение.
Чтобы этот сценарий работал, необходимо разместить конечную точку issue_ticket в каком-либо другом месте.
Атрибуты импорта WSDL можно потерять
WCF теряет атрибуты элемента <wst:Claims> в шаблоне RST при выполнении импорта WSDL. Это происходит при импорте WSDL, если <Claims> заданы непосредственно в WSFederationHttpBinding.Security.Message.TokenRequestParameters или IssuedSecurityTokenRequestParameters.AdditionalRequestParameters вместо использования коллекций типов утверждений. Вследствие потери атрибутов при импорте привязка не выполняет надлежащим образом полный цикл через WSDL и поэтому является неверной на стороне клиента.
Для устранения этой проблемы необходимо изменить привязку непосредственно в клиенте после выполнения импорта.