Punto de decisión y punto de aplicación de la política

La arquitectura de autorización se describe con cuatro papeles. El punto de aplicación (PEP) es el que recibe la petición del usuario, pregunta y hace cumplir la respuesta. El punto de decisión (PDP) evalúa la política con los datos de la petición y responde permitir o denegar. El punto de información (PIP) es cada fuente de atributos que el decisor consulta. El punto de administración (PAP) es donde se escriben y publican las políticas. El estándar XACML 3.0 de OASIS (2013) fijó estos nombres, y hoy se usan como vocabulario aunque no se use ese lenguaje.

La ventaja de separar los papeles es que la regla vive en un solo sitio: todos los servicios aplican la misma decisión, y cambiarla es cambiar una política, no siete programas. El precio es que el decisor se vuelve una dependencia de todos, y hay que diseñar qué hace cada servicio cuando no responde y con qué frescura le llegan los datos.

Un servicio que guarda su propia copia de las reglas es un segundo punto de decisión que nadie administra. El día que se copió decía lo mismo que la política; después, la política cambia en la consola y la copia no. La diferencia no da ningún error: el servicio sigue decidiendo, con reglas viejas, y nadie revisa esas decisiones porque nadie sabe que existen.

Abre el laboratorio. En componentes.txt está la versión de cada política publicada; en puntos-de-aplicacion.txt, cómo decide cada servicio.

Si el decisor no responde, el punto de aplicación tiene que elegir: denegar, usar una decisión reciente guardada en caché o dejar pasar. Denegar es fallar de forma segura, el principio del módulo 2. La caché corta reduce la dependencia a cambio de que un permiso retirado siga valiendo unos segundos. Dejar pasar convierte cualquier corte del decisor, o cualquier forma de provocarlo, en acceso sin control.

Hay casos donde la operación no puede detenerse, y entonces se diseña una excepción acotada: qué acciones se permiten sin decisor, durante cuánto tiempo y con qué revisión posterior. Lo que no se acepta es dejar pasar todo.

Una decisión es tan buena como el atributo más viejo que usa. Si el decisor no consulta la fuente en el momento sino una copia, la antigüedad de la copia es el tiempo durante el cual un cambio real (un traslado, una verificación que vence, un retiro) todavía no existe para la política. Ese tiempo hay que leerlo en el diseño, no descubrirlo en un incidente.

Lee fuentes-de-atributos.txt y fíjate en cuándo se tomó la última copia de cada atributo. Después cruza verificaciones.txt con registro-del-decisor.txt.

En el mismo registro, una persona trasladada a otra obra a primera hora sigue editando actas de la obra anterior a media mañana. El decisor no se equivocó: aplicó la regla con el dato que tenía.