El Modelo XACML: PEP, PDP, PIP y PAP

Una noche en un club de socios

Sara quiere entrar en un club de socios exclusivo. En la puerta, el portero la para y llama por radio a la gerente, que está en la oficina del fondo: “Aquí hay una tal Sara. ¿Puede entrar?”. La gerente consulta el libro de normas del club, ve que depende del nivel de socia y le pide al archivista que la busque. El archivista saca su ficha: socia al día, nivel oro, mayor de edad. La gerente lee la norma según la cual las socias oro pueden entrar a cualquier hora, dice “que pase” y el portero se aparta. La dueña, que escribió ese libro de normas hace semanas, no está ni cerca de la puerta.

Cuatro personas, cuatro trabajos, y nadie hace más de uno. Esa separación es la arquitectura de la que trata este artículo. Los artículos anteriores respondían a en qué debe basarse una decisión de acceso: dueños, etiquetas, roles, atributos, políticas, relaciones. Este gira noventa grados hacia otra pregunta: decidas como decidas, ¿cómo se construye la máquina que decide? ¿Cuáles son sus piezas, quién habla con quién y dónde vive la política? El sector llegó a una única respuesta, la arquitectura de referencia de XACML, y en cuanto ves sus cuatro componentes en un sistema, cada producto de autorización que te encuentres deja de ser un misterio y pasa a ser una variación de un plano conocido.

XACML significa eXtensible Access Control Markup Language, un estándar de OASIS de mediados de los 2000. Esto es lo que lo hace merecedor de un artículo entero: el lenguaje de XACML, su farragosa sintaxis XML, es hoy en buena parte historia, sustituido por sucesores más amables. Pero su arquitectura, la forma en que divide un sistema de autorización en cuatro papeles que cooperan, ganó del todo. Open Policy Agent, AWS Cedar, Amazon Verified Permissions, los motores al estilo Zanzibar, el IAM de tu nube: mira dentro de cualquiera y encontrarás las mismas cuatro piezas haciendo los mismos cuatro trabajos. Estudiamos XACML no para escribir su XML, sino porque nos dio el vocabulario y la forma que comparte toda la autorización moderna.

Cuatro personas, cuatro trabajos

El portero para a Sara en la entrada y, según la respuesta que reciba, se aparta o le cierra el paso. No conoce las normas del club, no busca a nadie y no decide. Solo pregunta y aplica. Es el punto de aplicación de políticas (PEP).

La gerente de la oficina del fondo es quien decide de verdad. El portero le hace la pregunta por radio y ella, consultando las normas, responde “permitir” o “denegar”. Tiene la lógica, no la puerta. Es el punto de decisión de políticas (PDP).

El archivista guarda las fichas. Para decidir, la gerente a menudo necesita datos que no tiene: ¿está al día la cuota de Sara?, ¿qué nivel tiene?, ¿es mayor de edad? El archivista los busca y se los pasa. Aporta información, nada más. Es el punto de información de políticas (PIP).

La dueña escribió las normas de la casa, “las socias oro entran a cualquier hora, las plata antes de las diez de la noche, nadie menor de edad”, y se las dio a la gerente antes de abrir el club. Escribe las normas de antemano y no está ni cerca de la puerta cuando llega Sara. Es el punto de administración de políticas (PAP).

Dos piezas más completan el dibujo. Entre el PEP y el PDP suele haber un gestor de contexto (context handler), el mensajero que traduce la petición de la aplicación al formato del PDP, reúne los atributos que pide el PDP llamando a los PIP y devuelve la decisión. Piensa en él como el ayudante de la gerente que corre entre la oficina, la puerta y el archivo para que ella pueda concentrarse en decidir. XACML nombra además un punto de recuperación de políticas (PRP), el almacén del que el PDP carga las políticas, la estantería donde está el libro de normas de la dueña. No siempre verás estas dos piezas con nombre, pero están implícitas allí donde aparecen los cuatro papeles principales.

Si te quedas con una frase, que sea esta: el PEP pregunta y aplica, el PDP decide, el PIP informa y el PAP escribe. Las dos parejas que más se confunden tienen cada una una pista clara. El PEP toca la puerta, porque la aplicación vive con la aplicación; el PDP toca las normas, porque la decisión vive en el motor. El PIP aporta hechos sobre esta petición ahora mismo, como si Sara es socia oro; el PAP aporta normas escritas antes, como que las socias oro pueden entrar. Hechos de ahora frente a normas de antes: esa es toda la diferencia.

