java soa glassfish-3 opensso openam

java - Alternativas OpenSSO/OpenAM



soa glassfish-3 (7)

¡Advertencia! Estoy en un viaje de pesca aquí, y ni siquiera estoy seguro de si las preguntas que hago tienen sentido. ¡Se amable con tus respuestas! :)

Hace poco asumí un proyecto que actualmente está basado en Java + Linux + Tomcat + MySQL. En este momento, el sistema es básicamente solo un sitio web con algunos trabajos cron en el fondo para mover algunos datos, etc. Al trabajar con el gerente de producto para desarrollar una cartera de pedidos priorizada, está claro por lo que quiere hacer que yo necesito comenzar a desarrollar una arquitectura orientada a servicios (SOA <- ¡advertencia de palabra de advertencia!), y terminaré con una combinación de servidores web y servidores de aplicaciones. Nota: estoy considerando mudarme a Glassfish v3.

Actualmente, la autenticación y las autorizaciones se manejan en código Java y la información del usuario se almacena en la base de datos MySQL. Como mínimo, me parece que tendré que dividir esto en un servicio de autenticación por separado (de lo contrario, terminaré con un montón de código duplicado por todas partes para manejar la autenticación de usuario y las autorizaciones).

He estado buscando soluciones de inicio de sesión único (SSO) y haciendo algunas investigaciones. Según lo que puedo deducir, OpenSSO ha sido eliminado oficialmente por Oracle, pero recogido por ForgeRock y ahora se llama OpenAM. Esto parece estar muy cerca de lo que quiero, pero como ya tengo un sistema basado en MySQL, preferiría tener algo que lo soporte (o algún otro tipo de RDBMS). Encontré esto en Stack Overflow y parece indicar que es básicamente LDAP o nada.

¿Hay alguna manera de hacer que OpenSSO / OpenAM hablen con la base de datos para su autenticación y autorización?

Mis preguntas son:

¿Qué otras opciones hay para OpenSSO / OpenAM? ¿LDAP es el camino a seguir? Nota: hacer una búsqueda de "OpenAM vs" en Google no rinde mucho. ¿Las personas tienden a simplemente "rodar las suyas"?

Cualquier pensamiento / sugerencia / enlace sobre este tema que ayudará a educarme será muy apreciado. Gracias de antemano por su paciencia y ayuda.

¿Está integrando aplicaciones existentes, o solo quiere apoyar sus propias aplicaciones?

¿Estás buscando un SSO real o simplemente credenciales compartidas? SSO inicia sesión en una sola aplicación y se propaga a otra aplicación (como iniciar sesión en Gmail y iniciar sesión automáticamente en Blogger). La credencial compartida es que puede usar el mismo nombre de usuario y contraseña en todas las aplicaciones, pero la credencial en sí misma no se propaga automáticamente.

LDAP es un sistema común utilizado para administrar una credencial compartida. Muchos sistemas le permiten apuntar su tienda de autenticación a un servidor LDAP existente.

Por ejemplo, si tiene varias aplicaciones implementadas en un contenedor Java EE, y también, por ejemplo, un servidor de correo electrónico y un cliente de correo electrónico basado en web, todas estas diversas aplicaciones podrían apuntar al mismo servidor LDAP y sus usuarios tendrían un solo inicio de sesión y contraseña para todos los diferentes sistemas, todos escritos en diferentes idiomas, todos desplegados en diferentes máquinas. Este es un caso de uso de LDAP pan y mantequilla, y casi todos los sistemas pueden manejar esto de la caja. Glassfish y Tomcat pueden validar fácilmente contra un servidor LDAP. También lo pueden hacer Apache (servidor web), Postgres (base de datos), Postfix (correo electrónico), etc., etc.

Entonces, si simplemente quiere una credencial compartida, la obtiene "gratis", ahora mismo, instalando un servidor LDAP. LDAP es una bestia diferente a algo así como un DBMS, pero una vez que lo estudias un poco y lo "entiendes", es bastante agradable. OpenLDAP es un popular servidor LDAP, pero soy parcial de ApacheDS.

La forma de configurarlo en un contenedor Java EE es configurar un "Reino". GF y Tomcat tienen reinos LDAP listos para usar, me imagino que el resto sí. Pero la clave es que necesitas usar seguridad Java EE para aprovechar el Reino.

