Usar isAccessAllowed con BEA WLP10

Recientemente nos hemos visto en la necesidad de añadir seguridad en un portlet que se iba a desplegar en un portal Weblogic Portal 10. La modificación consistía en dar una funcionalidad concreta a un rol determinado dentro la aplicación.

Después de valorar diferentes alternativas, decidimos aplicar el tag isAccessAllowed de la taglib xmlns:auth="http://www.bea.com/servers/p13n/tags/auth" . Este tag proporciona la comprobación primaria para autorizar el acceso a recursos de WLP. Si el resultado de la comprobación es negativo, el cuerpo del tag no se renderiza.

Este tag espera los siguientes parámetros:

• id. El nombre de la variable donde se almacena el resultado de la comprobación. Es de tipo booleano. Es obligatorio
  
• resourceId. Representa la taxonomía definida para el recurso dentro de la aplicación. Es de tipo String y es obligatorio.
  
• capability. Este no es obligatorio y representa el permiso concreto (view, edit, remove,...) que se quiere autorizar.
  

El problema de esta solución estaba en la construcción de la taxonomía del recurso que queríamos proteger (en este caso un portlet). No encontramos documentación de referencia de como construir esta cadena y tuvimos que investigar un poco hasta dar con la forma correcta.

Para construir el identificador de un recurso se debe concatenar los siguientes elementos:

Tipo_objeto + Etiqueta_de_portal + Etiqueta_de_desktop + Etiqueta_de_recurso

Donde:

• Tipo_objeto es una constante: Portlet para los portlets y Page para las páginas.
• Etiqueta_de_portal corresponde al Portal Path del portal.
• Etiqueta_de_desktop es el Desktop Path del desktop donde está instanciado el portlet.
• Etiqueta_de_recurso es el atributo Label de la instancia del portlet.

Todos estos valores se pueden obtener de forma bastante sencilla a partir de los elementos de presentación contextuales del portal. Por ejemplo:

<>
AppContext ac = AppContext.getAppContext(request);

AbstractButtonPresentationContext absBut =(AbstractButtonPresentationContext) pageContext.getAttribute("abstractbuttonpc");

StringBuffer resourceId = new StringBuffer("Portlet");

resourceId.append(EntitlementConstants.RESOURCE_ID_DELIMITER)
.append(ac.getPortalPath())
.append(EntitlementConstants.RESOURCE_ID_DELIMITER)
.append(ac.getDesktopPath())
.append(EntitlementConstants.RESOURCE_ID_DELIMITER)
.append(absBut.getWindowLabel());
< /jsp:scriptlet >

Además de a portlets y páginas, esta seguridad se puede aplicar a otro tipo de recursos siguiendo una nomenclatura similar.

Un posible inconveniente de esta solución estriba en el rendimiento, ya que el cálculo del resource id se hace a nivel de la capa de presentación. De todas formas, hay técnicas sencillas para evitar este problema.

WSRP en BEA Weblogic Portal

Hace unos días, mi compañero en IN2, Juan Carlos, hablaba del despliegue de portlets en shared library para Weblogic Portal. La idea es buena ya que permite independizar el desarrollo de portlets de la administración y mantenimiento del portal. Aun así, algunos aspectos de esta solución no acaban de convencerme como, por ejemplo, que haya que detener la aplicación de portal cada vez que se despliega una actualización de la shared libary.

Una alternativa para la distribución de portlets es usar portlets remotos que cumplan el estándar WSRP.

El estándar WSRP se presenta como una herramienta muy útil para la distribución y consumo de portlets entre diferentes portales, independizando la presentación del portlet de la ubicación donde esté desplegado.

El portal de Weblogic está preparado para trabajar con WSRP de forma que se puedan añadir nuevos portlets sin necesidad de detener la aplicación ya que se pueden añadir nuevos productores de portlets desde la consola de administración del portal. Los pasos a seguir son los siguientes:

1. Localizar el productor del portlet.
2. Rellenar la información del productor
3. Registrar el productor (opcional)
4. Seleccionar los portlets a incorporar en nuestro portal
5. Utilizar los portlets en las páginas de nuestro portal

Esta aproximación puede que no sea adecuada para todos los escenarios de portal pero es la única que independiza del todo la aplicación de portal de los portlets. Además es una estrategia alineada con SOA ya que en este caso el portlet es el servicio que se quiere compartir y reutilizar.

El portal de Weblogic también permite usar portlets remotos desde el IDE Workshop, de forma que las definiciones de los productores de portlets se incluyen en el fichero .portal y se despliegan junto con el resto de la aplicación.

Migración de datos en Weblogic Portal

El traspaso de información entre entornos de desarrollo y de producción puede ser una tarea difícil dependiendo de las herramientas utilizadas.

Recientemente me he visto en la necesidad de crear un nuevo dominio de producción de BEA Weblogic Portal que debiera aprovechar los contenidos introducidos en el Content Management de un dominio anterior. Había tres posibles formas de afrontar la tarea:

• Creando un nuevo dominio desde cero y utilizar las herramientas de propagación de contenido proporcionadas por WLP.
• Creando una nueva instancia en el cluster del dominio anterior, para copiar su configuración, y luego sacándola del cluster para que funcionara de forma independiente.
• Creando un dominio nuevo desde cero y cambiar el acceso a datos para que utilizara el esquema de base de datos del dominio anterior.

La primera opción quedó descartada por el tiempo que implica y los problemas técnicos que presenta la propagación de contenidos de WLP. La segunda opción parecía buena idea pero añade un elemento de inestabilidad que amenaza la consistencia de la aplicación de Portal.

La última opción fue la que se llevo a cabo pero con una variante. El nuevo dominio se creó de cero, con el mismo nombre que el anterior, sobre un nuevo esquema de base de datos (la BD es una Oracle 10g). A continuación se hizo una exportación del esquema del dominio antiguo y una importación sobre el nuevo. Y funcionó !

Gracias a esta técnica conseguimos replicar el entorno de producción, nos permitió apagar el entorno antiguo y seguir trabajando con el nuevo con toda la información disponible.