Una petición en movimiento

Los papeles se ven más claros en movimiento. Esta es la petición de Sara recorriendo los cuatro componentes y volviendo como decisión, con las etiquetas del club al lado.

sequenceDiagram
  accTitle: Cómo recorre una petición de acceso la arquitectura de referencia de XACML
  accDescr: El diagrama muestra el orden de los mensajes de una única petición de autorización. Primero, el punto de administración de políticas publica las políticas en el motor de decisión de antemano, marcado como preparación. Después Sara envía una petición de acceso al punto de aplicación. El punto de aplicación la reenvía al gestor de contexto, que pide una decisión al punto de decisión. El punto de decisión carga la política aplicable y, como necesita más datos, pide atributos a través del gestor de contexto, que consulta al punto de información y devuelve atributos del sujeto, el recurso y el entorno. El punto de decisión evalúa la política frente a la petición y los atributos y devuelve permitir o denegar al gestor de contexto, que se lo pasa al punto de aplicación. Por último el punto de aplicación permite o bloquea el acceso de Sara. El paso de administración está separado en el tiempo del flujo de la petición en vivo.
  participant U as Sara
  participant PEP as PEP (Portero)
  participant CH as Gestor ctx.
  participant PDP as PDP (Gerente)
  participant PIP as PIP (Archivista)
  participant PAP as PAP (Dueña)
  PAP-->>PDP: publica políticas (preparación, antes de la petición)
  U->>PEP: pide acceso
  PEP->>CH: reenvía la petición
  CH->>PDP: ¿decides?
  PDP->>CH: necesito atributos
  CH->>PIP: busca sujeto / recurso / entorno
  PIP-->>CH: atributos
  CH-->>PDP: atributos
  PDP->>PDP: evalúa la política
  PDP-->>CH: permitir / denegar
  CH-->>PEP: permitir / denegar
  PEP-->>U: deja pasar o bloquea

De antemano, la dueña publica las normas para la gerente; ese paso discontinuo de preparación es lo único que no ocurre durante la petición de Sara. Después Sara le pide al portero que la deje entrar. Él no razona nada; le pasa la petición al ayudante de la gerente, que le pide a ella que decida. La gerente saca la norma correspondiente, ve que necesita datos y pide los atributos de Sara; el ayudante se los pide al archivista y se los trae. La gerente evalúa la norma frente a la petición y los datos, produce permitir o denegar y se lo devuelve al portero, que abre o cierra la puerta. Cada componente hizo un trabajo, y la petición pasó por cada uno a su turno.

¿Por qué dividirlo en cuatro?

Puede parecer burocracia. ¿Por qué no dejar que un componente lo haga todo? Porque la separación da propiedades que no se consiguen de otra forma, las mismas ventajas que prometía el artículo del PBAC, ahora con una estructura concreta.

Como decidir está separado de aplicar, un PDP puede servir a decenas de PEP. Cada aplicación, servicio y pasarela pregunta a la misma gerente, así que todos aplican las mismas normas de la misma forma, y la coherencia pasa a ser una propiedad de la arquitectura y no una esperanza. Como escribir normas está separado de decidir y aplicar, la dueña puede reescribir las normas de la casa y todas las decisiones cambian a la vez, sin redesplegar ningún PEP. Como la información está separada de la decisión, puedes añadir una fuente de atributos, una fuente de riesgo o un directorio nuevo, sin tocar la lógica de la política ni el código de aplicación. Y como todas las decisiones pasan por el PDP, hay un único sitio donde registrar quién pidió qué y qué se decidió, en lugar de reconstruirlo a partir de logs de aplicaciones repartidos. Cada costura permite que una preocupación cambie sin alterar las demás, y eso es lo que mantiene manejables los sistemas de autorización grandes.

Lo que evalúa el PDP

