Page Comparison

...

La funcionalidad de Single sign-on (login único) en las herramientas web de IdeaSoft se realiza mediante CAS.

Esta funcionalidad está habilitada por defecto como una válvula del Tomcat que ejecuta dentro del JBoss y que se encarga de interceptar el login y administrarlo correctamente a través de CAS.

Se encuentra definida en el archivo <O3>/jboss/server/default/deploy/jbossweb-tomcat55.sar/server.xml:

<!-- CAS SSO -->
<Valve className="com.ideasoft.sso.cas.tomcat.CASSingleSignOnValve"
    debug="0"
    filteredApps="/o3process,/o3portal,/o3planner,/liferay"/>

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:

• Se decidió utilizar un mecanismo de SSO basado en tickets.
• El ticket sería generado por la aplicación de Zonamerica y almacenado en una base de datos, 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 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)

El funcionamiento sería el siguiente:

1. El usuario ingresa a la aplicación de Zonamerica, en ese momento 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á quien elimine de la bse de datos el ticket inmediatamente después de ser validado el usuario

Base de datos

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

Expiración

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 (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.

Características que debería cumplir el ticket

El ticket puede ser cualquier texto pero es recomendable:

• que sea único, en general se utiliza la hora de la máquina como uno de sus componentes para garantizar esa unicidad
• que no sea fácil de generar, por ejemplo que no sea un número secuencial, que permitiría "adivinar" un valor válido

Un ejemplo de una clase Java que puede ayudar a esta implementación es java.rmi.server.UID

Configuración de SSO según la propuesta planteada.

Se debe de configurar una válvula que es la encargada de correr la lógica de verificación del ticket.
Para esto se debe de tener en cuenta los siguientes puntos:

• El siguiente código se agrega en el archivo jboss\server\default\deploy\jbossweb-tomcat55.sar\server.xml (ponerlo bajo el ejemplo de CAS SSO).

...

<Valve className="com.ideasoft.sso.cas.tomcat.DBSingleSignOnValve" debug="0" filteredApps="/o3portal" httpRedirect="http://www.ideasoft.biz" httpRedirectError="http://www.ideasoft.biz" dsName="java:/SSODS" expirationSeconds="86400" tableName="SSO_TICKETS">
</Valve>

• Se debe de sustituir el jar jboss\server\default\deploy\jbossweb-tomcat55.sar\is_sso_tomcat.jar por el adjunto.

• Ejemplo dataSource para una base Hypersonic (jboss\server\default\deploy\gserver\zonaamerica-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>

   En caso de que se trate de otra Base de Datos se debe de copiar el jar del driver en O3/jboss/server/default/lib y configurar el datasource con la url, driverClass, usuario y password adecuados.

• Script de creación de la tabla para Hypersonic.

create table SSO_TICKETS(Ticket Varchar(100) NOT NULL, Ticket_TS TIMESTAMP NOT NULL, UserName Varchar(50) NOT NULL, CONSTRAINT PK_SSO_TICKETS PRIMARY KEY(Ticket))

Problemas con CAS ejecutando detrás de un firewall

Cuando se utiliza O3 Portal detrás de un firewall puede ocurrir que luego de la pantalla de login aparezca una pantalla en blanco, esto es causado por un problema en el módulo de validación de CAS, que ocurre cuando el servidor no se puede conectar a si mismo con el nombre de host ingresado por el usuario en la URL del navegador.
Es decir que esto ocurre si el usuario accede a 'http://www.company.com/o3portal' y el servidor O3 no puede acceder al host www.company.com en el puerto 80.

Este problema se resuelve cambiando la declaración de la válvula de Tomcat por:

<!-- CAS SSO -->
<Valve className="com.ideasoft.sso.cas.tomcat.CASSingleSignOnValve"
    debug="0"
    casValidate="http://localhost:8080/cas/proxyValidate"
    filteredApps="/o3process,/o3portal,/o3planner,/liferay"/>

donde 8080 debe ser reemplazado por el puerto en el que está ejecutando Tomcat.entre los diferentes módulos web de O3 (O3Portal, EPortal, Report) se realiza mediante CAS.

Secciones