2011-05-04 13 views
8

Estoy implementando un servicio WCF que se utilizará (en parte) dentro de una LAN privada.¿Cuál es la forma más sencilla de implementar el cifrado en WCF cuando se usa netTcpBinding?

Usaré netTcpBinding y me gustaría implementar alguna forma de seguridad en las comunicaciones, más específicamente, es importante que los datos sean encriptados para que (por ejemplo) nadie pueda ver los datos que se transfieren a través de la red.

No creo que la autenticación de Windows sea apropiada ya que el usuario final puede no mantener sus inicios de sesión de Windows y los roles de forma rigurosa para usarlos como autenticación. ¿Estoy en lo cierto al pensar que esto lo haría inapropiado? Por favor corrígeme si estoy equivocado.

Mi pregunta es, ¿cuál es la forma más sencilla de implementar el cifrado en un servicio WCF utilizando netTcpBinding? particularmente cuando el tipo de credencial de Windows no está disponible.

He intentado experimentar con certificados (generando mi propio uso de makecert) pero hay una clara falta de tutoriales y documentación que describan cómo hacerlo de principio a fin usando TCP y alojando el servicio en algo que no sea IIS. Una gran cantidad de ellos que hablar a través de la forma de generar los certificados en detalle (y no hay dos de estos tutoriales son exactamente los mismos en este sentido) y terminar diciendo algo como

usarlos para acceder al servicio y el cliente

... bien, lamentablemente ese es el proceso que necesito un poco más de aclaración!

¡En general, la solución de certificados parece estar por encima y un poco demasiado solo para obtener datos encriptados!

Cualquier ayuda o corrección en cualquier suposición que podría haber hecho sería muy apreciada.

+1

Antes de comenzar; ¿Cuál es el impulso para usar NetTcpBinding? Por ejemplo, ¿BasicHttpBinding con seguridad de transporte (SSL) haría el trabajo?(Menciono esto porque SSL es casi seguro que es lo "más simple" para funcionar) –

+0

Supongo que el servicio y el cliente se ejecutarán dentro de la misma LAN y varios artículos de MSDN afirman que el rendimiento se mejorará al usar TCP en lugar de HTTP - eso y el hecho de que estoy más familiarizado con el uso de zócalos TCP y UDP que cualquier cosa basada en Web/http, por lo que tienden a inclinarse hacia él debido a la familiaridad :) No hay un requisito firme, lo que significa que tengo que usar TCP. – Lewray

Respuesta

2

Tras el debate en los comentarios ...

En mi experiencia (y he hecho un montón de trabajo de serialización/WCF) el rendimiento "beneficio" de NetTcpBinding (y NetDataContractSerializer) es en gran parte mítica. Nunca he visto un importante diferencia, y a menudo los enlaces http vainilla son más rápidos.

Me cambiaría a BasicHttpBinding sobre SSL, que es trivial de configurar y es seguro.

Si quiere mejoró el rendimiento etc., cambiaría el serializador a algo como protobuf-net (revelación: soy el autor). Este hace han demostrado fácilmente ventajas de rendimiento, y funciona muy bien dentro de WCF (sólo un cambio en un archivo de configuración), especialmente sobre BasicHttpBinding (con un impulso adicional si se habilita la masa máxima de despegue mensaje a codificar, ya que es un binario formato).

Personalmente, nunca uso NetTcpBinding; como se mencionó, el rendimiento es cuestionable y te hace depender de cosas que no funcionarán en http básico si encuentras que necesitas acceso WAN.

+0

Gracias por la respuesta. ¿Todavía sería trivial configurar esto considerando que no estoy alojando el servicio en IIS? ¿Todavía tendría que pasar por todo el proceso de usar makecert y generar certificados durante mi fase de diseño y depuración? – Lewray

+0

@Lewray puede hospedar fuera de IIS, pero sí, el certificado se vuelve más complicado. Sin embargo, hay tutoriales - IIRC, que codician exactamente esto. –

+0

Según mi experiencia, he descubierto que BasicHttpBinding logra solo el 70% de lo que obtengo al utilizar NetTcpBinding, pero de nuevo estoy paleando muchos GB de datos binarios. Además, he descubierto que IIS se retrasa de vez en cuando, ocasionalmente obtiene tiempos de respuesta extremadamente largos al usar un enlace HTTP. –

Cuestiones relacionadas