Hemos tratado “las normas” como una caja negra. XACML también les dio una estructura precisa, la misma anatomía que describía el artículo del PBAC, ahora con nombre formal. Una regla es la unidad más pequeña: un objetivo (target) que dice a qué peticiones se aplica, una condición opcional para una comprobación más fina y un efecto, Permit o Deny. En el club, “las socias oro pueden entrar” es una regla. Una política es un grupo de reglas con nombre sobre un área, con su propio algoritmo de combinación, como la sección de socios del libro de normas. Un conjunto de políticas agrupa políticas, y otros conjuntos, también con un algoritmo de combinación, como el libro entero dividido en capítulos.

La petición que llega al PDP también tiene estructura. Describe el sujeto (quién), el recurso (qué), la acción (qué operación) y el entorno (el contexto), las mismas cuatro categorías de atributos que presentó el artículo del ABAC. El PDP compara la petición con los objetivos del árbol de políticas para ver qué reglas se aplican, evalúa sus condiciones frente a los atributos y junta los resultados. Aquí van una petición y una regla en pseudoformato legible, sin el XML real de XACML, que ocuparía muchas veces más:

PETICIÓN                             REGLA  (efecto: Permit)
  subject.role   = "support-agent"     target:    action == "view"
  action         = "view"                          resource.type == "account"
  resource.type  = "account"           condition: subject.role == "support-agent"
  resource.id    = 4471                            AND ticket.open_for(resource) == true
  environment.time = 14:30                         AND environment.time in business_hours

El objetivo es el filtro barato que decide si la regla viene al caso, y viene, porque la acción es view sobre una account. La condición es la comprobación más fina frente a los atributos reunidos: ¿es el rol correcto, hay un ticket abierto, es horario laboral? El efecto es lo que ocurre si las dos pasan, Permit. Todas las reglas de todos los motores tienen estas tres partes, por distinta que sea la sintaxis, y por eso aprender la forma importa más que aprender un lenguaje. También plantea la pregunta que hace funcionar las políticas con varias reglas: ¿qué pasa cuando dos reglas encajan y no coinciden?

Algoritmos de combinación: resolver desacuerdos

En cuanto hay más de una regla, dos pueden encajar con la misma petición y no ponerse de acuerdo, una permitiendo y otra denegando. La respuesta de XACML es el algoritmo de combinación, una forma declarada y determinista de juntar muchas decisiones parciales en una. Cada política y cada conjunto de políticas tiene el suyo, y decide cómo se resuelven los conflictos y los huecos.

No es una nota al pie; es una decisión de seguridad real. Deny-overrides es la opción conservadora y garantiza que si cualquier regla rechaza, el acceso se rechaza, así que una concesión olvidada nunca abre en silencio algo que una denegación quería cerrar. Elegir permit-overrides le da la vuelta a esa seguridad, y first-applicable hace que el orden de las reglas importe de formas que pueden sorprenderte. Cuando evalúes un motor de políticas, una de las primeras preguntas es cuál es su comportamiento de combinación por defecto y si puedes razonar sobre lo que pasa en los huecos, porque ese comportamiento, y no una regla suelta, gobierna el conjunto.

La decisión no es solo sí o no

Un PDP XACML devuelve uno de cuatro valores, no un booleano, y juntarlos demasiado pronto es una fuente clásica de errores. Permit significa que el acceso se permite: que pase. Deny significa que se rechaza: que no entre. NotApplicable significa que ninguna política encajó con la petición: ninguna norma cubre esta situación. Indeterminate significa que la evaluación falló, por ejemplo porque faltaba un atributo: el archivista no encontró su ficha.

Cada uno pide un trato distinto. NotApplicable significa que el PDP no tiene opinión, y el PEP tiene que decidir qué hacer con ese silencio, que en seguridad casi siempre debería ser denegar por defecto, porque un hueco no es un permiso. Indeterminate significa que algo se rompió, el PIP no pudo aportar un atributo necesario o una política falló. Tratarlo como una denegación normal puede ocultar una caída o un error de configuración que merece una alerta, y tratarlo como un permiso es un agujero de seguridad. Un sistema maduro distingue “no se aplicó ninguna regla”, “una regla denegó” y “la evaluación falló”, y trata cada caso a propósito. Junto a la decisión, el PDP puede devolver además obligaciones y consejos, los extras de “permitir, pero regístralo” y “permitir y muestra un aviso” del artículo del PBAC, que el PEP tiene que cumplir.

