Pasando HttpContext.Current.User.Identity a WCF

Question

Buscando un pequeño consejo (o tal vez incluso una respuesta directa).

Tengo un sitio web de MVC3. También tengo un conjunto de servicios WCF en ejecución (por ahora todo está en la misma caja).

Lo que estoy intentando hacer es autenticar al cliente (esa parte funciona bien), luego pasar ese usuario autenticado a varias llamadas WCF.

Por el momento me he enganchado hasta el método Application_AuthenticateRequest() en Global.Asax, que se reduce a la creación de un nuevo GenericIdentity & GenericPrincipal, a continuación, asignar ese principal a HttpContext.Current.User:

... 
GenericIdentity identity = new GenericIdentity(userName); 
GenericPrincipal principal = new GenericPrincipal(identity, null); 
HttpContext.Current.User = principal; 
... 

Y esa parte parece estar funcionando muy bien como bien.

Pero cuando llegué a mi servicio, perdí por completo al usuario que configuré. Los valores son vacíos o falsos

Lo principal que he notado es que en el lado del cliente, el objeto HttpContext.Current.User.Identity es del tipo {System.Web.Security.FormsIdentity}, pero en el servicio es del tipo {System.Security.Principal.WindowsIdentity}.

Basado en algo de lo que he leído, suena como simplemente modificar mi web.config por lo que contiene aspNetCompatibilityEnabled="true" puede ser suficiente para que esto funcione correctamente. Pero eso no es lo que estoy viendo. Entonces, o no estoy entendiendo todo (una posibilidad muy buena) o tengo algo malogrado (otra buena posibilidad).

Así que mi pregunta. ¿Es esto posible, y si es así, pensamientos sobre lo que me estoy perdiendo? Noté que algunos otros publicaron algo similar pero nunca recibieron una respuesta definitiva (ver here y here).

Cualquier sugerencia es muy apreciada.

Answer 1

Realmente no puedo responder directamente a su pregunta, pero espero que lo ayude a encontrar la respuesta definitiva.

Tiene 2 capas de servicio, y parece que su requisito es compartir la identidad de autenticación entre todas las capas.

Por lo tanto, en principio, necesitaría (al menos) los mismos mecanismos de autenticación o algoritmos o técnicas para lograr esto. Pero en este momento no está usando el mismo (y lo notó cuando vio un FormsIdentity y un WindowsIdentity allí).

Datos:

• , necesitará el mismo mecanismo de autenticación.
• Independientemente del mecanismo que utilice, debe admitir ese tercer salto que desea realizar (lo que significa que puede usar la identidad de un usuario con un tercer servicio sin tener realmente las credenciales para volver a autenticarse).

Problemas:

• Si continúa utilizando la autenticación de formularios, entonces usted tendrá que volver a autenticar con su servicio WCF (y por supuesto proporcionar credenciales de identidad, thispuede ayuda).Esto me resulta difícil a menos que conserve la contraseña que utilizó el Usuario para autenticarse, lo que generalmente es una mala idea.
• Si continúa utilizando la Autenticación de Windows para su sitio, entonces tendrá un problema si el usuario inicia sesión desde la Intranet. Lo curioso con Kerberos (el Directorio Activo usa Kerberos) es que permite al usuario acceder a recursos remotos sin volver a autentificar ... pero este Token de Identidad de Usuario solo sirve para 1 salto. Mientras que sus servicios WCF y MVC están en el mismo servidor, funcionará, pero si finalmente retira su servicio WCF ... eso es un tercer límite de cuadro ... un tercer salto, y el boleto de Kerberos no será lo suficientemente bueno.

Así que ... no estar al tanto de sus necesidades, quisiera en primer lugar que ha sugerido:

• Olvídate de autenticación en la capa de WCF
• Haga su acceso a los servicios WCF privada (el trabajo de su conexión en red. .. firewalls y otros). Comenzaría ejecutando WCF en un sitio web IIS aparte que no escucha el puerto 80 (o 443) y asegúrate de que Firewall bloquea el acceso a tu nuevo puerto WCF desde IPs fuera de tu LAN (o incluso mejor, fuera de tu red list (localhost por el momento)).
• Especifique la identidad del usuario como un parámetro de cada llamada WCF. O si se siente salvaje, explore formas de especificar una identidad de usuario a través de encabezados SOAP (si su WCF usa SOAP). Un encabezado personalizado también debería funcionar bien. Confíe entonces en su sitio web para desafiar y autenticar correctamente a los usuarios antes de otorgarles acceso a sus servicios de WCF.

Ya lo he visto correr muchas veces. No tener autenticación en un servicio privado es una buena oferta de rendimiento, pero debe tomar precauciones porque, en general, la mayoría de los ataques de TI provienen de la LAN interna.