SSO multiplataforma: ¿por dónde empezar?

Question

Estoy investigando opciones para el inicio de sesión único entre dos sistemas dispares: uno .NET, un Java EE. Cada uno de ellos se gestiona de forma independiente y tiene una administración de usuarios separada, con algunos usuarios que se superponen.

Me gustaría poder hacer un enlace de uno a otro sin tener que volver a solicitar la contraseña.

Parece que hay muchas opciones para productos y protocolos SSO. Estoy bastante seguro de que podría codificar una única vez para generar y validar mis propios tokens de seguridad, pero preferiría no volver a inventar la rueda.

¿Qué recomendaría, en términos de enfoque y/o producto (preferiblemente de código abierto)?

Primero, ¿podría ir con algo que admita SAML, OpenID, OAuth o ninguno de los anteriores?

En segundo lugar, de los productos gratuitos/de código abierto, conozco OpenAM, Shibboleth, JOSSO y CAS. ¿Alguna experiencia para compartir con cualquiera de ellos, buena, mala o fea?

Answer 1

En primer lugar deja mirada en los protocolos:

1. SAML 2.0 es un protocolo centralizada/descentralizada SSO. Es el protocolo avanzado más y ofrece federación, es decir, usted puede permitir a los usuarios iniciar sesión utilizando cualquiera de los sistemas X, o canalizar a todos los usuarios a través de un único sistema (conocido como IDP). SAML 2.0 se usa ampliamente en los sectores financiero y gubernamental junto con algunas aplicaciones hospedadas (aplicaciones de Google y Saleforce por ejemplo). También es la más compleja protocolo

2. OpenID es un protocolo descentralizado y más se adapte a Internet, aplicaciones no intranet/extranet. Los usuarios pueden optar por iniciar sesión desde a cualquier proveedor OpenId. Stackoverflow es un buen ejemplo de OpenId: nosotros podemos optar por iniciar sesión con nuestra cuenta de Google o Facebook. Puede implementar OpenId de forma centralizada al forzar una asociación predeterminada entre la aplicación consumidora (conocida como Parte dependiente ) y el sistema SSO (conocido como Proveedor de servicios).

3. OAuth no es realmente un protocolo SSO. Permite a un usuario otorgar Aplicación A acceder a su información en la Aplicación B sin proporcionando las credenciales para la Aplicación B a la Aplicación A. Algunas personas han usado OAuth como una forma de pseudo autenticación, es decir, si el sistema puede acceder a las fotos que pertenece al usuario X, entonces el usuario debe ser X. Es un truco y no se recomienda.

En definitiva, es una buena idea ir con un protocolo estandarizado para evitar bloqueo en. Microsoft recientemente ha introducido soporte para SAML 2.0 y hay muchos de código abierto y los productos comerciales disponibles para Java. Hay implementaciones de OpenId disponibles para Java, pero no sé lo suficiente sobre el mundo .NET para comentar.

Como mencionó, hay una gama de productos de código abierto SAML disponibles (OpenAM, Shibboleth, JOSSO y CAS).Una nota de precaución: SAML es un protocolo complejo, por lo que si va por la ruta de código abierto deberá estar preparado para un trabajo arduo. Cuando construimos nuestra plataforma SSO Cloudseal (basada en SAML 2.0) pasamos mucho tiempo tratando de simplificar las cosas para abstraer la complejidad. Otros proveedores comerciales han hecho lo mismo, pero los productos de código abierto que ha mencionado están más centrados en la funcionalidad que en la simplicidad. ¡En mi humilde opinión! :)