¿La mejor estrategia para pasar un token/cookie a un servicio WCF?

Question

Estamos creando un servicio web con WCF en .net 4.0. El servicio será utilizado principalmente por una interfaz ASP.net MVC, pero también será utilizado por una aplicación .net de Windows.

La autenticación básica de nombre de usuario/contraseña no funcionará, ya que no queremos guardar las credenciales de usuario, así que estaba pensando en autenticar una vez y crear un token simple (¿o debería llamarlo una cookie?) Con RNGCryptoServiceProvider .GetBytes() y luego usar eso para autenticar más solicitudes.

He examinado los diversos métodos comunes para hacer seguridad con WCF y en su mayoría parecen demasiado complejos, especialmente cuando todo lo que queremos hacer es esencialmente pasar una cookie a cada llamada a un método.

¿Cuál sería la mejor estrategia para pasar esta cookie de un cliente WCF a nuestros servicios WCF? El método preferido sería tan estrechamente acoplado con la arquitectura de seguridad de WCF como sea posible.

Hasta ahora me he apoyado en cualquiera usando custom HTTP headers, o custom authorization, pero no estoy seguro de cuál es el método más apropiado, en su caso.

Tenga en cuenta que para el sitio web ASP, se creará un nuevo canal para cada solicitud, mientras que se volvería a utilizar en la aplicación de Windows.

Answer 1

IMO hay dos maneras de hacer la seguridad wcf, Transporte o Messsage.

Puede implementar la autenticación de tipo de nombre de usuario en su aplicación. Por lo tanto, el lado del cliente debería completar un nombre de usuario y contraseña para enviar un mensaje. por lo que la unión del lado del cliente se vería como

<security mode="TransportWithMessageCredential"> 
    <message clientCredentialType="UserName"/> 
</security> 

En el lado del servidor se podría implementar su propio validador contraseña, como se muestra en este example

hacer esto sería autenticar su mensaje en el servidor, puede implementar cualquier lógica que desee para la validación de su contraseña. al usar esto, su mensaje se encriptaría usando SSL y se autenticaría usando su propia lógica implementada en el lado del servicio.