El atajo más peligroso es reducir todo lo que no sea Permit a una única “denegación” y seguir adelante. Suele funcionar, y eso es lo que lo hace peligroso, hasta el día en que se cae una fuente de atributos, todas las peticiones vuelven como Indeterminate y tu “trátalo como denegación” convierte una caída de datos en un bloqueo total sin ninguna alerta o, si elegiste “trátalo como permiso para no afectar a la disponibilidad”, en una puerta abierta. Decide a propósito qué significan NotApplicable e Indeterminate en tu sistema, deja explícita la denegación por defecto y lanza una alerta ante Indeterminate en lugar de tragártelo.

El lenguaje se apagó, la arquitectura ganó

XACML trajo dos cosas: un lenguaje XML para escribir políticas y la arquitectura de cuatro piezas para evaluarlas. La historia las trató de forma muy distinta. El lenguaje era potente pero de una verbosidad legendaria, hasta el punto de que una regla de una línea en Rego podía ocupar decenas de líneas de XML anidado, y nunca se ganó a los desarrolladores; los sistemas nuevos casi nunca escriben XACML a pelo hoy. La arquitectura fue un triunfo discreto. La separación entre PEP, PDP, PIP y PAP, el flujo de petición y decisión, los algoritmos de combinación, las obligaciones, los cuatro valores de decisión: todo eso se convirtió en la base conceptual de prácticamente todos los motores de autorización construidos desde entonces.

Ya conocías el patrón con otros nombres. El artículo del PBAC presentó los puntos de aplicación y de decisión y describió OPA, Cedar y los servicios de autorización alojados como “un PEP pregunta, un PDP decide con una política externalizada y los datos llegan de varias fuentes”. Eso es la arquitectura XACML; aquellos artículos la estaban enseñando antes de nombrarla. Open Policy Agent es un PDP que gestionas tú, el cliente de OPA de tu app es el PEP, los datos que cargas en OPA hacen de PIP y tu repositorio de Rego y tu pipeline de CI son el PAP. Amazon Verified Permissions es un PDP gestionado que habla Cedar. En cuanto ves los cuatro papeles, cada producto se coloca solo en ellos, y aprender una herramienta de autorización nueva se reduce a averiguar cuál de los cuatro papeles hace y cómo.

Dónde viven los componentes

La arquitectura no dice nada a propósito sobre el despliegue, y los sistemas reales colocan el PDP de tres formas muy distintas, una elección con consecuencias reales en latencia, frescura y radio de impacto que desarrolla el artículo de la autorización descentralizada. El PDP puede ser una librería compilada dentro de la aplicación, lo más rápido, sin saltos de red, pero con una copia por app que mantener sincronizada. Puede ser un sidecar que corre junto a cada servicio, local y rápido y separado del código de la app, el patrón habitual en entornos nativos de nube, como OPA en modo sidecar. O puede ser un servicio central al que todas las apps llaman por red, un único decisor con autoridad, pero con una dependencia de red en el camino de la petición y otra pieza más que mantener siempre disponible. El PEP casi siempre está en la aplicación o en su pasarela, porque la aplicación tiene que ocurrir donde ocurre la acción; el PAP suele ser un sistema aparte de redacción y CI; y los PIP están allí donde ya vivan tus atributos. No hay una colocación correcta para todo, solo equilibrios entre velocidad, coherencia y acoplamiento. Los cuatro papeles son lógicos, no físicos: pueden juntarse en un solo proceso o repartirse por un continente, y reconocerlos consiste en ver los cuatro trabajos, no cuatro servidores distintos.

Sara en la app de cashback

Cambia el club por la fintech de cashback y la correspondencia es exacta. Sara, ahora agente de soporte, abre la consola y hace clic para ver la cuenta del cliente #4471. El PEP de la consola intercepta el clic y, en lugar de decidir nada, empaqueta una petición, sujeto Sara con rol support-agent, acción view, recurso cuenta #4471, y se la envía al PDP. El PDP carga la política que el equipo de seguridad escribió a través del PAP: un agente de soporte solo puede ver una cuenta si tiene un ticket abierto asignado para ella, en horario laboral. Como necesita datos, el PDP pide atributos, y los PIP aportan el rol y el turno de Sara desde el directorio, el registro del sistema de tickets según el cual el ticket #90210 está abierto y asignado a Sara para este cliente, y la hora actual. El PDP evalúa la regla, obtiene Permit y lo devuelve con la obligación de registrar el acceso. El PEP escribe la entrada de auditoría y muestra la cuenta. Repite el mismo flujo fuera del horario y devuelve Deny, y el mismo PEP bloquea la vista.

