Studio SSON + Tivoli integration

Cloud Pass

Studio SSON + Tivoli integration

 Se ha habilitado una funcionalidad que permite parametrizar Axional para que acepte, sin requerir login/password, el acceso a usuarios que han introducido correctamente sus credenciales en otro servidor de validación.

La solución SSO instalada en el servidor de validación para este caso, es la suite de IBM Tivoli Access Manager que gracias a la utilidad webSEAL, un gestor de accesos, permite al servidor actuar como un proxy web inverso. Con este montaje, todo flujo de datos pasará por el servidor de validación.

Para que el sistema funcione y sea cerrado es muy importante que en el aplicativo final (Axional) todos los links sean relativos.

¿Cómo se accede a las aplicaciones?

Los usuarios que tratan de acceder a un recurso web protegido como Axional u otros aplicativos web, lo hacen mediante una URL que apunta al servidor de validación. Esta URL varía en función del aplicativo al que se quiere acceder, ya que para cada aplicación se define una URL base denominada Anclaje (Junction). A continuación vemos un ejemplo de dos anclajes creados en el servidor de validación websso-validation-server.com. El primero serviría para acceder a Axional y el segundo para acceder a otro aplicativo:

https://websso-validation-server.com/Axional/
https://websso-validation-server.com/OtherApp/

Si los usuarios no han introducido sus credenciales o éstas son inválidas, son redirigidos a un formulario en el que se les pide login y password.  Una vez introducidos y validados, el proxy reverse devuelve el recurso solicitado (determinado por el anclaje de la URL).

¿Cómo identifica Axional al usuario que conecta vía webSSO?

En la petición HTTP que hace el servidor de validación (vía proxy reverse) al aplicativo final (Axional), se envía un parámetro llamado iv-user en el encabezado HTTP. Este parámetro contiene el login del usuario que ha hecho la petición y sólo se envía si las credenciales del usuario han sido validadas.

El servidor de aplicaciones destino (Axional), recibe la petición HTTP y una válvula la intercepta para crear el Principal del usuario que recibimos e introducirlo en la sesión. A partir de este momento es como si el usuario se hubiese validado en Axional y la seguridad dependerá de Axional, es decir, si un usuario quiere acceder a una aplicación a la que no se le ha dado acceso, será la propia seguridad de Axional la que no le permitirá acceder (wic_dbms_usersdb).

¿Cómo activar esta funcionalidad en AXIONAL?

Se deben seguir las siguientes instrucciones:

1.- Verificar que tenemos el fichero AMTomcatValve.jar en el directorio /CATALINA_HOME/server/lib, que está disponible en las últimas distribuciones de Axional.

Dentro del jar, se puede acceder al código fuente de la válvula utilizada para gestionar los accesos.

2.- Activar la válvula AMTomcatValveAX, que interceptará las conexiones para verificar si el usuario se ha identificado correctamente en el servidor de validación. Esto se hace en el fichero /CATALINA_HOME/conf/server.xml añadiendo el siguiente código dentro del tag Engine.

3.- Añadir una válvula para restringir las máquinas desde las que se puede acceder. Pondremos la IP del servidor de validación y la de las máquinas que consideremos oportuno (es posible que queramos acceder directamente al aplicativo sin tener que pasar por WebSSO). Esto se hace en el fichero de configuración /CATALINA_HOME/conf/server.xml añadiendo el siguiente código dentro del tag Engine.


<Valve className="com.ibm.tivoli.integration.am.catalina.valves.AMTomcatValveAX" />

Finalmente reiniciaremos el servicio para que se apliquen los cambios en los ficheros de configuración.


<Valve className="org.apache.catalina.valves.RemoteHostValve" allow="10\.125\.102\.10 ,10\.125\.102\.11, 10\.125\.102\.14"/>

¿Cómo se ha creado la válvula AMTomcatValveAX?

La válvula original AMTomcatValve que ofrece el paquete AMTomcatValve.jar de IBM, no funcionaba porque para permitir el acceso a Axional se necesita un Principal especial. Con la válvula original no se cargaban los perfiles del usuario conectado y cuando intentábamos acceder daba errores de recurso protegido.

