Listas de control de acceso (ACL)

Es posible que esto que os voy a contar a muchos de vosotros no os venga de nuevo, pero me ha parecido interesante exponer la experiencia que me ha hecho redescubrir algo tan básico como son las Listas de Control de Acceso (ACL). Yo conocía el concepto de ACL en dispositivos de red (como routers), pero no recordaba que estas podían usarse en el desarrollo de un software para proteger recursos según roles. Al final no deja de ser un simple método de usuarios y roles, pero como en la navaja de Occam, la solución más simple siempre suele ser la correcta.

Estando el otro día reunidos varios compañeros para la definición de requerimientos de un software que vamos a desarrollar, se nos planteó la duda de cómo íbamos a gestionar los permisos en dicha aplicación. La aplicación se va a desarrollar con el framework de php CakePHP, y un compañero se dio cuenta que este entorno tiene implementadas las ACL. Buscando por Internet su funcionamiento, encontré el ejemplo que los chicos de Cake han hecho, y me parece que mejor no se puede explicar. Voy a tratar de hacer un resumen un poco más gráfico que ellos, pero si no queda claro, en su web está toda la explicación.

Lo primero que hay que entender son dos conceptos muy importantes; quién o qué quiere poder acceder a que cosa. Al quién o qué (generalmente usuarios) lo llamaremos ARO (ARO – Access Request Object – Objeto que solicita el control de algo) y la cosa la llamaremos ACO (ACO – Access Control Object – Objeto que se quiere controlar). Vamos a utilizar los mismos ARO y ACO que se utilizan en el ejemplo de Cake y que hacen referencia a los personajes del Señor de los Anillos. En la siguiente tabla vemos una lista de los distintos ARO que conforman nuestro ejemplo:

ARO

A los distintos actores de nuestro ejemplo se les tiene que otorgar el acceso a distintos objetos, según quienes sean o que rol desempeñan en la historia (o aplicación). Estos son los distintos objetos:

ACO

Este ejemplo de matriz de permisos funciona bien en este caso, pues se conocen los actores y objetos que intervienen, pero queda claro que no es muy escalable ya que para casa objeto nuevo que pueda entrar en escena, o cada personaje, se han de “revisar” uno a uno quién tiene permisos sobre qué. Ahora imaginemos que hemos de modelizar esto para todos y cada uno de los personajes de toda la saga. Está claro que se hace un poco difícil y tedioso. Si además esto se ha de programar, ni os cuento. En otras palabras, estaría muy bien que, una vez terminada la batalla, los hobbits pudieran acceder a la cerveza y al jamón; en otras palabras, otorgar individualmente permisos a hobbits es tedioso y propenso a errores, mientras que aplicarles un cambio en cascada es mucho más fácil.

La ACL se suele implementar en una estructura de árbol y generalmente, existe uno para los AROs y uno para los ACOs. Organizando los objetos así, los permisos se gestionan de forma granular y se mantiene una visión general. La siguiente figura muestra un ejemplo de los ARO agrupados por tipo (o rol).

De esta forma ahora podemos ir dando/quitando los permisos a los distintos objetos según por que rama del árbol vayamos descendiendo. Una primera aproximación sería, negar todo a la comunidad, y a partir de ahí ir otorgando los permisos correspondientes según se muestra en la siguiente figura, en la que quedan superpuestos los dos árboles.

Si vemos el esquema, notaremos que a los guerreros (Legolas, Aragorn, Gandalf) se les permite el jamón, la cerveza y las armas. Además, a los magos se les permite da diplomacia. En el caso de los hobbits, vemos que por defecto todos ellos tienen permiso de cerveza, así que cualquier hobbit nuevo que añadamos (por ejemplo Sam), podrá acceder a ella. Sin embargo a título personal, se le ha denegado la cerveza a Merry (al parecer abusaba de ella), y por último se le permite a Frodo llevar el Anillo.

Vamos, que espero que haya quedado claro la potencia de otorgar/denegar permisos a los ARO de los distintos ACO que forman nuestra aplicación. Está claro que esto nada tiene que ver con el “Login” en ella (que sería como pertenecer o no a la comunidad del anillo), si no que lo que se establece son los permisos sobre partes concretas de la aplicación.

Una vez visto esto, queda pendiente en otro post, explicar como se usa esto en CakePHP, con permiso de Nedim ;)