Ver, el detalle con un Reino Java EE es que es un aspecto del CONTENEDOR, no de la aplicación. Al igual que un grupo de conexiones, es un recurso contenedor que aprovecha su aplicación. La mayoría de las personas quiere que la seguridad sea parte de su aplicación, donde sienten que tienen más control sobre ella.

Eso está muy bien hasta que empiece a recibir un montón de aplicaciones diferentes y todos estén configurados de manera diferente y tengan listas de usuarios y políticas de contraseñas por separado, etc., etc.

LDAP puede arreglar mucho de eso, ya que los configura a todos para usar el mismo almacén de credenciales.

The Realm completa esa necesidad en un servidor Java EE. Su aplicación está configurada para usar un Reino provisto por el contenedor. Si tiene varias aplicaciones y un solo Reino, todos podrán compartir las credenciales dentro de ese Reino (independientemente del tipo de Reino).

Los dominios pueden ser cualquier cosa: basados ​​en archivos, basados ​​en bases de datos, LDAP, etc. Los dominios también se agrupan si el contenedor se agrupa (lo que puede ser útil).

El lado oscuro de la seguridad de Java EE, y por qué la mayoría de las aplicaciones lo evitan es que, una vez más, el Reino es parte del contenedor, y no de la aplicación, puede ser un poco desagradable de usar, y quizás no ofrecer las características que como en términos de administración de usuarios, políticas de contraseñas, etc.

Pero el lado positivo de la seguridad de Java EE es que una vez que está bajo su paraguas, puede aprovechar la credencial en todo su código fácilmente. Una persona inicia sesión en el sitio web, y esa credencial se puede usar allí en la aplicación web, o propagarse automáticamente al nivel EJB (siempre un nivel EJB remoto), y la información siempre es útil.

Puede apuntar sus aplicaciones web a un reino, EJB, sus servicios web. Todos aprovechan las mismas piezas.

Para obtener lo mejor de ambos mundos es aprovechar los mecanismos específicos del contenedor para acceder a la seguridad de los contenedores. Este es el otro lado oscuro de la seguridad de Java EE.

Cosas como Realms y el acceso directo a la seguridad del contenedor no son portátiles en todos los contenedores. GF lo hace diferente de lo que Tomcat lo hace diferente de WebLogic. Todo está muy cerca, pero difiere en los detalles, por lo que su código no se transporta a la perfección.

El lado positivo es para aplicaciones internas, la mayoría de las personas simplemente aprovechan el contenedor que tienen, ponen una abstracción razonable alrededor del código dependiente del contenedor y lo llaman día, señalando que sí, tendrán que portar esto si y cuando se muevan a un diferente envase. Pero, en la práctica. al igual que una base de datos, una vez que se elige una plataforma de contenedores, la gente tiende a acurrucarse y atenerse a ella.

Finalmente, Servlet 3.0 (en GF3 y Tomcat 7) estandariza más de los problemas de inicio de sesión programáticos para hacerlos más portátiles en todos los contenedores, pero los conceptos subyacentes son los mismos.

Ahora, SSO.

SSO es una bestia diferente. Pero, fuera de la puerta, tanto GF como Tomcat admiten SSO para aplicaciones web. Esto le permite iniciar sesión en una aplicación web y tener acceso fácil a otras personas sin tener que iniciar sesión en ellas. Pero el SSO es un poco limitado ya que se basa más en la seguridad del contenedor y su ciclo de vida, que en uno más flexible bajo el control de la aplicación. Tenga en cuenta, no solo en los Reinos (eso es algo dado), sino en el inicio de sesión de formulario basado en contenedor real, en lugar de un inicio de sesión programático personalizado. El inicio de sesión FORM no es espectacular, pero es funcional y funciona. Implemente un Reino, implemente sus aplicaciones en una sola instancia de Tomcat o GF (o un clúster en GF 3.1), y obtenga SSO gratis, de modo que si eso es importante, es realmente agradable. Su usabilidad está bien para aplicaciones de back office, pero quizás no para Internet pública.

Si desea una solución SSO más sofisticada, entonces necesita ver implementaciones personalizadas. OpenSSO es uno de esos, y se basa en SAML y el perfil web de SAML. Sin embargo, hay otros. También hay CAS, Atlassian Cloud, Kerberos y OAuth. Todos usan protocolos diferentes a SAML. Si desea seguir con SAML, también puede mirar Shibboleth, o incluso SimpleSAML (SimpleSAML es un servidor PHP que actúa como Proveedor de Identidad SAML, entre otras cosas, pero aún necesita un Proveedor de Servicios dentro de sus aplicaciones).

