Share via

Cenários sem suporte

  • Artigo

Por vários motivos, o WCF (Windows Communication Foundation) não dá 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 dá 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, têm suporte 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 autenticação do Windows em representação, a autenticação pode ocorrer com a identidade do processo cliente em vez da identidade representada.

O WCF não dá suporte à representação, e um InvalidOperationException é gerado quando as seguintes condições existem:

  • O sistema operacional é Windows XP.

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

  • A propriedade Impersonation do OperationBehaviorAttribute é definida como Required.

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

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

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

Observação

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

Possível conflito de ASP.NET

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

Os carregamentos de assembly podem falhar na representação

Se o contexto representado não tiver direitos de acesso para carregar um assembly e se for a primeira vez que o CLR (Common Language Runtime) estiver tentando carregar o assembly desse 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 carregar novamente depois que o contexto do usuário é alterado. Você deve reiniciar o domínio do aplicativo para se recuperar da falha.

Observação

O valor padrão da propriedade AllowedImpersonationLevel da classe WindowsClientCredential é Identification. Na maioria dos casos, um contexto de representação no nível de identificação não tem direitos de carregar assemblies adicionais. Esse é o valor padrão, portanto, essa é uma condição muito comum para 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 privilégio SeImpersonate. Para obter mais informações, confira Delegação e representação.

A delegação exige a negociação de credenciais

Para usar o protocolo de autenticação Kerberos com a delegação, você precisa implementar o protocolo Kerberos com a negociação de credenciais (às vezes chamado de Kerberos de vários segmentos ou de várias etapas). Se você implementar a autenticação Kerberos sem a negociação de credenciais (às vezes chamada de Kerberos de processo único ou de segmento único), uma exceção será gerada. Para obter mais informações sobre como implementar a negociação de credenciais, consulte Depurando erros de autenticação do Windows.

Criptografia

SHA-256 compatível apenas com usos de chave simétrica

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

Hashes SHA-256 compatíveis com FIPS sem suporte

O WCF não dá suporte a hashes compatíveis com FIPS SHA-256, portanto, os conjuntos de algoritmos que usam SHA-256 não têm suporte do WCF em sistemas em que o uso de algoritmos compatíveis com FIPS é necessário.

Algoritmos compatíveis com FIPS poderão falhar se o Registro for editado

Você pode habilitar e desabilitar algoritmos compatíveis com FIPS (Federal Information Processing Standards) usando o snap-in MMC (Console de Gerenciamento da Microsoft) de Configurações de Segurança Local. Você também pode acessar a configuração no Registro. No entanto, observe que o WCF não dá suporte ao uso do Registro para redefinir a configuração. Se o valor for definido como algo diferente de 1 ou 0, resultados inconsistentes poderão 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: próxima geração (CNG) é a substituição 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.

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

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

Falha na segurança da mensagem se estiver usando representação ASP.NET e a compatibilidade com ASP.NET for necessária

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

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

  • O modo de compatibilidade ASP.NET é habilitado definindo o atributo aspNetCompatibilityEnabled de <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, desabilite o recurso de representação ASP.NET e use a representação fornecida pelo WCF. Para obter mais informações, confira 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 no mesmo computador e os endereços literais IPv6 são usados para o serviço.

Os endereços IPv6 literais funcionarão se o serviço e o cliente estiverem em computadores diferentes.

Falhas de recuperação do 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 em que o Servidor de Token de Segurança e o serviço estão contidos no mesmo ServiceHost.

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

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

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

  • http://localhost/CalculatorService/mex (o ponto de extremidade de metadados)

Isso gera uma exceção.

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

Atributos de importação WSDL podem ser perdidos

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

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

Confira também