Partilhar via

Cenários não suportados

  • Artigo

Por vários motivos, o Windows Communication Foundation (WCF) não oferece suporte a alguns cenários de segurança específicos. Por exemplo, o Windows XP Home Edition não implementa os protocolos de autenticação SSPI ou Kerberos e, portanto, o WCF não oferece suporte à execução de um serviço com autenticação do Windows nessa plataforma. Outros mecanismos de autenticação, como nome de usuário/senha e autenticação integrada HTTP/HTTPS são suportados ao executar o WCF no Windows XP Home Edition.

Cenários de representação

A identidade representada pode não fluir quando os clientes fazem chamadas assíncronas

Quando um cliente WCF faz chamadas assíncronas para um serviço WCF usando a autenticação do Windows sob representação, a autenticação pode ocorrer com a identidade do processo do cliente em vez da identidade representada.

WCF não oferece suporte à representação e um InvalidOperationException é lançado quando as seguintes condições existem:

  • O sistema operacional é o Windows XP.

  • O modo de autenticação resulta em uma identidade do Windows.

  • A Impersonation propriedade do OperationBehaviorAttribute é definida como Required.

  • Um token de contexto de segurança baseado em estado (SCT) é criado (por padrão, a criação está desabilitada).

O SCT baseado em estado só pode ser criado usando uma associação personalizada. Para obter mais informações, consulte Como criar um token de contexto de segurança para uma sessão segura.) No código, o token é habilitado criando um elemento de vinculação de segurança (ou SymmetricSecurityBindingElement AsymmetricSecurityBindingElement) usando o SecurityBindingElement.CreateSspiNegotiationBindingElement(Boolean) ou o SecurityBindingElement.CreateSecureConversationBindingElement(SecurityBindingElement, Boolean) método e definindo o requireCancellation parâmetro como false. O parâmetro refere-se ao cache do SCT. Definir o valor para false habilitar o recurso SCT baseado em estado.

Como alternativa, na configuração, o token é habilitado criando um <customBinding>, adicionando um <security> elemento e definindo o authenticationMode atributo como SecureConversation e o requireSecurityContextCancellation atributo como true.

Nota

Os requisitos anteriores são específicos. Por exemplo, o CreateKerberosBindingElement cria um elemento de ligação que resulta em uma identidade do Windows, mas não estabelece um SCT. Portanto, você pode usá-lo com a Required opção no Windows XP.

Possível conflito ASP.NET

WCF e ASP.NET podem habilitar ou desabilitar a representação. Quando ASP.NET hospeda um aplicativo WCF, pode existir um conflito entre o WCF e ASP.NET definições de configuração. Em caso de conflito, a configuração WCF tem precedência, a menos que a Impersonation propriedade seja definida como NotAllowed, caso em que a configuração de representação ASP.NET tem precedência.

As cargas de montagem podem falhar sob representação

Se o contexto representado não tiver direitos de acesso para carregar um assembly e se for a primeira vez que o Common Language Runtime (CLR) está tentando carregar o assembly para esse AppDomain, o AppDomain armazenará em cache a falha. As tentativas subsequentes de carregar esse assembly (ou assemblies) falham, mesmo depois de reverter a representação e mesmo que o contexto revertido tenha direitos de acesso para carregar o assembly. Isso ocorre porque o CLR não tenta novamente a carga depois que o contexto do usuário é alterado. Você deve reiniciar o domínio do aplicativo para se recuperar da falha.

Nota

O valor padrão para a AllowedImpersonationLevel WindowsClientCredential propriedade da classe é Identification. Na maioria dos casos, um contexto de representação no nível de identificação não tem direitos para carregar assemblies adicionais. Este é o valor padrão, por isso esta é uma condição muito comum de se estar ciente. A representação no nível de identificação também ocorre quando o processo de representação não tem o SeImpersonate privilégio. Para obter mais informações, consulte Delegação e representação.

A delegação requer negociação de credenciais

Para usar o protocolo de autenticação Kerberos com delegação, você deve implementar o protocolo Kerberos com negociação de credenciais (às vezes chamado Kerberos de várias pernas ou várias etapas). Se você implementar a autenticação Kerberos sem negociação de credenciais (às vezes chamada de Kerberos one-shot ou single-leg), uma exceção será lançada. Para obter mais informações sobre como implementar a negociação de credenciais, consulte Depurando erros de autenticação do Windows.

Criptografia

SHA-256 suportado apenas para usos de chaves simétricas

O WCF oferece suporte a uma variedade de algoritmos de criptografia e criação de resumo de assinatura que você pode especificar usando o conjunto de algoritmos nas associações fornecidas pelo sistema. Para maior segurança, o WCF suporta algoritmos Secure Hash Algorithm (SHA) 2, especificamente SHA-256, para criar hashes de resumo de assinatura. Esta versão suporta SHA-256 apenas para usos de chaves simétricas, como chaves Kerberos, e onde um certificado X.509 não é usado para assinar a mensagem. WCF não suporta assinaturas RSA (usadas em certificados X.509) usando hash SHA-256 devido à falta atual de suporte para RSA-SHA256 no WinFX.

