É possível cortar um cliente WCF para passar credenciais de mensagens sem SSL?

Question

escreveu uma ligação de um tempo atrás para permitir que a minha carga equilibrada fazenda para serviços de acolhimento via IIS WCF personalizado. A razão para a ligação costume era que cada servidor não tem SSL, mas necessária a capacidade de aceitar uma credencial de cliente de nome de usuário + senha. O proxy em frente a esta fazenda tem SSL para que o tráfego seria criptografados fora do firewall. Esta ligação funciona bem, mas agora eu estou no ponto onde eu preciso prestar atenção ao tráfego da minha máquina local e queria fazer isso SSL w / out no mix personalizado.

A questão é esta - no cliente .net se eu definir o meu modo de segurança = "TransportWithMessageCredential" I deve ter SSL mais eu começar a diversão de erro "esquema inválida, espera https"

É possível escrever algo personalizado para o cliente para "ignorar" que SSL está faltando, mas ainda me deixar passar o nome de usuário + senha através do cabeçalho SOAP?

Answer 1

Sim, eu escrevi um post sobre isso um tempo atrás chamado "How To: SSL Passthrough com o WCF --ou-- TransportWithMessageCredential através de HTTP".

A curto do que é que você precisa para criar o seu próprio HttpTransportBindingElement subclasse que "mentiras" sobre o fornecimento de segurança.

Answer 2

Há um Hotfix para .NET 3.5 SP1 que adiciona uma propriedade AllowInsecureTransport ao SecurityBindingElement . Este também será em .net 4 beta 2.

Answer 3

Eu assumo, em sua ligação, que você também terá um erro se você usar apenas o modo de segurança = "Mensagem" personalizado? A ligação de costume não era realmente necessário, já que (se não me engano) você pode usar o wsHttpBinding com o modo de segurança = "Mensagem" (não exigindo SSL).

Outra alternativa é apenas para gerar um certificado SSL mesmo, instalá-lo no IIS, e implementar uma confiança toda a política de certificado em seu código de chamada, mas esta é geralmente desaprovado (como é o envio de nomes de usuário e senhas em um canal inseguro) .

Uma terceira opção é mudar as operações do seu contrato para aceitar nomes de usuário e senhas (ou algum tipo de token) como um parâmetro, ou modificar suas contratos de dados para que você possa enviar as informações juntamente com qualquer objeto que você já pode estar enviando.