Aplicación web - Autenticación de usuario en dominios

Question

Un cliente nuestro se ha acercado a nosotros para desarrollar una aplicación y, como de costumbre, el alcance crece día a día.

Inicialmente, comenzó como una aplicación dedicada confinada dentro de su red corporativa. La autenticación del usuario se estableció al adquirir el inicio de sesión de Windows del usuario y usar una base de datos SQLServer para alojar los derechos de acceso. Todo muy sencillo.

Ahora quieren lo siguiente:
- Aplicación para ser basada en web
- Solicitud para ser alojado fuera de la red corporativa. - La autenticación de usuario funciona de la misma manera (sin usar contraseñas, solo inicio de sesión de Windows)

Para complicarlo aún más, quieren que las distintas funciones de la aplicación puedan ser utilizadas por otra aplicación que simplemente dispara las solicitudes HTTP.
: el usuario inicia sesión en la red corporativa
- Usuario lanza aplicación corporativa
- El usuario procesa los detalles del cliente
- El usuario hace clic en un botón
- La aplicación corporativa lanza una solicitud HTTP a nuestra aplicación web alojada
- La solicitud HTTP incluyó la autenticación necesaria y los detalles del cliente
- La autenticación del usuario se completa 'automáticamente' (sin participación humana)
- Los datos del cliente se transmiten de forma segura

Tienen muchas ganas de que hagamos esto por ellos, ya que nuestro enfoque inicial era lo que querían. Todavía quieren que hagamos esto, aunque dichas aplicaciones web alojadas no sean nuestra especialidad. Así que ahora me acerco a los expertos; - ¿Alguien tiene algún consejo sobre cómo abordar esto?
- ¿Alguien tiene alguna advertencia sobre las posibles dificultades a evitar?

Answer 1

Básicamente están hablando de acceso federado. Debería alojar un punto de autenticación dentro de su red, que a su vez reenvía un token a su aplicación que lo analiza y permite (o detiene el acceso). Esto es bastante estándar, y MS proporciona una buena base para esto en Marco de Ginebra . Esto también funcionará para llamadas de servicio web siempre que puedan cambiar su aplicación para usar WSFed como protocolo y hablar con un servicio de token de seguridad que emite silenciosamente el token de autenticación. En la mayoría de los casos, usarás SAML para esto. También tiene la ventaja adicional de que los detalles de autenticación nunca salen de su red corporativa.

La sugerencia de autenticación basada en certificado es interesante, pero requiere más trabajo en la implementación de una infraestructura PKI. Esto puede ser costoso.

CardSpace no funcionará, no es silencioso como parecen querer. OpenID tampoco es un iniciador, tampoco es silencioso.

Puntos adicionales si está mirando a Azure: los bits de autenticación de Azure también usan SAML / WSFed bajo el capó, y contienen fragmentos de Ginebra. Por lo tanto, si se muda a la nube, cada uno de sus clientes solo tendrá que configurar una página de inicio de sesión dentro de su red; todo lo que deberá hacer es confiar en esa página para emitir tokens de autenticación y analizarlos de acuerdo con sus reglas.

Answer 2

Quizás la comunicación WCF con autenticación basada en certificado, es decir, a usuarios externos que usan el servicio que la compañía les proporciona con un certificado válido. Esto no requeriría una contraseña de nombre de usuario, sino que se lo llevaría directamente.

Answer 3

¿Ya viste SAML ?

Answer 4

Echa un vistazo a Windows CardSpace ya que se integra con el inicio de sesión de Windows y permite el SSO escenario que requieren.

Answer 5

Dependiendo de cómo se construya su aplicación, puede jugar con machineKey en su web.config para permitir llamadas AJAX con inicio de sesión único (SSO). Esto implicaría una pequeña aplicación asp.net dentro de la red corporativa solo para entregar tokens de autenticación y redirigir a su aplicación alojada.

Si las dos aplicaciones comparten la misma machineKey, entonces el sistema de autenticación asp.net permitirá a los usuarios ingresar a su aplicación alojada.

Hay problemas con este enfoque:

• Introduce otra dependencia en su sistema (la aplicación de autenticación dentro de la red corporativa). Será una aplicación simple, pero tendrá problemas cuando intente diagnosticar problemas si no tiene acceso.
• Necesitas tu servicio alojado en el mismo dominio que la aplicación de autenticación (para que se pase el ticket de autenticación en la cookie HTTP).
• También necesitará un certificado SSL para que su servicio alojado asegure la información. (No es realmente una desventaja por sí misma, probablemente querrá hacer esto de todos modos).
• Debido a que usted y su cliente tendrán un machineKey compartido, atará una instancia de su aplicación a ese cliente en particular.

Answer 6

Yo usaría un proveedor / servidor privado de OpenID para esto.