id doe

Una de las posibles opciones que tenemos para implementar la seguridad en una arquitectura SOA es la de propagar las credenciales del cliente o del usuario final a través de todos los servicios por lo que pase esta invocación, típicamente desde la pantalla hasta la base de datos.

Hay que tener en cuenta que en SOA, hay servicios compuestos y flujos de integración. Por lo tanto, un usuario final (un empleado por ejemplo) desde su aplicación de frontal (hecha por ejemplo en Visual Basic) puede desencadenar la invocación a un servicio web (al pulsar un botón de un formulario por ejemplo). Para hacer esto, necesita enviar las credenciales del usuario (que puede ser su nombre de usuario) con una contraseña o un token de seguridad. Estas credenciales llegarán al primer servicio, y tal vez, desde este servicio se llame a otro o a otros. Por lo tanto, las credenciales del usuario pueden viajar de servicio en servicio, que siempre ejecutarán la lógica de negocio en nombre de ese usuario.

Por supuesto, este enfoque tiene varias ventajas en cuanto a la seguridad y auditoría del sistema. Primeramente los servicios se securizan y se deja pasar a o no a un usuario concreto (con nombre y apellidos). Además todas las acciones que se hagan en el servicio, se podrán guardar trazas con el username del usuario final que está pidiendo su ejecución.

Por el contrario, esto tiene una desventaja muy importante: es necesario dar acceso a ese usuario (o rol que aglutine a varios usuarios) a todos y cada uno de los servicios por los que puede pasar la invocación, que pueden ser uno, dos o decenas.

Así que el diseño de una arquitectura SOA debemos estudiar nuestro caso en particular y ver si nos compensa el mayor grado de seguridad los muchos inconvenientes de la propagación de las credenciales del usuario. Realmente, si la seguridad y auditoría de los servicios no es un requisito principal de nuestra empresa ,en mi opinión, no merece la pena.

Así pues, establecería siguiente política de securización :

  • Los frontales se securizarán mediante roles y se autorizará a cada rol con unos flujos de navegación determinados (conjuntos de pantallas)
  • Los servicios estarán securizados con un usuario de aplicación. Es decir, no es de un usuario (como un empleado).

De esta manera logramos securizar todos los servicios sin tener que gestionar el acceso de todos los roles con todos los usuarios de la empresa. En su lugar, sólo habrá que hacerlo con los usuarios de aplicación que serán muchos menos.

Esto tiene como principal desventaja que ya no se tiene la identidad del usuario final cuando se ejecuta un servicio. Por lo tanto, no podemos generar trazas de auditoría para deja constancia que cierto usuario está ejecutando ciertas acciones. Una forma de mitigar esto sería enviar una cabecera de control en la invocación a los servicios donde se transmita el usuario (username) del cliente final que está invocado. Es decir, la seguridad se hará con usuarios de aplicación pero se transmitirá, además, este username.

Como conclusión, en este tema como en casi todos, debemos hacer lo justo para nuestra necesidad, ni menos pero tampoco más. Hacer de más, no tiene que ser bueno, al contrario. Puede representar un gasto de tiempo y de dinero a medio y largo plazo que nos pasará factura.

Anuncios