...
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:
| Code Block |
|---|
<!-- CAS SSO -->
<Valve className="com.ideasoft.sso.cas.tomcat.CASSingleSignOnValve"
debug="0"
filteredApps="/o3process,/o3portal,/o3planner,/liferay"/>
|
Propuesta para SSO entre una aplicación web existente y O3 utilizando mecanismo de ticket
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 debe ser generado por la aplicación en la que se loguea el usuario 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 deben estar definidos en los dos sistemas (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?:
- El usuario ingresa a la aplicación X, y en 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).
- Cuando la aplicación genera un link al O3Portal, éste llevaría el ticket como argumento de la URL
- O3 recibe el ticket y consulta la base de datos, para validar el ticket y obtener el nombre del usuario conectado
- O3 es quien elimine de la base de datos el ticket inmediatamente después de ser validado el usuario.
Base de datos
Debe existir una tabla llamada SSO_TICKETS con los siguientes campos:
Campo | Tipo | Descripción |
|---|---|---|
Ticket | Varchar(100) | |
Ticket_TS | Timestamp | Fecha y hora de creación del ticket |
UserName | Varchar(50) | Login del usuario conectado |
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 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
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>
Nombre de atributo | Descripción |
|---|---|
dsName | es el jndi-name definido en el archivo de configuración del data source (java:/"jndi-name definido en el datasource"). |
expirationSeconds | son los segundos en que va a tener validez un ticket que se encuentre en la base (por defecto toma 24 horas). |
httpRedirect | es usado para redirecionar en caso de que no se encuentre el ticket. |
httpRedirectError | es usado para redirecionar en caso de que el ticket no valide en la DB ya sea por expiración del ticket o porque este no exista. |
tableName | es el nombre de la tabla donde se guarda el ticket. Por defecto toma "SSO_TICKETS" |
- 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\appX-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.
...
entre los diferentes módulos web de O3 (O3Portal, EPortal, Report) se realiza mediante CAS.
Secciones
| Panel | ||||||
|---|---|---|---|---|---|---|
| ||||||
|