Cualquiera que sea el protocolo que elija, el proceso es básicamente el mismo (se detalla aquí - Inicio de sesión de dominios cruzados - Cómo iniciar sesión automáticamente cuando se transfiere de un dominio a otro ).

Pero el diablo está en los detalles. Y, chico, ¿hay demonios?

Todos estos sistemas son complicados. SSO es complicado. Por ejemplo, ahora que tiene Single Sign On, ¿qué pasa con Single Sign Out? ¿Qué pasa con Single Time Out? ¿Qué sucede con los cambios de credenciales mientras los usuarios están conectados? ¿Qué tal un STS (Servicio de token seguro) para sus servicios web? (STS ofrece un mecanismo de autenticación delegado similar para servicios web).

SAML te introduce a un montón de nuevo vocabulario y mucha configuración. No se recoge fácilmente ya que la documentación no es estelar y se basa mucho en documentos estándar que hablan de un nivel más alto de cosas genéricas, y no para usted y su aplicación específicamente.

Si no necesita realmente SSO, probablemente se contente con algo así como una tienda LDAP central y continúe desde allí.

Todo lo dicho, por ejemplo, nuestras aplicaciones son compatibles con un backend DB y LDAP. Usan Glassfish y la seguridad de Java EE. Controlamos completamente la experiencia del usuario. También admitimos SSO a través de SAML (escribimos nuestros propios proveedores de identidad y servicios), y hemos compartido credenciales a través de LDAP y SSO en Java y otras aplicaciones, utilizando nuestro código y el código de un tercero. El lado positivo es que esto se basa en todos los estándares. El lado oscuro es que los estándares se comunican en inglés, y el inglés está sujeto a interpretación.

Digo esto simplemente para decir que se puede hacer. También escribí ad hoc, detrás de las implementaciones SSO de servilleta, tanto el mismo dominio como el dominio cruzado (el mismo dominio es simple con una cookie compartida) utilizando filtros de servlets simples. Las políticas de contraseñas, la recuperación de contraseñas, mantener los temporizadores vivos, el tiempo de espera de múltiples ventanas y la gestión de sesiones (eso es un puntazo), roles, privilegios, etc. He estado allí, hecho eso.

Además, sería negligente no mencionar a Spring and Spring Security, que ofrece todo esto además de Spring. No lo he usado (no soy una persona de Spring), pero esas personas sí saben lo que están haciendo, así que vale la pena mirarlo.

He creado con éxito un repositorio de usuarios personalizado para OpenAm. Dado que esta pregunta no ha estado activa por un tiempo y porque sería demasiado largo describir en detalle aquí cómo hacerlo, solo daré algunos consejos. Si necesita ayuda con detalles, no dude en preguntarme.

  • Su punto de entrada básico necesita extender com.sun.identity.idm.IdRepo.
  • Debe registrar su repositorio personalizado utilizando ssoadm.jsp? Cmd = add-sub-schema.

A partir de este punto, su tipo de repositorio se incluirá entre los otros tipos cuando cree un almacén de datos para un reino.

Buena suerte !

OpenAM tiene dos tiendas separadas, una tienda de usuario, donde se almacenan los usuarios y todas las propiedades que la acompañan y una tienda de configuración, que contiene la configuración. Hay una User Store de base de datos, que está disponible en OpenAM sin embargo, nunca lo he probado. La pregunta de SO a la que usted estaba apuntando se refería principalmente a la tienda de configuración, que aunque solo está integrada en LDAP, está integrada en OpenAM (por lo que no requiere administración directa).

Personalmente, soy un fanático de Tomcat sobre Glassfish, ya que es un contenedor Servlet rápido y ligero, sin todo el hinchamiento asociado que va con un contenedor J2EE completo.

Puede usar OpenAm con RDBM. Estoy usando la tienda de usuarios basada en JBDC en OpenAm

Tenga en cuenta que " ¿Hay alguna manera de hacer que OpenSSO / OpenAM hable con la base de datos para su autenticación y autorización? " Está redactado incorrectamente. Los detalles de la pregunta y las respuestas solo se refieren al aspecto de autorización . OpenAM funciona muy bien con una base de datos MySQL de usuarios y contraseñas ( autenticación ), y puede usar su servidor LDAP oculto / incrustado para almacenar políticas y otras configuraciones.

Parece que todavía necesita desarrollar su modelo de seguridad, pero es probable que no necesite algo como OpenAM y que solo pueda usar la seguridad provista por contenedor / framework.