Para solucionar esto, se decide crear una variante de esa válvula que cree un deister.webstudio.login.MemoryRealmPrincipal en lugar de un org.apache.catalina.realm.GenericPrincipal, que es lo que hace la clase original.

Para ello,  hemos hecho lo siguiente:

Decompilado de  la clase original

  1. Descomprimir el fichero  AMTomcatValve.jar, obteniendo la estructura de carpetas en las que están contenidas las clases.
  2. Ubicar la clase (.class) AMTomcatValve, que se encuentra en com/ibm/tivoli/integration/am/catalina/valves.
  3. Decompilar el fichero AMTomcatValve.class. Una de las herramientas que podemos utilizar para hacer esto es DJ Java decompiler. Al decompilar, se obtiene el fichero AMTomcatValve.java
AMTomcatValve.java

Creación de la  válvula AMTomcatValveAX.java

  1. Hacemos una copia del fichero AMTomcatValve.java y lo guardamos como AMTomcatValveAX.java.
  2. Importar las clases necesarias para crear el MemoryRealmPrincipal, esto se hace en el encabezado de la clase:
    // webStudio login
    import deister.webstudio.login.MemoryRealmPrincipal;
    // webStudio dbms
    import deister.webstudio.core.dbms.info.conf.HttpUser;
    import java.sql.*;
    
  3. Modificar el método getPrincipal
    • Vamos a permitir que aparezca la pantalla de login si accedemos directamente al portal (sin webSSO), la clase original no sólo permite conexiones desde webSSO. De este modo podremos conectarnos directamente al server si es necesario. Para ello buscamos el siguiente código:
       if(s == null)
           throw new ServletException((new StringBuilder()).append(userHeader).append(" ").append("not found").toString());
      

      y lo sustituimos por este otro:

      if(s == null)
          return null;
      

      Como no se emite excepción y no se crea el principal (devolvemos null), Axional mostrará la pantalla de login para que el usuario se identifique.

    • Creamos un Principal a partir de la clase de Axional deister.webstudio.login.MemoryRealmPrincipal. Para ello sustituimos el código que se utiliza para crear el GenericPrincipal:
      GenericPrincipal genericprincipal = new GenericPrincipal(request.getContext().getRealm(), s, null, getRoles(request), null);
      

      por el siguiente código, en el que crearemos un principal al que le asignamos lor roles del usuario:

      principal = new MemoryRealmPrincipal(s);
      try {
          ArrayList list = HttpUser.getObject(s).getWebOSRoles();
          for (int idx = 0; idx < list.size(); idx++)
              principal.addRole(list.get(idx));
      } catch (SQLException ex) {
          System.out.println("Error getObject MemoryRealm " + s + " " + ex.getStackTrace().toString());
      }
      

De este modo tenemos una clase AMTomcatValveAX.java que con las prestaciones de la original, y que nos permite crear el principal con los roles necesarios para que el usuario pueda acceder a Axional. A continuación podemos ver el código fuente completo de  la clase customizada.

AMTomcatValveAX.java

Compilación y empaquetado

  1. Copiar el fichero AMTomcatValveAX.java en la misma ubicación en la que teníamos la original: com/ibm/tivoli/integration/am/catalina/valves
  2. Compilamos utilizando el siguiente comando: javac com/ibm/tivoli/integration/am/catalina/valves/*.java -cp /home/jas/server/lib/catalina.jar:/home/jas/common/lib/servlet-api.jar:/home/jas/server/lib/webStudioAuth.jar:/home/jas/common/lib/webStudioCore.jar:.
  3. Creamos un .jar mediante el uso del comando jar (ejecutarlo desde la carpeta que contenga la carpeta raíz com de la estructura de directorios): jar -cvf AMTomcatValve.jar com

Instalación en AXIONAL

Copiar el fichero al directorio /CATALINA_HOME/server/lib y reiniciar el servicio. A partir de este momento, podremos utilizar la válvula. Esto se explica en este mismo artículo en el  apartado “¿Cómo activar esta funcionalidad en AXIONAL?”.