Page Comparison

...

Propuesta para Single Sign On enter una aplcación web existente y O3 utilizando mecanismo de tickets

En una conferencia telefónica se realizaron las siguientes definiciones:

...

Este es un ejemplo de cómo se puede implementar el macanismo de SSO para evitar el doble login en o3portal, considerando que el usuario ya se encuentra loqueado en otra aplicación (aplicación X, de ahora en más). Características de la implementación:

• Se utiliza un mecanismo de SSO basado en tickets.
• El ticket sería debe ser generado por la aplicación de Zonamerica en la que se loguea el usuario y almacenado en una base de datos, el . El único requerimiento de dicha base de datos es que sea accesible por el servidor O3 a través de un driver JDBC.
• Los usuarios se mantendrían deben estar definidos en los dos sistemas , sincronizados manualmente, queda para una segunda etapa la evaluación de una posible integración del repositorio de usuarios (a través de LDAP o algún otro mecanismo)

...

• (en la aplicación X y en O3). Dependiendo del respositorio de usuarios que la aplicación X proveea, se podrá integrar a O3 (por ejemplo LDAP), evitando tener que mantener la doble definición de usuarios.

Cómo funciona este mecanismo de SSO ?:

1. El usuario ingresa a la aplicación de ZonamericaX, y en ese el momento que desea acceder al O3Portal se genera el ticket y se almacena en la base de datos (más adelante se propone el esquema de la tabla a utilizar). Propuesta modificada: el ticket se genera recién al momento que el usuario ingresa al o3portal.
2. Cuando la aplicación genera un link al O3Portal, éste llevaría el ticket como argumento de la URL
3. O3 recibe el ticket y consulta la base de datos, para validar el ticket y obtener el nombre del usuario conectado
4. El sistema de Zonamerica es responsable de eliminar de la base de datos el ticket asociado a una sesión cuando ésta es cerrada (ya sea explícitamente por el usuario o por una expiración) Propuesta modificada: O3 será O3 es quien elimine de la bse base de datos el ticket inmediatamente después de ser validado el usuario.

Base de datos

Se propone la existencia de Debe existir una tabla llamada SSO_TICKETS con los siguientes campos:

...

Se propone utilizar el campo Ticket_TS para la validación del Ticket, es decir cuando O3 valida el Ticket además de verificar que existe un registro en la tabla, se aseguraría de que el tiempo de vida no sea mayor a un parámetro que se defina (valor predeterminado, por ejemplo un día). Esto sería para evitar que si no se eliminó correctamente un ticket no permita el ingreso por tiempo indeterminado. El valor del tiempo expiración se debe definir a través de un parámetro.

Características que debería cumplir el ticket

...

• Ejemplo dataSource para una base Hypersonic (jboss\server\default\deploy\gserver\zonaamericaappX-hsql-ds.xml).

<?xml version="1.0" encoding="UTF-8"?>

<!-- ==================================================================== -->
<!--  Datasource config for Hypersonic SQL                                -->
<!-- ==================================================================== -->


<datasources>
	<local-tx-datasource>
		<jndi-name>SSODS</jndi-name>
		<connection-url>jdbc:hsqldb:hsql://localhost:1701</connection-url>
		<driver-class>org.hsqldb.jdbcDriver</driver-class>
		<user-name>sa</user-name>
		<password/>
		<!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
		<metadata>
			<type-mapping>Hypersonic SQL</type-mapping>
		</metadata>
	</local-tx-datasource>
</datasources>

...