SOA es una forma de diseñar nuestro software, no es un tecnologia en particular, sin embargo obviamente tenemos que implementarla de alguna manera. Y también en lo que se refiere a la seguridad debemos de definir como llevar a la práctica los conceptos que conlleva una arquitectura orientada a servicios.

Lo más habitual es usar como repositorio de usuarios un LDAP, por ejemplo el Active Directory de Microsoft. Casi todas las implementaciones de plataformas para la construcción de servicios web (como Java o .NET) tienen soporte para el estándar LDAP. En la práctica su uso es obligado ya que los productos que podemos utilizar para el desarrollo de nuestras aplicaciones, por ejemplo un servidor de portal exigen la disponibilidad de LDAP.

Cuando decimos que SOA es una paradigma de diseño de software y de integracion de servicios heterogéneos no se dice por decir. Debe de ser capaz de crear nuevos servicios de negocio, servicios compuestos de más alto valor añadido, que tengan sentido para el negocio y que se puedan ensamblar (no deberíamos decir construir) a partir de otros servicios más básicos. ¿Que pasa si cada uno de estos servicios a integrar pertenecen a otro sistema? Por sistema me refiero a un mix entre tecnología y Arquitectura que definen un contenedor de lógicas heterogéneo. Por ejemplo, un contenedor de EJB implementados en Java con seguridad declarativa basada en LDAP se podría considerar uno de estos sistemas, otro podría estar basado en COBOL/CICS/DB2. dentro de cada uno de estos sistemas podríamos tener un conjunto de lógicas o aplicaciones que denominamos backend. Pues bien:

¿que pasaría si un servicio de negocio compuesto integra lógicas de tres backends de tres sistemas distintos?

Si estos son antiguos o legacy, a buen seguro que no estarán basados en LDAP. La integracion está suficientemente soportada mediante el protocolo estándar de web services, prácticamente ubicuos en todos los sistemas operativos y lenguajes de programación. Sin embargo ¿Que pasa con la seguridad? Si queremos seguridad nominal, es decir, que las credenciales del usuario se propaguen de un sistema a otro, necesariamente nuestro servicio deberá estar desacoplado en cuanto a la implementación de cada uno de los servicios de más bajo nivel y también desacoplados y heterogéneos desde el punto de vista de la seguridad.

Si los tres servicios no tienen en común un contexto de usuario, no comparte una base de datos de usuario u otro repositorio de seguridad (como LDAP) entonces no es posible tener un sistema de autenticación y autorización común para estos tres servicios. Pero esto en principio no debería ser problema ya que SOA está precisamente para construir servicios de alto nivel a partir de sistemas heterogéneos, es el pegamento que lo puede unir todo, por muy distinto que sea dentro del “parque” de aplicaciones de nuestra empresa.

Pero la práctica es otro cantar. Tenemos que asegurar lo siguiente en nuestra arquitectura:

  1. Que la identidad del usuario se propague por todos los servicios implicados. En esto nos ayuda el estándar de web service (WS-Security) ya que nos permite enviar cabeceras del tipo UserNameToken de una manera estándar.
  2. Debemos ser capaces de validar la identidad del usuario, transmitida como cabecera en la invocación del servicio. Esto es fácil si el sistema soporta LDAP y los usuarios están dados de alta en este repositorio.
    Si no ocurre ninguna de estas dos cosas deberemos hacer extensiones programáticas personalizadas. En Java, por ejemplo, sería deseable usar la especificación JAAS.
  3. Para la autorización, saber si el usuario puede hacer o no lo que pide, también seria relativamente fácil si todos los sistemas soportan LDAP y los usuarios están dados de alta en este repositorio con unos roles que describen un conjunto de permisos sobre operaciones concretas en los servicios.
    Si no es así, es posible que se cuente con otro repositorio de seguridad propio del producto (como RACF en entornos Host IBM) pero la solución se complica de todos modos ya que empiezan varios repositorios diferentes. Aún puede ser peor si los repositorios de seguridad son “caseros”.
    En cualquier caso, si hay más de un repositorio de seguridad lo que verdaderamente se resiente es la administración de los usuarios y sus roles. En nuestro caso de los tres servicios que se ensamblan, no sería de extrañar que se tuvieran que dar alta al usuario y sus roles en estos tres repositorios haciendo uso de tres consolas de operación diferentes. El personal de administración de seguridad por lo tanto triplicaría su carga administrativa  para hacer posible que nuestro usuario pueda usar este servicio compuesto.

Por otra parte, también hay que tener en cuenta, que se suele tener el requisito, derivado de la LOPD de mantener una auditoría sobre qué usuario accede o modifica qué recurso. Por lo tanto, deberíamos tener un mecanismo de logs, homogéneo en los n sistemas que manejemos que sea capaz de generar unas trazas consistentes y que se asegure que relamente se escribe esta traza y además sin afectar al rendimiento de la aplicación.
En Java, una posible implementación sería la extensión del componente JMSAppender de Log4j. De este modo tendríamos un API igual que para el resto de trazas y éstas se podrían dejar en una cola de mensajería JMS persistente (para asegurarnos de que no se pierda ningún mensaje) y dado que es asíncrono, no afectaría al rendimiento.

En definitiva, cuando pensemos en ensamblar servicios de sistemas heterógeneos debemos pensar no sólo de la integración de la funcionalidad, de la definición del interfaz del servicio y de la propia lógica de integración. También debemos tener presentes las necesidades de la seguridad sabiendo que encontrarnos con sistemas heterogéneos es el pan nuestro de cada día en SOA.

Comparte esta entrada…
Share

Anuncios