Cómo configurar la seguridad al llamar al Servicio WCF desde .Net 2.0 Cliente

Question

Tengo un servicio WCF en funcionamiento y puedo comunicarme entre el servicio y un cliente .Net 2.0 utilizando basicHttpBinding.

Ahora necesito bloquear el servicio WCF para que solo pueda ser llamado por clientes autenticados.

Tengo control sobre los clientes que llamarán a mi servicio. Los clientes son parte de un producto que se instalará en la naturaleza y "llamando a casa" para enviar y extraer datos. La aplicación cliente está escrita para el framework .Net 2.0 y no se puede actualizar a 3.0 o 3.5 en este momento. No puedo agregar cuentas de usuario de Windows a las máquinas del cliente.

¿Cuáles son mis opciones para asegurar el servicio WCF y poder autenticar desde mis clientes .Net 2.0? Además, los datos deben pasarse a través de https.

He estado buscando en la web, y siento que estoy en una loca búsqueda.

Answer 1

El uso de certificado SSL es la única opción para que el cliente .NET 2.0 acceda al servicio WCF ya que basicHttpBinding no proporciona seguridad. Al usar SSL, está asegurando todo el canal de transporte.

Compruebe el enlace http://www.codeplex.com/WCFSecurityGuide/Release/ProjectReleases.aspx?ReleaseId=15892. Cubre la seguridad WCF que cubre todos los escenarios.

Para obtener un certificado SSL gratis, visite http://www.comodo.com/ o http://www.instantssl.com/ y pruébelo en su aplicación.

Answer 2

Su seguridad estará cubierta por el ssl.

Para la autenticación tiene dos opciones: básica (nombre de usuario y contraseña) o certificado.

Here es un video que demuestra la configuración de la autenticación de certificados.

En que está configurando los elementos de seguridad de la basicHttpBinding muestra a continuación:

< basicHttpBinding>
    < nombre del enlace = "basicHttp">
        < modo de seguridad = "TransportWithMessageCredential" >
            < mensaje clientCredentialType = "Certificado" />
        </seguridad>
    </binding>
</basicHttpBinding>

También hay una buena página en este here. Google en clientCredentialType y debe encontrarse en el camino correcto lo suficientemente pronto.

Para configurar los certificados de cliente está buscando el archivo de política wse *.

Tendrá que averiguar cómo va a proporcionar el certificado del cliente a los diversos sitios. Eso depende de las preocupaciones de seguridad del proyecto. Hay varias maneras (ninguna de las cuales puedo recordar, lo siento, la última vez que hice esto para wse * wse * hace dos años, así que los detalles se olvidan, pero es ciertamente posible, tomó unos días de investigación sólida para encontrar un buen método)

Answer 3

Puede configurar un punto final WCF para usar autenticación de 2 vías SSL. Esto significa que puede solicitar a los clientes que presenten un certificado X.509 que confirme su identidad cada vez que realicen una solicitud al servicio.

Por el lado del servidor, puede usar uno de los esquemas de validación incorporados en WCF o proporcionar su propia lógica de validación para verificar el certificado X.509.
Si estuviera alojando su servicio en IIS, sería trivial configurar SSL para requerir certificados de cliente en el nivel de transporte. Sin embargo, se puede encontrar una buena guía sobre cómo implementar este comportamiento en un servicio WCF alojado en sí mismo aquí:

http://leastprivilege.com/2007/08/25/certificate-based-authentication-and-wcf-message-security/

No he probado esto por mí mismo, pero, dado que esto crea un requisito de seguridad en el message-level, creo que deberá usar wsHttpBinding para aplicarlo en su contrato WSDL, ya que la imposición de requisitos de seguridad para acceder a un servicio web forma parte de los estándares WS- *.

Si usted tiene que utilizar basicHttpBinding, puede probar esta solución en lugar de que mueve las cosas en el transporte de nivel:

http://leastprivilege.com/2007/08/26/certificate-based-authentication-and-wcf-mode-independent/

espero que esto ayude

Answer 4

bien así, con SSL tienes seguridad de nivel de transporte; lo cual está bien, eso protege el mensaje de husmear y cambiar.

Así que ahora tiene opciones; ¿necesita la validación para guardar silencio o puede solicitar al usuario un nombre de usuario/contraseña cuando se inicia el programa? Si debe ser silencioso, puede ir al certificado del lado del cliente como se mencionó (aunque eso es doloroso, tendrá que generar los certificados usted mismo y validarlos, por lo que debe considerar ejecutar su propia autoridad de certificación). O puede incrustar un encabezado personalizado en el mensaje que contiene una ID de cliente y hacerlo de la manera más barata.

Sin embargo, si puede solicitar un nombre de usuario y contraseña, entonces se autentica de esa manera y lo conecta fácilmente a una base de datos usando custom authenticator, o incluso usando ASP.NET membership database.

Answer 5

Esto es lo que terminé haciendo lo que parecía ser la solución más sencilla en nuestra situación, que es bastante pequeña escala con sólo un puñado de servicios web expuestos:

1. asegurado el transporte con SSL
2. Los clientes primero inician sesión en el servicio web llamando a un método de inicio de sesión en el servicio web. Si el inicio de sesión tiene éxito, devuelve un FormsAuthenticationTicket encriptado al cliente.
3. Los clientes deben proporcionar el ticket de autenticación de formularios con cada llamada de servicio web. Cada método verifica si el ticket es válido y, si es así, hace su trabajo. Si el ticket ha expirado o no es válido, los clientes deben volver a autenticarse.

la esperanza de que ayude a alguien ...