INSTALACIÓN de PAPI en TOMCAT

"Configuración de la autenticación de una aplicación en Tomcat contra el sistema PAPI de la Universitat, utilizando OpenPAPI".

1. Introducción.
2. Descargar el módulo OpenPAPI.
2a. Modificarlo para que devuelva el parámetro "rol" al tomcat.
3. Incorporarlo al directorio de librerías de Tomcat (5 o 6 o 7) (NO PROBADO EN VERSIONES MÁS RECIENTES).
4. Configurar el Realm OPENPAPI.
5. Configurar el contexto de la aplicación que se va a validar utilizando OpenPAPI.
6. Configurar en la aplicación la parte de la misma que queremos que se autentique contra OPENPAPI.
7. Reiniciar Tomcat
8. Probar. Comportamiento esperado.

1. Introducción.

Se presenta la necesidad de validar una aplicación web externa a la UV (podría ser interna) instalada en un servidor Tomcat contra el sistema de validación de usuarios de la Universitat de València. No se puede utilizar OpenLDAP porque no se permite hacer bind desde fuera de la institución.

Así pues, la alternativa es validar con el sistema AS. Para ello tratándose de Apache existe un módulo modificado por el SIUV para validar contra PAPI. En el caso de Tomcat no se ha desarrollado ningún módulo al respecto en el SIUV.

Pero encontramos en Internet el módulo OpenPAPI-Realm que puede utilizarse como fuente de autenticación de usuarios. Este componente permite integrar la tecnología PAPI dentro de la arquitectura de seguridad de Tomcat. Cada versión de Tomcat define una arquitectura diferente, OpenPAPI-Realm es compatible sólo con Tomcat 5 y 6. Para ello, se define un nuevo componente de autenticación Tomcat así como un Realm propio, que son capaces de entender el protocolo PAPI y darle funcionalidad de Proveedor de Servicio.

2. Descargar el módulo OpenPAPI.

Desde la copia local del OpenPAPI-Realm-1.2.zip.

2a. Modificarlo para que devuelva el parámetro rol al tomcat.

Este módulo debe configurarse NECESARIAMENTE para que autentique contra un GPoA. No funciona directamente con es AS. El GpoA devolverá una serie de parámetros, entre los cuales está el usuario (username), pero el GpoA de la Universitat de Valéncia no devuelve el parámetro rolesAttr que el módulo de OpenPAPÎ espera, por lo que se produce un error en la autenticación.

Habría dos formas de solucionarlo:

Modificar el GpoA
Modificar el módulo OpenPAPI-Realm

Optamos por la segunda ya que tiene menos implicaciones y lo que hacemos es en el método authenticate de la clase java:

src/main/java/es/prise/openpapi/authn/OpenPAPIAuthN.java

Dónde recoge los parámetros del GpoA comentamos esas líneas y añadimos a mano el rol que queremos validar, en este ejemplo he puesto tomcat, pero se podría definir un rol nuevo en tomcat para este tipo de autenticación.

El código fuente quedaría de esta forma:

List roles = new ArrayList();
/*     if (attrs.containsKey(rolesAttr)) {
            String[] values = (String[]) attrs.get(rolesAttr);
            for (int i = 0; i < values.length; i++) {
               roles.add(values[i]);
               }
            }
*/
// anyadimos rol a mano
roles.add("tomcat");
System.out.println("Rol tomcat anyadido  a mano");

Compilar el módulo (probado con Maven 2, java 1.7 del OpenJDK)

3. Incorporarlo al directorio de librerías de Tomcat (5 o 6).

Una vez compilado/descargado el módulo (zip o .gz) lo descomprimimos y vemos que tiene estos 3 jars: bcprov-jdk15-1.44.jar, OpenPAPI-Realm-1.1.jar (o 1.0) y papi-crypt-1.0.2.jar, los copiamos al directorio de librerías del tomcat, típicamente $CATALINA_HOME/lib

Después de las modificaciones el único que realmente cambia es el OpenPAPI-Realm-1.2.jar

4. Configurar el Realm OPENPAPI.

Necesitaremos indicarle al Tomcat que queremos usar este módulo de autenticación. Este proceso no es trivial puesto que Tomcat no ha previsto que los administradores incluyan nuevos tipos. Para ello, deberemos obtener el archivo Authenticators.properties de la librería catalina.jar de la siguiente manera:

jar –xvf catalina.jar org/apache/catalina/startup/Authenticators.properties

Lo editamos y añadimos la última línea que configura el Realm OPENPAPI:

# These must match the allowed values for auth-method as defined by the spec 
BASIC=org.apache.catalina.authenticator.BasicAuthenticator
CLIENT-CERT=org.apache.catalina.authenticator.SSLAuthenticator
DIGEST=org.apache.catalina.authenticator.DigestAuthenticator
FORM=org.apache.catalina.authenticator.FormAuthenticator
NONE=org.apache.catalina.authenticator.NonLoginAuthenticator
OPENPAPI=es.prise.openpapi.authn.OpenPAPIAuthN

Lo volvemos a añadir al catalina.jar:

jar -uvf catalina.jar org/apache/catalina/startup/Authenticators.properties

5. Configurar el contexto de la aplicación que se va a validar utilizando OpenPAPI.

