continuación...

Seguridad J2EE soportado por WebSphere
Application Server y Tivoli Directory Server

La seguridad puede abarcar muchos temas, pero principalmente se centra en especificar cuáles son los recursos que se desean proteger, quiénes pueden utilizar éstos recursos, cómo los pueden utilizar y cómo garantizar la identidad de las entidades que los utilicen.

Definir los recursos que queremos proteger, las entidades que pueden utilizarlos y la forma cómo los pueden utilizar puede ser una labor de programación exhaustiva. Con la aparición de contenedores de aplicaciones, los programadores vieron cómo se puede delegar las labores de seguridad al contenedor. Por ejemplo la especificación de aplicaciones J2EE permite desarrollar soluciones aplicativas flexibles y actualizables ya que delegan muchas de éstas funciones de seguridad al contenedor.

Una de las grandes ventajas que ofrece el desarrollo de aplicaciones J2EE es la facilidad que ofrece la especificación para implementar la seguridad aplicativa de forma declarativa. De una forma ágil y sencilla, un programador puede definir la seguridad de su aplicación en un archivo descriptor que especifica la protección deseada a recursos de la aplicación y el nivel de acceso deseado según los roles de usuario. Ésto significa que un programador tiene control sobre los recursos que desea proteger, y los roles que se asocian a cada recurso. Todo ésto sin tener que editar el código fuente de la aplicación.

Una implicación importante de implementar la seguridad declarativamente es que permite una mayor flexibilidad cuando se piense en actualizar la seguridad de la aplicación. Como no fue programada, si quisiéramos incrementar o restringir el nivel de acceso a recursos para un determinado grupo de usuarios, no es necesario realizar modificaciones en el código fuente. Lo único que debería importarle al programador sería entender cuáles son los recursos existentes y los roles de usuarios definidos.

La seguridad declarativa es manejada por el contenedor de aplicaciones. WebSphere Aplication Server (WAS) utiliza el descriptor de seguridad para asociar los roles y usuarios definidos en el contenedor con los de la aplicación. Otra funcionalidad que tiene WAS, es la facilidad con que se delega la administración de usuarios a otra aplicación, por ejemplo con Tivoli Directory Server que es un directorio que implementa el protocolo LDAP. Utilizando un “wizard” en la consola administrativa de WAS, se configura de forma sencilla nuestro repositorio externo de usuarios, sea un directorio LDAP, repositorios federados o alguna estructura personalizada para administrar usuarios. De esta forma para las aplicaciones es indiferente donde se encuentran los usuarios o quien los administra.

Existen diversas formas de aproximar soluciones al problema de identidad. Los certificados digitales son una solución que nos permiten generar una especie de cédula digital, para así poder asegurar la identidad de los usuarios de una aplicación. Cuando una comunicación inicia entre un cliente y un servidor, generalmente si existe algún nivel de seguridad con certificados el servidor es quién envía al cliente su certificado para que éste pueda acceder a sus servicios. Ésto realmente se utiliza para asegurar el canal de comunicación entre las partes a través de SSL.

Cuando un servidor envía un certificado confiable es porque está validado por una autoridad externa que es quién se encarga de certificar que el certificado corresponde a quién lo está enviando. Si bien ésto es ideal, no en todos los países existen autoridades que realizan éstas labores. Una solución muy flexible es implementar el sistema de certificados auto-firmados. Los certificados autofirmados son generados por la organización que desea que sus clientes sean identificados. Estos certificados son validados por la organización en el momento en que un cliente desea acceder a los servicios. Si bien no es el caso ideal, es una solución viable. Adicionalmente deja la puerta abierta cuando en futuro exista una autoridad que elabore los certificados.

Una arquitectura flexible y escalable.

Como se ha mencionado, en el contexto de los formularios se desarrolló una arquitectura flexible y escalable. Se desacopló la lógica del negocio de la presentación, se utilizaron mapas de transformación para facilitar el acceso y transformación de datos de la base de datos a XML y la seguridad se desarrolló declarativamente y se integró con un directorio de usuarios basado en el protocolo LDAP. Todo ésto bajo una idea sencilla de lograr agilizar un proceso de negocio que ahorrara tiempo y dinero, implementado por una infraestructura orientada a servicios.

El diagrama siguiente muestra una idea general de la implementación realizada. La flexibilidad del sistema se puede evidenciar porque por ejemplo la base de datos se accede mediante WebSphere TX. Si se quisiera cambiar la proveniencia de los datos, simplemente habría que cambiar la definición de los datos y la transformación, sin tocar la aplicación. El directorio de usuarios Tivoli Directory Server también se podría sustituir por otro directorio sin tener que cambiar la aplicación.

La solución desarrollada realmente ofrece todas las facilidades y ventajas necesarias para que la organización cumpla con el objetivo de agilizar sus procesos