En mi anterior entrada en este blog, plantee una herramienta muy sencilla, más bien un concepto, para que nos ayudase en nuestra difícil labor de poner orden en el mundo de los servicios. Era necesaria para que un analista pueda saber si un servicio que necesita ya existe. Si existiera, para pedir una modificación del servicio o ante un cambio, saber a quien le afecta (análisis de impacto).
Quedaba pendiente sin embargo, ver otro tema que si no se trata convenientemente puede dar muchos problemas, me refiero a la gestión de la seguridad de los servicios o lo que podríamos llamar “el gobierno de la seguridad”.
Como sabéis el éxito de SOA vendrá cuando se se construyan servicios compuestos a partir de otros servicios de bajo nivel o grano fino. Estos últimos servicios, los básicos, los que exponen la lógica de nuestros backends llegarán a un número suficiente, una masa crítica de servicios, en los que no haga falta ya desarrollar más, sino que nos dedicaremos a ensamblar.
En este escenario, en el que fabricaremos nuevos servicios a partir de otros servicios, tenemos que preguntarnos cómo se va a gestionar la seguridad.
Normalmente la seguridad en aplicaciones de negocio, se basa en repositorios de usuarios que siguen el estándar LDAP. Las aplicaciones, ya sean de frontal o de servicios, declaran en sus descriptores de despliegue que “roles” de usuarios pueden acceder a estas funcionalidades. Los roles son una agrupación de usuarios finales para facilitar la gestión de la seguridad, en lugar de declarar en la aplicación uno por uno los cientos o miles de usuarios que pueden acceder se indica únicamente un rol o varios a los que pertenecen estos usuarios.
¿que problema tenemos entonces?
Imaginemos un nuevo servicio de alto nivel, por ejemplo “calcular presupuesto” de una aplicación de agencia de viajes. Este servicio puede estar formado por otros tres: calcular presupuesto de hotel, de avión y de coche de alquiler. Estos tres servicios a su vez pueden estar compuestos por otros varios en una progresión geométrica, y así por poner un ejemplo, nuestro único servicio pues estar en realidad formado por 15 servicios.
Ahora imaginemos que estos 15 servicios, cada uno de ellos, tiene su propia y diferente configuración de seguridad. Es decir, para acceder a ellos se necesita un rol diferente. Nuestro usuario accederá al primer servicio, el de “calcular presupuesto” pero el resto de servicios permanecerán ocultos a este usuario. Y ahora bien ¿a cuantos roles debe pertenecer el usuario para poder ejecutar este servicio? pues a los 15 roles de los 15 servicios.
¿y cuales son esos roles? ¿donde puedo mirar para saberlo?
Puedo ir documento a documento y mirar en la descripción del servicio, un documento tipo word, que roles necesita cada servicio, pero esto no es operativo.

Si ya disponemos de la herramienta que nos permite saber los servicios que tenemos, quien los usa, etc. como vimos en la entrada anterior, es fácil su adaptación para saber qué tipo de seguridad tiene cada servicio. Mediante esta funcionalidad, de manera recursiva, puede ir mirando los servicios que se usan, podemos saber fácilmente qué roles se necesitan para que el usuario pueda ejecutar la totalidad de los servicios que necesita nuestro servicio compuesto.
Si no tenemos este control, es fácil de imaginar el caos que se va producir cuando haya que desplegar el servicio o haya que incorporar más usuarios al mismo, sobre todo en una gran empresa en la que los usuarios se cuentan por miles y los servicios por cientos.

Una herramienta muy sencilla, que nos ayudará a poner orden y “gobierno” en la seguridad de los servicios. La pregunta no sería si usas una herramienta, más bien sería ¿que herramientas tienes tú para estos casos?

Comparte esta entrada:

Share

Anuncios