Fíjate en lo que gana la fintech. La misma política gobierna la app móvil, la consola web y la herramienta de revisión de fraude de mañana, porque cada una solo necesita un PEP que pregunte al PDP compartido. Cuando cumplimiento endurece la regla, el equipo de seguridad la edita una vez en el PAP y todas las superficies obedecen en segundos, sin redesplegar ninguna app. Cuando empieza a importar un atributo nuevo, por ejemplo una puntuación de riesgo del dispositivo, se añade en un PIP sin tocar ni una línea de política ni de código de aplicación. La arquitectura no solo respondió a la petición de Sara; hizo que todo el sistema se pudiera cambiar, y a gran escala eso importa todavía más que cualquier decisión suelta.

Resumen

La arquitectura de referencia de XACML es el plano que hay debajo de casi cualquier sistema de autorización. Tiene cuatro papeles bien separados: el PEP pregunta y aplica, el PDP decide, el PIP aporta los hechos y el PAP escribe las normas de antemano, con un gestor de contexto que lleva peticiones y atributos entre ellos. Una petición los recorre en orden: el PEP la reenvía, el PDP evalúa la política publicada antes a través del PAP, saca de los PIP los atributos que necesita y devuelve una decisión que aplica el PEP. La separación es la recompensa: un decisor sirve con coherencia a muchos aplicadores, las normas cambian sin redesplegar apps, las fuentes de datos cambian con libertad y cada decisión se audita en un solo sitio. Las políticas se estructuran como reglas con objetivo, condición y efecto, dentro de políticas dentro de conjuntos de políticas, con algoritmos de combinación que resuelven los conflictos, una elección de seguridad real, y las decisiones tienen cuatro valores y no un simple booleano. Y el lenguaje XML se apagó mientras la arquitectura ganaba en todas partes: OPA, Cedar, Verified Permissions y el IAM de la nube siguen este patrón.

Tres preguntas para ponerte a prueba

1. Con el club, explica la diferencia entre el PEP y el PDP, y por otro lado entre el PIP y el PAP. Para cada pareja, da la pista de una frase que las mantiene separadas.
2. Llega una petición, encajan dos reglas, una permite y otra deniega, y la política usa deny-overrides. ¿Cuál es el resultado y por qué la elección del algoritmo de combinación es una decisión de seguridad y no un detalle técnico? ¿Qué cambiaría con first-applicable?
3. Un PDP devuelve Indeterminate porque un PIP no pudo aportar un atributo necesario. Explica por qué convertir eso en denegar puede ser peligroso, por qué convertirlo en permitir es peor y qué debería hacer un PEP maduro con NotApplicable frente a Indeterminate.

Ejercicios prácticos

1. Lleva un sistema que uses a los cuatro papeles. Elige una plataforma con autorización externalizada, como Kubernetes con OPA Gatekeeper, una service mesh o un servicio de autorización en la nube. Identifica qué hace de PEP, de PDP, de PIP y de PAP, y dónde se guarda la política. Si falta un papel o está fundido con otro, anótalo; eso dice algo de los equilibrios del sistema.
2. Sigue una petición sobre el papel. Toma la regla de la fintech (un agente de soporte solo puede ver una cuenta con un ticket abierto asignado, en horario laboral) y escribe en orden los mensajes entre PEP, gestor de contexto, PDP, PIP y PAP para un caso que dé Permit y otro que dé Deny. Marca qué paso ocurre en la preparación y cuáles en el momento de la petición.
3. Elige algoritmos de combinación a propósito. Escribe en lenguaje llano tres reglas para un recurso en el que al menos dos puedan aplicarse a la misma petición, y calcula el resultado con deny-overrides, permit-overrides y first-applicable. Fíjate en dónde no coinciden; ese hueco es justo la decisión de seguridad que toma por ti el algoritmo de combinación.