El contexto de una aplicación en tomcat se puede configurar en el fichero server.xml general para todo el servidor o en el fichero META-INF/context.xml de la aplicación en cuestión, en nuestro caso lo configuramos dentro del $CATALINA_BASE/conf/server.xml porque es dónde configuramos los contextos de las aplicaciones.

Añadimos el siguiente bloque entre las etiquetas de nuestra aplicación:

<Realm className="es.prise.openpapi.realm.OpenPAPIRealm"
              pubkeyFile="ruta_al_public_key/GPoA_pubkey.pem"
              gpoaURL="https://gpoa.uv.es/papi/cookie_handler.jpg"
              rolesAttr="Lcook"
              userIdAttr="username" 
              defLoggedOutURL="http://rodrigo.uv.es/logout"
              defNoAuthRURL="http://rodrigo.uv.es/"
              />
      <Valve className="es.prise.openpapi.valve.OpenPAPILogoutValve"
              gpoaURL="https://as.uv.es/cgi-bin/AuthServer?LOGOUT&RECONNECTURL=https://uvapp.uv.es/msgs"
              logoutRegExp=".*/logout[^\\w]?"
              logoutReturnParam="returnurl" />

Donde,

pubkeyFile: es la ruta absoluta de la clave pública del GPoA/adAS al que preguntará por la identidad del usuario. Este fichero nos lo tiene que pasar el administrador del sistema AS, lo colocaremos en una ruta en nuestra máquina con tomcat y esa ruta la apuntaremos en este parámetro.

gpoaURL: es la URL del GPoA, con parámetros.

PAPIPOAURL=http%3A%2F%2Frodrigo.uv.es/jspui/index.jsp". Es la URl a la que debe retornar cuando la autenticación haya tenido éxito. En este ejemplo retornamos al índice.

En el caso de la válvula del Logout los parámetros son distintos, pero si ponemos los que pone en el ejemplo borrará las cookies del AS.

rolesAttr: es el atributo que se utilizará para establecer los roles del usuario. Debería coincidir con los que configuremos para la aplicación en el siguiente paso.

userIdAttr: es el atributo que se utilizará para establecer el identificador del usuario.

defLoggedOutURL: es la URL a la que redirigirá al usuario cuando haya finalizado el proceso de logout. [Este parámetro es opcional]

defNoAuthRURL: es la URL a la que redirigirá al usuario cuando no tenga permisos para acceder a la aplicación, en vez de enviarlo al GPoA. [Este parámetro es opcional]

logoutRegExp: es una expresión regular que permita indicarle al componente cuando una petición es de logout.

logoutReturnParam: es el nombre del parámetro HTTP que se utilizará para establecer la URL de vuelta cuando finalice la gestión de logout con el GPoA. [Este parámetro es opcional]

Para cerrar sesión el GPOA no cierra sesión, por lo que en la configuración de la para el logout configuramos la URL del AS de la UV en lugar del del GPOA.

6. Configurar en la aplicación la parte de la misma que queremos que se autentique contra OPENPAPI.

La configuración de una aplicación web se establece en el fichero WEB-INF/web.xml de la aplicación.

Aquí añadiremos al final lo siguiente (pero antes de </web-app>):

<security-constraint>
  <web-resource-collection>
    <web-resource-name>
      Todo el sitio
    </web-resource-name>
    <url-pattern>/*</url-pattern>
  </web-resource-collection>
  <auth-constraint>
      <role-name>tomcat</role-name>
  </auth-constraint>
</security-constraint>
  <login-config>
        <realm-name>Entrar en PAPI</realm-name>
        <auth-method>OPENPAPI</auth-method>
  </login-config>

Dónde dentro de <url-pattern></url-pattern> hemos puesto que proteja toda nuestra aplicación, podría ser sólo una parte.

El rol configurado aquí ha sido tomcat, pero podría ser otro creado expresamente (en el fichero tomcat-users.xml de tomcat) para este tipo de autenticación.

7. Reiniciar Tomcat

/etc/init.d/tomcat6 restart

8. Probar. Comportamiento esperado.

Lo hemos probado en la aplicación jspui de la máquina Rodrigo, protegiendo sólo la página entrar.jsp:

Entramos a:
http://rodrigo.uv.es/jspui/index.jsp

Nos llevará al sistema de autenticación GPOA, pasándole parámetros de quien sómos y dónde venimos:

Estaremos en as.uv.es

El usuario ahí introducirá su usuario y contraseña de la Universitat y el sistema lo validará, si es correcto, nos redirigirá a la URL de la que veníamos.

En ese momento el módulo PAPI lee el valor devuelto en el parámetro DATA, lo desencripta con la clave pública del servidor GPOA, obtiene el parámetro username y el rol, cómo no lo recibe del GPOA, le añade uno y redirige a nuestra aplicación, que nos dejará pasar porque tenemos el rol adecuado.

Si pedimos cualquier URL que cotenga el texto logout, se lanzará la Válvula del Logout y nos redireccionará a la URL que le hemos puesto en el parámetro GPOA para hacer el Logout en el PAPI, a través del AS de la UV.

Según la configuración DEL GPOA hecha en el servidor AS, el cookie de sesión sólo nos vale para esta aplicación, no para el resto de aplicaciones de la UV, y es lo que deseamos, ya que esta aplicación va a ser externa a la UV.

Documentación

En los mismos fuentes. La documentación antigua se ha vuelto inencontrable.

Jose Angel Navalón - jnavalon (at) uv.es

Servicio de Identificación