único sso sesión inicio example basado spring-security single-sign-on saml-2.0 shibboleth spring-saml

spring-security - example - inicio de sesión único basado en saml sso



Inicio de sesión único en Spring utilizando la extensión SAML y Shibboleth (1)

Me gustaría implementar una capa de autenticación de inicio de sesión único (SSO) en mi aplicación basada en Spring con el objetivo de admitir la autenticación y la autorización de diferentes dominios de seguridad. He elegido a Shibboleth como IdP, pero todavía tengo que identificar qué usaré para el SP.

Las opciones son:

  • Spring Security SAML Extension: el componente permite que las aplicaciones nuevas y existentes actúen como proveedor de servicios en federaciones basadas en el protocolo SAML 2.0 y habiliten el inicio de sesión único en la web. Spring Security Extension permite una combinación perfecta de SAML 2.0 y otros mecanismos de autenticación y federación en una sola aplicación. Todos los productos que admiten SAML 2.0 en el modo Proveedor de identidad (por ejemplo, ADFS 2.0, Shibboleth, OpenAM / OpenSSO, RM5 IdM o Ping Federate) se pueden utilizar para conectarse con la extensión SAML de Spring Security.

  • Shibboleth ( también como SP ): Shibboleth es una tecnología basada en la web que implementa los perfiles HTTP / POST, artefacto y atributo push de SAML, incluidos los componentes Proveedor de identidad (IdP) y Proveedor de servicio (SP).

Entonces, tengo algunas preguntas:

  1. ¿Es una buena idea usar directamente Spring SAML como SP en términos de escalabilidad y mantenibilidad?
  2. ¿Es posible usar un SP externo junto con Spring Security? ¿Cómo debo configurar mi aplicación y / o mi servidor de aplicaciones (JBoss 8.0 - WildFly)?
  3. ¿Dónde defino los roles (para cada escenario)?
  4. ¿Cuál es la opción que vale la pena?

Saludos cordiales, V.


La principal diferencia entre los dos es el escenario de implementación:

  • Los complementos de Shibboleth SP se implementan directamente en el servidor web Apache / IIS.
  • Spring SAML está incrustado en su aplicación.

Ambos tienen pros y contras.

  1. ¿Es una buena idea usar directamente Spring SAML como SP en términos de escalabilidad y mantenibilidad?

Primavera SAML

  • Ofrece un gran control sobre cómo se realiza la autenticación y cómo el proceso de autenticación interactúa con su aplicación. Puede, por ejemplo, crear sus propias IU de configuración y agregar IDP dinámicamente, crear pantallas de inicio de sesión personalizadas como parte de su aplicación, tener un control completo y sencillo sobre el manejo de errores, admitir fácilmente múltiples IDPs, detalles dinámicamente configurados del SSO (AuthnContexts, IDs de nombre solicitados, enlaces) , forzamiento de autenticación).
  • Analice fácilmente los atributos SAML recibidos en varios formatos, admita múltiples métodos de autenticación en la misma aplicación.
  • Genera metadatos de SP dinámicamente, proporciona múltiples tenencias limitadas y admite perfiles que no están disponibles en todas las demás opciones (por ejemplo, cierre de sesión único, titular de clave, detección de IDP).
  • Interactúa a la perfección con Spring Security, que aporta un conjunto de beneficios propios. Con Spring SAML también puede configurar una completa política de autenticación y autorización directamente en su aplicación (por ejemplo, qué páginas requieren autenticación o no y cuándo, el control de acceso basado en roles al contenido, la autenticación en condiciones dinámicas, ...).
  • Le permite implementar la aplicación en cualquier servidor o contenedor de aplicaciones y detrás de cualquier servidor proxy o web inverso sin afectar la funcionalidad.

Plugins de shibboleth

  • Estos están configurados de forma estática y suelen interactuar con su aplicación a través de encabezados HTTP. Desacoplan la lógica de autenticación de la aplicación en sí, por lo que lo único que debe tener en cuenta es la aceptación de los encabezados y la inicialización de la sesión de la aplicación con el contexto de seguridad correcto. La definición de qué páginas están protegidas está presente en el servidor IIS / Apache y se basa en los patrones de URL, lo que significa que la política de autenticación y autorización se define en parte fuera de su aplicación.
  • Debe asegurarse de que solo se pueda acceder a la aplicación a través del servidor web (= prohibir todos los accesos directos) ya que esto permitiría forjar los encabezados.
  • No requiere muchos cambios en la aplicación en sí y, por lo tanto, se puede usar fácilmente con sistemas heredados.
  1. ¿Es posible usar un SP externo junto con Spring Security? ¿Cómo debo configurar mi aplicación y / o mi servidor de aplicaciones (JBoss 8.0 - WildFly)?

Sí, es posible, pero requerirá esfuerzo. Por ejemplo, podría configurar WildFly para configurar una cookie de dominio compartido en formato cifrado y verificar la cookie en su configuración de Spring Security.

  1. ¿Dónde defino los roles (para cada escenario)?

Con Spring SAML usted define roles al procesar la Respuesta SAML, por ejemplo, analizando los atributos SAML. Esto se hace implementando la interfaz SAMLUserDetailsService y conectándola al samlAuthenticationProvider .

Con Shibboleth puede reenviar atributos recibidos de IDP a su aplicación con encabezados y analizarlos en su aplicación.

WildFly (probablemente) le permite definir el contexto de seguridad y los roles directamente en SP sin necesidad de configurar esto en su aplicación. Dicha configuración podría no ser portátil entre servidores de aplicaciones.

  1. ¿Cuál es la opción que vale la pena?

Todas las opciones le permitirán realizar WebSSO con SAML 2.0. Las personas suelen elegir en función de sus requisitos (por ejemplo, necesidades de personalización), entorno (servidor web utilizado, servidor de aplicaciones), metodología de desarrollo preferida (Java, .NET, otros), marcos utilizados, código heredado. Muchos clientes utilizan los complementos Spring SAML y Shibboleth.