it-swarm-es.com

¿Cómo configurar un inicio de sesión único para varios dominios?

He configurado un inicio de sesión único para dos de nuestros sitios que viven en el mismo dominio: a.domain.com y b.domain.com

Lo hice a través de cookies, pero dependen del dominio. Y, como está escrito en el Gran Libro, ahora la necesidad de inicio de sesión único en diferentes dominios ha levantado su cabeza fea :) Estoy 99% seguro de que puedo olvidar el uso de OpenId (no les gustan los servicios externos aquí, ni siquiera pude hacer que aceptaran reCaptcha )

Me gustaría poder identificar a alguien en diferentes sitios web (a.domain.com, b.anotherdomain.com, etc.). ¿Cuáles son las formas recomendadas para configurar/administrar el inicio de sesión único en múltiples dominios? ¿Algún problema de seguridad específico que deba tener en cuenta antes de redactar una propuesta?

21
samy

La forma en que se implementó el inicio de sesión único para Stack Exchange Network es muy interesante. Hace uso de almacenamiento local HTML 5 . Dependiendo del soporte del navegador que requiera, puede usar un método similar.

Puede consultar la publicación del blog stackoverflow Inicio de sesión automático de red global para obtener más detalles.

16
Mark Davidson

No tiene que usar un servicio externo para OpenId. Podría alojar un servidor OpenId internamente y usarlo para su SSO. Esto le permitiría aprovechar el código fuente abierto y todo el trabajo que se ha dedicado a hacer que OpenId sea seguro.

PD: OpenId se puede utilizar para tener una identidad única utilizada por muchos sitios, pero aún debe iniciar sesión "manualmente" en cada dominio.

5
Olivier Lalonde

Dos buenos protocolos para esto son OAuth (http://en.wikipedia.org/wiki/OAuth) y SAML. Puede ejecutar su propio sitio de "proveedor de identidad", utilizando OpenID u otra autenticación enfoques.

5
nealmcb

Quizás ADFSv2 (una descarga gratuita para Windows 2008R2) lo ayudará con la cookie de dominio común. Aquí hay un extracto de web.config ubicado en C:\inetpub\adfs\ls que necesitará configurar para lograr el efecto deseado.

  <!--
    Common domain cookie. A common domain cookie stores a list of recently visited Claims Providers 
    (also called Identity Providers), as described in Section 4.3.1 of Profiles for the OASIS Security 
    Assertion Markup Language (SAML) V2.0. It is recommended that you enable common domain cookies by 
    including the <commonDomainCookie> element in the web.config file.

      1.The writer attribute of the <commonDomainCookie> element specifies the address of the writer 
      service that a Claims Provider uses to set the common domain cookie once it has authenticated a user.
      This address should be a valid URL.
      2.The reader attribute of the the <commonDomainCookie> element specifies the address of the reader
      service that a claims-aware service (also called a Service Provider) uses to get the list of Claims
      Providers that it should present to the user. This address should be a valid URL.

      The following configuration enables the use of common domain cookies and specifies writer and reader 
      services as described previously. 

      A common Domain Cookie is named "_saml_idp" in 4.3.1 http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
      Space delimited URI encoded

      RULES:
      Must be secure
      Must have path = /
      Must be leading period as in .domain.com 
      Can be session or persistant
      All providers should be configured similarly
      TODO-->
    <commonDomainCookie writer="" reader="" />
2
goodguys_activate

Muchas buenas respuestas aquí.
Estas son algunas buenas soluciones:

  • OpenId
  • OAuth
  • SAML
  • ADFS
  • Almacenamiento local

Aunque no creo que ninguno de estos sea realmente trivial de implementar, sin aprender un poco más sobre ellos.

Mejor aún estaría implementando un producto web-SSO adecuado, aunque parece de su pregunta que esa no es una opción (aunque le insto a que reconsidere e intente convencer a sus superiores).

Una solución bastante simplista que he visto, y de hecho, algunos productos web-SSO también usan este truco (tenga en cuenta que no necesariamente recomiendo este enfoque en todas las situaciones, ver a continuación):
Tenga un tercer dominio de "autenticación" que emite una "cookie de identidad" (después de autenticar al usuario). Los sitios web en otros dominios pueden enviar una solicitud simple POST) al dominio de autenticación, que por supuesto incluirá la cookie del usuario para ese dominio . La respuesta devuelta básicamente le dirá al dominio original, si el usuario está autenticado y, si es necesario, cuál es su identidad.
Si el usuario aún no está autenticado, será redirigido a una página en el dominio de autenticación para enviar su contraseña, etc.

Si bien esto es bastante simple de configurar, tenga en cuenta que existen algunos desafíos para que sea realmente seguro.
Por ejemplo, como se define, any sitio web puede recuperar su identidad. Además, el sitio web de confianza puede ser "engañado" modificando la respuesta devuelta.
Por supuesto, la forma más directa de resolver estos problemas es, lo adivinó, SAML/OpenId/etc.

1
AviD

Me acabo de registrar, pero me sorprende que no hayas encontrado una respuesta en otro lado. Como ya has descubierto, no puedes pasar tokens de autenticación sustitutos usando cookies.

No ha proporcionado ningún detalle sobre cómo se implementa la autenticación para su sitio actual ni las herramientas que tiene disponibles para programar los sitios. Pero supondré que el mecanismo de autenticación está escrito en un idioma que se ejecuta en el servidor web y utiliza una cookie para realizar un seguimiento de la sesión.

En ese caso, ya tiene código en cada url que requiere autenticación para verificar si la sesión se ha autenticado y luego tomar las medidas apropiadas, ya sea actuando la solicitud o redirigiendo a una página de inicio de sesión. Todo lo que necesita hacer es lidiar con el escenario donde no hay una sesión autenticada y hay una variable encriptada que se pasa en la URL (es decir, como GET). Descifra el valor, verifica su validez y crea una sesión en este punto. Luego, en su página de inicio de sesión, después de un inicio de sesión exitoso, redirige, agregando el par clave/valor apropiado a la URL.

Esa es una breve descripción general: hay algunos ajustes en los que debe pensar (por ejemplo, si desea compartir los mismos datos de sesión en todos los sitios, desea volver a vincular la sesión para diferentes sesiones para asegurarse de que no caduque en el lado del servidor) y también debe pensar en cómo evitar los ataques de repetición (por ejemplo, incluir un TTL en la carga útil cifrada, incluido un desafío generado aleatoriamente, pero tenga cuidado de usar la dirección IP del cliente).

Dado que solo está encriptando/desencriptando del lado del servidor, el cifrado simétrico es adecuado.

0
symcbean