2008-12-06 10 views

Respuesta

0

Puede utilizar un producto de código abierto existente, CAS y simplemente impleméntelo en lugar de desarrollar el suyo. De esta forma, podrá integrarse con otras aplicaciones que admitan el mismo protocolo. Incluso si decide implementar el suyo propio en lugar de usar su código, hay muchas ideas presentadas en el sitio web que podrían serle útiles.

0

Si las aplicaciones están alojadas en el mismo servidor, entonces puede configurarlo para usar el inicio de sesión único. Por ejemplo, en Tomcat esto se logra con un Valve.

Si las aplicaciones se encuentran en entornos diferentes, entonces un servicio web seguro es una buena idea. Por ejemplo, podría crear un par de claves públicas y privadas y tener una aplicación de autentificación de la aplicación b (servidor) a (cliente) en el certificado del cliente. Esto significa que la aplicación a firma todas las solicitudes a la aplicación b con el certificado del cliente. Se necesitan más detalles sobre la arquitectura para una solución completa.

0

¿Está utilizando un servidor de aplicaciones? ¿Cuál es el ambiente para sus aplicaciones?

Hay un estándar para propagar identidad utilizando servicios web llamado Web Service Security UsernameToken Profile. Aquí hay una rápida overview. Puede enviar un nombre de usuario/contraseña o varios tokens, como un certificado X.509 o una aserción SAML. Algunas pilas de servicios web de servidores de aplicaciones manejarán WSS UsernameToken Profile, JBoss, Websphere y WebLogic. De lo contrario, el código del servicio web debe manejarlo. Este enfoque puede ser demasiado engorroso dependiendo de su entorno.

Hay un estándar para el inicio de sesión único, llamado SAML. Nuevamente, esto puede ser demasiado pesado para su caso de uso.

0

En tierra de Oracle, sé que existe el concepto de una aplicación confiable. Básicamente, si tiene el control de ambas aplicaciones, puede configurarlo de la siguiente manera:

La Aplicación A envía la Aplicación B, 1) el nombre de usuario y la contraseña de la Aplicación A y 2) el nombre de usuario actual. Como B conoce y confía en la Aplicación A, no necesita verificar las credenciales del usuario, ya que sabe que la aplicación A ya lo hizo por ella.

Supongo que si tiene una aplicación personalizada B, es posible que pueda hacer algo como esto. Si su implementación de SSO es compatible con esto, probablemente no tenga que hacer mucho, excepto diseñar sus servicios web.

buena suerte

3

Suponiendo que estos son aplicaciones web - debe implementar algún tipo de modelo de confianza compartida entre las aplicaciones.

Bajo ninguna circunstancia debes escribir el tuyo. Eso es demasiado fácil de arruinar y hay muchos existentes (tanto abiertos como comerciales) para elegir.

1 Estas son las siguientes opciones: 1 - Si todo el mundo está ejecutando Windows, puede usar Windows Native Authentication (también conocido como SPNEGO) 2 - Puede implementar algún tipo de sistema SSO.Los sistemas populares son CAS, Oracle Access Manager, CA SiteMinder, Sun SSO e IBM Tivoli Access Manager. Si bien CAS es de código abierto, los otros también le permitirán implementar la autorización, mientras que CAS solo realiza la autenticación.

Finalmente, asegúrese de elegir la opción que elija, que se integra con la autenticación nativa de su idioma & marco de autorización. En Java esto sería JAAS. En .NET sería el marco de seguridad .NET. Para PHP/Perl, puede aprovechar los módulos de Apache. El beneficio es que no tiene que convertirse en un experto en seguridad y facilitará el uso de sistemas externos para la autenticación de autenticación & sin tener que volver a codificar su aplicación.

2

Puede usar un esquema de autenticación de clave pública.

Crear un par de llaves con una clave pública y privada (utilizando la herramienta de claves de Java, GNU GPG o una herramienta similar). Utilice la clave privada para firmar una información (por ejemplo, un nombre de usuario) en la aplicación A y cree un enlace a la aplicación B a la que se pueda acceder desde la aplicación A y que contenga los datos firmados. La aplicación B puede iniciar sesión en el usuario después de verificar con la clave pública que la solicitud proviene de la aplicación A (que debe tener si es capaz de descifrar la cadena).

Por supuesto, puede crear un par de llaves opuestas para navegar en la otra dirección, o puede simplemente usar la clave pública y mantenerla en secreto (convirtiéndola en un sistema secreto compartido).

Si el usuario intenta acceder directamente a la aplicación B, también puede redirigirlo a la aplicación A con un parámetro que dice que proviene de la aplicación B (o hacer una comprobación de referencia). Si ya inició sesión en la aplicación A, crea el enlace con los datos firmados y redirigir a ella, de lo contrario, preséntalo con una pantalla de inicio de sesión y redirigir después del inicio de sesión.

Espero que ayude!

Cuestiones relacionadas