java - sso - saml google

Inicio de sesión único[SSO] en diferentes dominios utilizando Java (4)

Estamos implementando el inicio de sesión único [SSO] en varias aplicaciones, que están alojadas en diferentes dominios y diferentes servidores.

Ahora, como se muestra en la imagen, estamos introduciendo un servidor de autenticación que realmente interactúa con LDAP y autentica a los usuarios. Las aplicaciones que se utilizarán / hablarán con el servidor de autenticación se alojarán en diferentes servidores y dominios.

para SSO, no puedo usar variables de sesión, ya que hay diferentes servidores y diferentes aplicaciones, diferentes dominios, una variable de sesión / cookie de nivel de dominio no es útil.

Estoy buscando una mejor solución que pueda usarse para SSO a través de ellos. ¿Existe alguna implementación demostrada? Si es así, por favor publícalo o apúntame en la dirección correcta para esto.

La pregunta más importante es cómo está implementando el inicio de sesión único. Muchas ofertas de código abierto e incluso de propiedad (IBM Tivoli) que valen la pena, ofrecen su capacidad de inicio de sesión único en varios dominios. Esta sería la forma más fácil y mejor de implementar el dominio cruzado entre sí. Puede configurar el servidor LDAP que usa en el servidor sso que elija.

Tomando por ejemplo open sso, aquí hay un artículo para configurar el inicio de sesión único entre dominios en http://docs.oracle.com/cd/E19681-01/820-5816/aeabl/index.html

Para configurar LDAP en sso abierto, http://docs.oracle.com/cd/E19316-01/820-3886/ghtmw/index.html

La referencia sobre el problema se presenta en un diagrama ordenado aquí http://docs.oracle.com/cd/E19575-01/820-3746/gipjl/index.html

Dependiendo de la oferta que utilice, puede configurar el inicio de sesión único entre dominios.

Con esto, su diagrama se verá así, con el servidor de autenticación como su utilidad para interactuar con el servidor sso de su elección.

Tener un servidor de autenticación que se comunique con sso es un principio de arquitectura de sonido. Yo sugeriría hacer llamadas para autenticar como puntos finales REst que podrían llamarse a través de http desde diferentes aplicaciones.

No puedes usar el servicio de descanso.

Podría usar lo que yo llamo una Autenticación de URL de referencia. Supongamos que se está ejecutando una aplicación de autenticación en www.AAAA.com. En las aplicaciones donde desea autenticar, you could have a filter which looks for a authenticated cookie in its domain else redirect to www.AAAA.com for authentication

En la Successfull authentication , puede pass the user profile information as encrypted GET / POST data back to the application

Puede lograr esto haciendo que todos sus inicios de sesión se realicen en el servidor de autenticación. Las otras aplicaciones pueden comunicarse con el servidor de autenticación a través de un canal posterior. El principio general es así:

Usuario accede a la aplicación 1.
La aplicación 1 necesita que el usuario inicie sesión, por lo que envía un token al servidor de autenticación a través del canal posterior. La aplicación 1 luego redirige al usuario a la página de inicio de sesión en el servidor de autenticación con el token como parámetro en la solicitud.
El usuario inicia sesión en el servidor de autenticación. El servidor de autenticación establece una cookie, marca el token como autenticado y asocia los detalles del usuario con él. El servidor de autenticación luego redirige al usuario a la aplicación 1.
La aplicación 1 recibe la solicitud del usuario y llama al servidor de autenticación a través del canal posterior para verificar si el token está bien. Autenticar la respuesta del servidor con los detalles del usuario.
La aplicación 1 ahora sabe que el usuario está autorizado y tiene algunos detalles básicos del usuario.

Ahora aquí es donde entra el bit SSO:

Usuario accede a la aplicación 2.
La aplicación 2 necesita que el usuario inicie sesión, por lo que envía un token al servidor de autenticación a través del canal posterior. La aplicación 2 luego redirige al usuario a la página de inicio de sesión en el servidor de autenticación con el token como parámetro en la solicitud.
El servidor de autenticación ve que hay un registro válido en la cookie, por lo que puede indicar que el usuario ya está autenticado y sabe quiénes son. El servidor de autenticación marca el token como autenticado y asocia los detalles del usuario con él. El servidor de autenticación luego redirige al usuario a la aplicación 2.
La aplicación 2 recibe la solicitud del usuario y llama al servidor de autenticación a través del canal posterior para verificar si el token está bien. Autenticar la respuesta del servidor con los detalles del usuario.
La aplicación 2 ahora sabe que el usuario está autorizado y tiene algunos detalles básicos del usuario.

Hay algunas implementaciones existentes de este método, por ejemplo, CAS (Servicio de autenticación central). Tenga en cuenta que CAS es compatible con el sistema en Spring Security . Le aconsejaría que utilice una implementación existente, ya que escribir la suya será difícil. He simplificado las cosas en mi respuesta y hay muchas posibilidades de introducir agujeros de seguridad si eres nuevo en esto.

Te recomendaré que eches un vistazo a OAuth. Es un buen protocolo de autorización y autorización utilizado por varias grandes organizaciones, como facebook, google, windows live y otras. Puede tener una curva de aprendizaje inicial, pero es una solución de grado de producción.

También tiene bibliotecas para Java, Ruby, PHP y una variedad de otros lenguajes de programación.

Por ejemplo, las siguientes implementaciones del lado del servidor están disponibles para Java.

Ámbar Apache (proyecto 22)
Seguridad de primavera para OAuth
Servidor de Autorización Apis (v2-31)
Marco de Restlet (borrador 30)
Apache CXF

Las siguientes bibliotecas de Java del lado del cliente también están disponibles:

Ámbar Apache (proyecto 22)
Primavera social
Seguridad de primavera para OAuth
Marco de Restlet (borrador 30)

Por favor, consulte aquí para más detalles: