2009-07-31 26 views
6

¿Cuál es la mejor solución para implementar inicio de sesión único en una aplicación .net? Busqué en Google y encontré pocas soluciones, pero no estoy muy convencido con esas soluciones.cómo implementar inicio de sesión único en .Net?

El usuario inicia sesión en el sitio web1 y luego se traslada al sitio web2. ¿Cómo sabrá el sitio web2 que el usuario se ha conectado? Supongo que al pasar un token en la url que será verificado por el sitio web2 en la base de datos para la validez. Eso significa que necesito ordenar todas las direcciones URL en el sitio web1, que lleva al sitio web2.

En segundo lugar, si el usuario continúa navegando en el sitio web2, digamos 1 hora y luego muévase al sitio web1. En ese momento, la sesión del sitio web1 ha expirado, por lo que el usuario verá una página de inicio de sesión, ¿no es así? Pero este comportamiento es incorrecto según la funcionalidad de inicio de sesión único.

+0

Esto es Autenticación única y no Single Sign On, debe iniciar sesión N veces para N sitios con la misma autenticación. –

+0

Debe distinguir entre autenticación y autorización. Puede autorizar a un usuario, lo que significa que sabe que es quien dice ser, pero aún necesita autorizar a ese usuario, en cualquiera de sus 2 sitios web, para acceder al contenido al que puede acceder y al que no puede acceder en cada sitio. El token caducará, pero generalmente se puede actualizar para mantener el acceso. – htm11h

Respuesta

14

Creo que está entendiendo mal cómo funciona el inicio de sesión único.

Consideremos el sitio web1 y el sitio web2 que quieran usar el inicio de sesión único.

Se ha creado un sitio web de inicio de sesión en identityProvider. Este es el único lugar donde aparece una pantalla de inicio de sesión.

Cuando el usuario visita el sitio web1 y elige iniciar sesión en el sitio web1 envía al usuario a la pantalla de inicio de sesión en identityProvider. El usuario inicia sesión en identityProvider, que deja caer su propia cookie de inicio de sesión para su dominio (y quizás le permite al usuario guardar su información de autenticación para que nunca vuelva a aparecer). A continuación, redirige el navegador de nuevo al sitio web1, incluido un token en la solicitud, cuyo sitio web1 se abre, obtiene información de identidad y realiza sus propios bits de inicio de sesión (descartando su propia cookie de autenticación que dura como lo desee).

Luego el usuario visita el sitio web2 y selecciona el inicio de sesión. Website2 devuelve al usuario a identityProvider, que ya sabe quién es el usuario y, si el usuario ha elegido guardar su información de inicio de sesión, autentica de forma silenciosa y luego redirecciona de nuevo a sitio web2 con otro token que se abre y luego ejecuta sus propios bits de inicio de sesión.

Hay un montón de seguridad a su alrededor, lo que limita las fichas a determinadas páginas web, permitiendo sólo fichas para ser enviados a los sitios web de la lista blanca, etc., etc.

Así que para hacer frente a sus preocupaciones

  1. usuario inicia una sesión sitio web1 y luego se traslada al sitio web2. ¿Cómo sabrá el sitio web2 que el usuario se ha conectado? No es así sitio web2 primero debe solicitar información de autenticación desde el sitio de inicio de sesión único.
  2. Eso significa que necesito ordenar todas las direcciones URL en el sitio web1 que lleva al sitio web2? No, a menos que también haga que el sitio web1 sea el proveedor de identidades. Aun así, eso sería doloroso, es mejor que el sitio web2 redirija al proveedor de la identidad si es necesario un token.
  3. En segundo lugar, si el usuario continúa navegando en el sitio web2, digamos 1 hora y luego muévase al sitio web1. En ese momento, la sesión del sitio web1 ha expirado, por lo que el usuario verá una página de inicio de sesión, ¿no es así? - Depende de cómo configure el sitio web1 y cuánto tiempo dura la cookie de autenticación.
  4. Pero este comportamiento es incorrecto según la funcionalidad de inicio de sesión único. No, no es. El inicio de sesión único no significa que obtenga un token flotante que se comparte entre los sitios. Cada sitio web que utiliza el inicio de sesión único aún crea su propia cookie de autenticación. Lo que podría suceder es que si el usuario vuelve al sitio web1, detecta una cookie de autenticación expirada, luego envía al usuario a la página de inicio de sesión único donde están autenticados (silenciosamente) y un token nuevo se restituye al sitio web1, lo que crea un nuevo cookie de autenticación por sí mismo.
+0

Esto es Autenticación única y no Single Sign On, debe iniciar sesión N veces para N sitios con la misma autenticación. –

+0

Creo que el paso "Entonces el usuario visita el sitio web2 y * selecciona el inicio de sesión *" es lo que el OP desea evitar. ¿Cómo es eso posible? – CodeGrue

0

MS hizo un papel en ella dentro de la empresa hace unos años - que la puesta a punto de las muestras, pero nunca puestos en práctica de verdad - Single Sign-on

+0

Ya he visto ese documento pero no responde a mis dudas. –

3

El enfoque oficial de Microsoft es a través de los Servicios de federación de Active Directory (que envuelve SAML con autenticación AD). Esto tiene las características que está buscando, pero posiblemente sea demasiado pesado para una aplicación web pública.

3

Supongo que no desea usar la Autenticación de Windows con Active Directory, etc. Un método es pasar de una sesión autenticada a la otra utilizando un token de seguridad en la cadena de consulta, como usted describe.

Ambas aplicaciones usan la misma clave de cifrado público para codificar/descodificar el token de seguridad. Como dices, esto funciona bien si tienes enlaces de transición limitados y predefinidos entre los sitios, pero si deseas poder usar cualquier enlace de página entre las aplicaciones necesitarías generar esas urls sobre la marcha para que contengan el token.

La forma de lidiar con los tiempos de espera es que el token de seguridad también contiene un tiempo de caducidad. Generas un nuevo token de seguridad en cada solicitud de página, o cuando creas un nuevo enlace entre aplicaciones.

Normalmente, el token de seguridad contiene un ID de usuario y un tiempo de espera y el comprobador de inicio de sesión devuelve el ID de usuario o nulo si el tiempo de espera ha expirado.

No es una solución rápida para codificar correctamente y de forma segura. Tal vez puedas encontrar uno pre-construido en Code Project?

1

Puede utilizar diferentes mecanismos de SSO para diferentes aplicaciones según su aplicación.

  • que usa la máquina de configuración

  • inicio de sesión único dentro de un segundo dominio de nivel

  • Cross Domains Using Common database (Aplicación debe tomarse cuidado por nosotros)

Sin embargo, podría ver "Servicio SSO listo para usar" de Live, Google, Yahoo, Facebook, etc. para proporcionar autenticación mediante el soporte de SAML. Esto nos ayudará a deshacernos de los problemas que mantienen nuestra propia implementación del servicio SSO.

Si necesita una comprensión básica de cómo el trabajo de SSO, puede hacer referencia here

Cuestiones relacionadas