Hashes SHA-256 compatíveis com FIPS não suportados

O WCF não suporta hashes compatíveis com FIPS SHA-256, portanto, os pacotes de algoritmos que usam SHA-256 não são suportados pelo WCF em sistemas onde o uso de algoritmos compatíveis com FIPS é necessário.

Algoritmos compatíveis com FIPS podem falhar se o registro for editado

Você pode habilitar e desabilitar algoritmos compatíveis com FIPS (Federal Information Processing Standards) usando o snap-in Configurações de Segurança Local do Console de Gerenciamento Microsoft (MMC). Você também pode acessar a configuração no registro. Observe, no entanto, que WCF não suporta o uso do registro para redefinir a configuração. Se o valor for definido como algo diferente de 1 ou 0, resultados inconsistentes podem ocorrer entre o CLR e o sistema operacional.

Limitação de criptografia AES compatível com FIPS

A criptografia AES compatível com FIPS não funciona em retornos de chamada duplex sob representação de nível de identificação.

Certificados CNG/KSP

API de criptografia: Next Generation (CNG) é o substituto de longo prazo para a CryptoAPI. Essa API está disponível em código não gerenciado no Windows Vista, Windows Server 2008 e versões posteriores do Windows.

O .NET Framework 4.6.1 e versões anteriores não oferecem suporte a esses certificados porque usam a CryptoAPI herdada para manipular certificados CNG/KSP. O uso desses certificados com o .NET Framework 4.6.1 e versões anteriores causará uma exceção.

Há duas maneiras possíveis de saber se um certificado usa o KSP:

  • Faça um p/invoke de CertGetCertificateContextProperty, e inspecione dwProvType no devolvido CertGetCertificateContextProperty.

  • Use o certutil comando da linha de comando para consultar certificados. Para obter mais informações, consulte Tarefas Certutil para solução de problemas de certificados.

A segurança da mensagem falhará se for necessário usar a representação de ASP.NET e a compatibilidade ASP.NET

O WCF não oferece suporte à seguinte combinação de configurações porque elas podem impedir que a autenticação do cliente ocorra:

  • ASP.NET A representação está ativada. Isso é feito no arquivo Web.config definindo o impersonate <identity> atributo do elemento como true.

  • ASP.NET modo de compatibilidade é ativado definindo o aspNetCompatibilityEnabled <atributo do serviceHostingEnvironment> como true.

  • A segurança do modo de mensagem é usada.

A solução alternativa é desativar o modo de compatibilidade ASP.NET. Ou, se o modo de compatibilidade ASP.NET for necessário, desative o recurso de representação de ASP.NET e use a representação fornecida pelo WCF. Para obter mais informações, consulte Delegação e representação.

Falha de endereço literal IPv6

As solicitações de segurança falham quando o cliente e o serviço estão na mesma máquina e endereços literais IPv6 são usados para o serviço.

Os endereços IPv6 literais funcionam se o serviço e o cliente estiverem em máquinas diferentes.

Falhas de recuperação WSDL com confiança federada

O WCF requer exatamente um documento WSDL para cada nó na cadeia de confiança federada. Tenha cuidado para não configurar um loop ao especificar pontos de extremidade. Uma maneira pela qual os loops podem surgir é usando um download WSDL de cadeias de confiança federadas com dois ou mais links no mesmo documento WSDL. Um cenário comum que pode produzir esse problema é um serviço federado onde o servidor de token de segurança e o serviço estão contidos dentro do mesmo ServiceHost.

Um exemplo dessa situação é um serviço com os seguintes três endereços de ponto de extremidade:

  • http://localhost/CalculatorService/service (o serviço)

  • http://localhost/CalculatorService/issue_ticket (STS)

  • http://localhost/CalculatorService/mex (o parâmetro de avaliação dos metadados)

Isso abre uma exceção.

Você pode fazer esse cenário funcionar colocando o issue_ticket ponto de extremidade em outro lugar.

Os atributos de importação WSDL podem ser perdidos

O WCF perde o controle dos atributos em um <wst:Claims> elemento em um RST modelo ao fazer uma importação WSDL. Isso acontece durante uma importação WSDL se você especificar <Claims> diretamente ou WSFederationHttpBinding.Security.Message.TokenRequestParameters IssuedSecurityTokenRequestParameters.AdditionalRequestParameters em vez de usar as coleções de tipo de declaração diretamente. Como a importação perde os atributos, a vinculação não percorre corretamente o WSDL e, portanto, está incorreta no lado do cliente.

A correção é modificar a ligação diretamente no cliente depois de fazer a importação.

Consulte também