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

La forma en que se ha implementado el inicio de sesión único para la Stack Exchange Network es muy interesante. Hace uso de HTML 5 Local Storage . Dependiendo de la compatibilidad del navegador que necesite, tal vez pueda utilizar un método similar.

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

No es necesario utilizar un servicio externo para OpenId. Puede 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 realizado para hacer que OpenId sea seguro.

PS: OpenId se puede usar para tener una identidad única utilizada por muchos sitios, pero todavía tiene que iniciar sesión "manualmente" en cada dominio.

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 otros métodos de autenticación.

Quizás ADFSv2 (una descarga gratuita para Windows 2008R2) te ayudará con la cookie de dominio común. Aquí hay un extracto de web.config ubicado en C:\inetpub\adfs\ls que deberá 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="" />

Muchas respuestas buenas 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 que no es una opción (aunque le insto a que lo reconsidere y trate de 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, consulte a continuación):
Tener un tercer dominio de "autenticación" que emita una "cookie de identidad" (después de autenticar al usuario). Los sitios web en otros dominios pueden enviar una solicitud POST simple al dominio de autenticación, que por supuesto incluirá la cookie del usuario para ese dominio . La respuesta devuelta básicamente indicaría el 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 es bastante sencillo de configurar, tenga en cuenta que existen algunos desafíos para hacerlo realmente seguro.
Por ejemplo, como se define, cualquier sitio web puede recuperar su identidad. Además, el sitio web de confianza se puede "engañar" modificando la respuesta devuelta.
Por supuesto, la forma más sencilla de resolver estos problemas es, lo has adivinado, SAML / OpenId / etc.

Me acabo de registrar, pero es sorprendente que no hayas encontrado una respuesta en ningún otro lugar. Como ya descubrió, no puede pasar tokens de autenticación sustitutos mediante 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 la programación de los sitios. Pero supongo 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 tienes un código en cada url que requiere autenticación para verificar si la sesión ha sido autenticada y luego toma la acción apropiada, 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 se pasa una variable cifrada en la URL (es decir, como un GET). Descifras el valor, verificas su validez y creas 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.

Esta es una breve descripción general: hay algunos ajustes en los que debe pensar (por ejemplo, ¿desea que se compartan los mismos datos de sesión en todos los sitios? (lado) y también debe pensar en cómo evitar los ataques de reproducción (por ejemplo, incluir un TTL en la carga útil cifrada, incluido un desafío generado aleatoriamente, pero tenga cuidado con el uso de la dirección IP del cliente).

Ya que solo está cifrando / descifrando el lado del servidor, el cifrado simétrico es adecuado.