El Modelo XACML: PEP, PDP, PIP y PAP

De “qué decidir” a “cómo construir al decisor”

Todo el módulo anterior respondía una pregunta: ¿en qué debe basarse una decisión de acceso? Dueños, etiquetas, roles, atributos, políticas, relaciones — seis respuestas, un eje. Este nuevo módulo gira noventa grados hacia una pregunta distinta: decidas como decidas, ¿cómo construyes de verdad la máquina que decide? ¿Cuáles son sus partes, quién habla con quién y dónde vive la política? La respuesta a la que convergió toda la industria tiene un nombre — la arquitectura de referencia de XACML — y una vez que puedes ver sus cuatro componentes en cualquier sistema, todo producto de autorización que encuentres deja de ser un misterio y se vuelve una variación de un mismo plano familiar.

XACML significa eXtensible Access Control Markup Language, un estándar de OASIS de mediados de la década de 2000. Aquí está el giro que lo hace merecer un artículo entero: el lenguaje de XACML — su verbosa sintaxis XML — es hoy en gran medida legado, desplazado por sucesores más amables. Pero la arquitectura de XACML — la forma en que divide un sistema de autorización en cuatro roles que cooperan — triunfó por completo. Open Policy Agent, AWS Cedar, Amazon Verified Permissions, los motores estilo Zanzibar, el IAM de tu nube: asómate dentro de cualquiera de ellos y encuentras las mismas cuatro partes haciendo los mismos cuatro trabajos. Así que estudiamos XACML no para escribir su XML, sino porque nos dio el vocabulario y la forma que comparte toda la autorización moderna. Apréndelo una vez, y podrás leerlos todos.

Como estos cuatro componentes tienen siglas poco amigables — PEP, PDP, PIP, PAP — vamos a conocerlos primero como personas, mediante una analogía, y solo después les pondremos los nombres técnicos. Es el camino más rápido para no volver a confundirlos jamás.

La analogía: entrar a un local de socios

Imagina que Sara quiere entrar a un club de socios exclusivo. Cuatro personas distintas, con cuatro trabajos distintos, determinan juntas si consigue entrar — y, crucialmente, ninguna persona hace más de un trabajo. Esa separación es la arquitectura.

Conoce al reparto:

• El Portero está en la entrada. Cuando Sara llega, el Portero la detiene y — según la respuesta que reciba — o se aparta para dejarla entrar o la bloquea. Fíjate en lo que el Portero no hace: no conoce las reglas de socios, no busca a nadie y no decide. Solo pregunta y aplica. Es el Punto de Aplicación de Políticas (PEP).
• El Gerente, en una oficina trasera, es quien realmente decide. El Portero avisa “hay una tal Sara aquí — ¿tiene permiso para entrar?”, y el Gerente, consultando las reglas del club, responde “permite” o “deniega”. El Gerente sostiene la lógica, no la puerta. Es el Punto de Decisión de Políticas (PDP).
• El Archivista guarda los expedientes. Para decidir, el Gerente a menudo necesita hechos que no tiene a mano: ¿La membresía de Sara está vigente? ¿De qué nivel es? ¿Es mayor de 18? Se los pide al Archivista, que los busca e informa. El Archivista suministra información, nada más. Es el Punto de Información de Políticas (PIP).
• El Dueño escribió las reglas de la casa — “los socios de nivel oro entran a cualquier hora, los de plata antes de las 22h, nadie menor de 18” — y se las entregó al Gerente antes de que el club siquiera abriera esta noche. El Dueño crea las reglas, con antelación, y no está cerca de la puerta durante la llegada de Sara. Es el Punto de Administración de Políticas (PAP).

Ese es todo el modelo. Cuatro roles, limpiamente separados: uno aplica, uno decide, uno informa, uno crea. Cada sigla confusa de abajo es solo una de estas cuatro personas. Ten el local en la cabeza y nunca los mezclarás.

Los cuatro componentes, con precisión

Ahora podemos ser exactos. Aquí está cada componente, su analogía, su única responsabilidad y — igual de importante para evitar confusiones — lo que deliberadamente no hace.

Unos pocos matices completan el cuadro. Entre el PEP y el PDP suele haber un manejador de contexto — el mensajero que traduce la solicitud de la aplicación al formato que el PDP espera, reúne los atributos que el PDP pide llamando a los PIP, y lleva la decisión de vuelta. Piénsalo como el asistente del Gerente que corre entre la oficina, la puerta y el archivo para que el Gerente pueda concentrarse en decidir. XACML también nombra un Punto de Recuperación de Políticas (PRP), el almacén desde el que el PDP carga las políticas — el estante donde reposa el libro de reglas del Dueño. No siempre verás estos dos mencionados explícitamente, pero están implícitos allí donde aparecen los cuatro roles principales.

Ver una solicitud fluir por la máquina

Los roles se ven más claros en movimiento. Sigue una solicitud — Sara pide entrar — mientras viaja por los cuatro componentes y regresa como una decisión. La secuencia de abajo es exactamente lo que ocurre dentro de un sistema estilo XACML, con las etiquetas del local al lado para que ambos queden soldados.

sequenceDiagram
  accTitle: Cómo fluye una solicitud de acceso por la arquitectura de referencia de XACML
  accDescr: El diagrama muestra el flujo ordenado de mensajes para una única solicitud de autorización. Primero, el Punto de Administración de Políticas publica políticas al motor de decisión con antelación, marcado como configuración. Luego Sara envía una solicitud de acceso al Punto de Aplicación de Políticas. El punto de aplicación reenvía la solicitud al manejador de contexto, que pide una decisión al Punto de Decisión de Políticas. El punto de decisión carga la política aplicable y, al necesitar más hechos, pide atributos a través del manejador de contexto, que consulta al Punto de Información de Políticas y devuelve atributos de sujeto, recurso y entorno. El punto de decisión evalúa la política contra la solicitud y los atributos, luego devuelve permite o deniega al manejador de contexto, que 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 solicitud en vivo.
  participant U as Sara
  participant PEP as PEP (Portero)
  participant CH as Manejador de contexto
  participant PDP as PDP (Gerente)
  participant PIP as PIP (Archivista)
  participant PAP as PAP (Dueño)
  PAP-->>PDP: publica políticas (configuración, antes de la solicitud)
  U->>PEP: solicita acceso
  PEP->>CH: reenvía la solicitud
  CH->>PDP: ¿decide?
  PDP->>CH: necesito atributos
  CH->>PIP: obtén sujeto / recurso / entorno
  PIP-->>CH: atributos
  CH-->>PDP: atributos
  PDP->>PDP: evalúa la política
  PDP-->>CH: permite / deniega
  CH-->>PEP: permite / deniega
  PEP-->>U: permite o bloquea

Léelo como una historia. Con antelación, el Dueño (PAP) publica las reglas al Gerente (PDP) — este es el paso discontinuo de configuración, y es la única parte que no ocurre durante la solicitud de Sara. Luego Sara le pide al Portero (PEP) entrar. El Portero no razona; reenvía la solicitud al asistente del Gerente (manejador de contexto), que pide al Gerente (PDP) que decida. El Gerente saca la regla relevante, se da cuenta de que necesita hechos y pide los atributos de Sara; el asistente los obtiene del Archivista (PIP) y los trae de vuelta. El Gerente evalúa la regla contra la solicitud y los hechos, produce “permite” o “deniega”, y lo envía de vuelta por la cadena hasta el Portero, que finalmente abre o bloquea la puerta. Cada componente hizo exactamente un trabajo, y la solicitud tocó a cada uno por turno.

¿Por qué dividirlo en cuatro? El beneficio de la separación

Esto puede parecer burocracia — ¿por qué no dejar que un componente lo haga todo? Porque la separación compra propiedades que no puedes conseguir de otra forma, y son los mismos beneficios que prometía el artículo de PBAC, ahora con una estructura concreta.

Un decisor, muchas puertas. Como decidir está separado de aplicar, un único PDP puede servir a decenas de PEP — cada aplicación, servicio y gateway le pregunta al mismo Gerente, así que todos aplican las mismas reglas de forma idéntica. La consistencia deja de ser una esperanza y se vuelve una propiedad de la arquitectura. Cambiar reglas sin tocar apps. Como crear las reglas (PAP) está separado de decidir y aplicar, el Dueño puede reescribir las reglas de la casa y toda decisión cambia a la vez, sin redesplegar ningún PEP. Intercambiar fuentes de datos libremente. Como la información (PIP) está separada de la decisión, puedes añadir una nueva fuente de atributos — un feed de riesgo, un nuevo directorio — sin cambiar la lógica de política ni el código de aplicación. Y auditar en un solo lugar: como todas las decisiones fluyen por el PDP, hay un único punto donde registrar “quién pidió qué, y qué se decidió”, en lugar de reconstruirlo desde registros de aplicación dispersos. Cada costura de la arquitectura está ahí para dejar que un interés cambie sin perturbar a los otros — que es exactamente lo que hace mantenibles a los grandes sistemas de autorización.

Qué evalúa realmente el PDP: la estructura de la política

Hemos tratado “las reglas” como una caja negra; XACML también nos dio una estructura precisa para ellas, y es la misma anatomía que viste en el artículo de PBAC, ahora nombrada formalmente. El libro de reglas es una jerarquía anidada:

Una solicitud que llega al PDP está igualmente estructurada — 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 introdujo el artículo de ABAC. El PDP empareja esta solicitud contra los targets del árbol de políticas para hallar qué reglas aplican, evalúa sus condiciones contra los atributos y pliega los resultados juntos. Para hacerlo concreto, aquí hay una solicitud y una regla en pseudo-forma legible — despojada del XML real de XACML, que sería muchas veces más largo:

SOLICITUD                            REGLA  (efecto: Permit)
  subject.role   = "support-agent"     target:    action == "view"
  action         = "view"                          resource.type == "account"
  resource.type  = "account"           condición: subject.role == "support-agent"
  resource.id    = 4471                            Y ticket.open_for(resource) == true
  environment.time = 14:30                         Y environment.time en horario_laboral

El target es el filtro barato que decide si esta regla es siquiera relevante para la solicitud (lo es — la acción es view sobre una account); la condición es la prueba más fina evaluada contra los atributos reunidos (¿es correcto el rol de Sara, hay un ticket abierto, es horario laboral?); y el efecto es lo que ocurre si ambos pasan (Permit). Toda regla en todo motor que encuentres tiene estas mismas tres partes, por muy distinta que sea la sintaxis — que es exactamente por qué aprender la forma importa más que aprender un lenguaje concreto. Esto también expone la pieza que hace que las políticas de varias reglas funcionen de verdad: ¿qué ocurre cuando dos reglas coinciden y discrepan?

Algoritmos de combinación: resolver el desacuerdo

Aquí hay un problema que aparece en cuanto tienes más de una regla: dos reglas coinciden con la misma solicitud y discrepan — una dice Permit, la otra dice Deny. ¿Cuál gana? La respuesta de XACML es el algoritmo de combinación, una regla declarada y determinista para plegar muchas subdecisiones en una. Adjuntas un algoritmo de combinación a cada política y conjunto de políticas, y él decide cómo se resuelven conflictos y huecos.

Esto no es una nota al pie; es una genuina decisión de seguridad. deny-overrides es la elección conservadora — garantiza que si cualquier regla se niega, el acceso se niega, así que una concesión olvidada nunca abre en silencio algo que una denegación pretendía cerrar. Elegir permit-overrides en su lugar invierte la postura de seguridad, y elegir first-applicable hace que el orden de las reglas sea significativo de un modo que puede sorprenderte. Siempre que evalúes un motor de políticas, una de las primeras preguntas que hacer es “¿cuál es el comportamiento de combinación por defecto, y puedo razonar sobre qué pasa en los huecos?” — porque ese comportamiento, y no ninguna regla individual, gobierna el todo.

La decisión no es solo sí o no

Una lección sutil pero importante: un PDP de XACML devuelve uno de cuatro valores, no un booleano. Colapsarlos demasiado pronto es una fuente clásica de fallos.

La distinción importa porque cada valor requiere un manejo distinto. NotApplicable significa que el PDP no tiene opinión — nada coincidió — y es tarea del PEP decidir cómo tratar el silencio, que por seguridad casi siempre debería ser denegar por defecto (un hueco no es permiso). Indeterminate significa que algo se rompió — el PIP no pudo suministrar un atributo requerido, o una política dio error — y tratar eso como un simple “deniega” puede enmascarar una caída o una mala configuración que merece una alerta, mientras que tratarlo como “permite” es un agujero de seguridad. Un sistema maduro distingue “ninguna regla aplicó”, “una regla denegó” y “la evaluación falló”, y maneja cada caso deliberadamente. Junto a la decisión, el PDP también puede devolver obligaciones y consejos — los extras “permite, pero regístralo” y “permite, y muestra un aviso” que viste en el artículo de PBAC — que el PEP es responsable de llevar a cabo.

XACML el lenguaje frente a XACML la arquitectura

Ahora el encuadre crucial que hace que todo este artículo rinda. XACML entregó dos cosas: un lenguaje XML para escribir políticas, y la arquitectura de cuatro componentes para evaluarlas. La historia las trató de forma muy distinta. El lenguaje XML era potente pero notoriamente verboso — una regla que se lee como una línea de Rego podía desparramarse por decenas de líneas de XML anidado — y nunca ganó el corazón de los desarrolladores; los sistemas nuevos casi nunca escriben XACML crudo hoy. Pero la arquitectura fue un triunfo silencioso. La separación PEP/PDP/PIP/PAP, el flujo solicitud-decisión, los algoritmos de combinación, las obligaciones, la decisión de cuatro valores — estos se volvieron la base conceptual de esencialmente todo motor de autorización construido desde entonces.

Dónde viven los componentes en sistemas reales

La arquitectura es abstracta sobre el despliegue a propósito, y los sistemas reales colocan el PDP de tres formas ampliamente distintas — una elección con consecuencias reales para la latencia, la frescura y el radio de impacto que el artículo de autorización descentralizada desarrolla en detalle. El PDP puede ser una biblioteca compilada dentro de la aplicación (lo más rápido, sin salto de red, pero una copia por app que mantener sincronizada), un sidecar que corre junto a cada servicio (local y rápido, desacoplado del código de la app — el patrón cloud-native común, p. ej. OPA como sidecar), o un servicio central al que toda app llama por la red (un decisor autoritativo único, pero con una dependencia de red en el camino de la solicitud y una sola cosa que mantener altamente disponible). El PEP casi siempre está dentro de la aplicación o su gateway, porque la aplicación debe ocurrir donde ocurre la acción; el PAP suele ser un sistema separado de autoría y CI; y los PIP están donde ya viven tus atributos. No hay una colocación universalmente correcta — solo compromisos entre velocidad, consistencia y acoplamiento, las mismas tensiones que todo este dominio no deja de rodear. La lección es que los cuatro roles son lógicos, no físicos: pueden colapsar en un solo proceso o extenderse por un continente, y reconocerlos consiste en detectar los cuatro trabajos, no cuatro servidores separados.

Un ejemplo resuelto: Sara en la app de cashback

Cambia el local por la fintech recurrente y el mapeo se mantiene exacto. Sara, una agente de soporte, abre la consola y hace clic para ver la cuenta de cliente n.º 4471. El PEP de la consola intercepta el clic y, en vez de decidir nada por sí mismo, empaqueta una solicitud — sujeto: Sara (rol support-agent); acción: view; recurso: cuenta n.º 4471 — y la envía al PDP. El PDP carga la política de autorización que el equipo de seguridad creó mediante el PAP (“un agente de soporte puede ver una cuenta solo si tiene un ticket abierto asignado para ella, en horario laboral”). Al ver que necesita hechos, el PDP pide atributos: el PIP suministra el rol y el turno de Sara desde el directorio, el registro del sistema de tickets de que el ticket n.º 90210 está abierto y asignado a Sara para este cliente, y la hora actual desde el entorno. El PDP evalúa la regla contra estos, obtiene Permit, y lo devuelve — con una obligación de registrar el acceso. El PEP recibe Permit, cumple la obligación escribiendo la entrada de auditoría, y renderiza la cuenta. Cambia el escenario a fuera de horario, y el mismo flujo devuelve Deny; el mismo PEP ahora bloquea la vista. Una política, un decisor, muchos aplicadores posibles — y cada parte de esa frase es un componente de XACML.

Fíjate en lo que esto le compra a la fintech. La política idéntica 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 le pregunte al PDP compartido. Cuando el cumplimiento endurece la regla, el equipo de seguridad la edita una vez en el PAP y toda superficie obedece en segundos, sin redesplegar ninguna app. Cuando un nuevo atributo se vuelve relevante — digamos una puntuación de riesgo del dispositivo — se añade en un PIP sin tocar una línea de política ni de código de aplicación. La arquitectura no solo respondió la solicitud de Sara; hizo el sistema entero cambiable, lo que a escala importa aún más que cualquier decisión individual.

Recapitulación

La arquitectura de referencia de XACML es el plano bajo esencialmente todo sistema de autorización:

1. Cuatro roles, limpiamente separados. El PEP (Portero) pregunta y aplica, el PDP (Gerente) decide, el PIP (Archivista) suministra hechos, y el PAP (Dueño) crea las reglas con antelación — con un manejador de contexto llevando solicitudes y atributos entre ellos.
2. Una solicitud fluye por ellos en orden: el PEP reenvía la solicitud, el PDP evalúa la política (publicada antes por el PAP), extrae atributos de los PIP según los necesita, y devuelve una decisión que el PEP aplica.
3. La separación es el beneficio: un decisor sirve a muchos aplicadores de forma consistente, las reglas cambian sin redesplegar apps, las fuentes de datos se intercambian libremente, y toda decisión se audita en un solo lugar.
4. Las políticas están estructuradas como reglas (target, condición, efecto) dentro de políticas dentro de conjuntos de políticas, con algoritmos de combinación (deny-overrides y compañía) resolviendo conflictos — una decisión de seguridad real — y las decisiones vienen en cuatro valores (Permit, Deny, NotApplicable, Indeterminate), no un simple booleano.
5. El lenguaje XML se apagó, pero la arquitectura triunfó en todas partes. OPA, Cedar, Verified Permissions y el IAM de la nube son todos este patrón — así que aprende XACML por su forma, que es universal, no por su sintaxis, que rara vez escribirás.

Tres preguntas para autoevaluarte

1. Usando la analogía del local, explica la diferencia entre el PEP y el PDP, y por separado entre el PIP y el PAP. Para cada par, da la pista de una frase que los mantiene claros (“hechos-ahora frente a reglas-antes”, y demás).
2. Llega una solicitud, dos reglas coinciden, una Permit y otra Deny, y la política usa deny-overrides. ¿Cuál es el resultado, y por qué la elección del algoritmo de combinación se describe como una decisión de seguridad en vez de un detalle técnico? ¿Qué cambiaría con first-applicable?
3. Un PDP devuelve Indeterminate porque un PIP no pudo suministrar un atributo requerido. Explica por qué colapsar esto a “deniega” puede ser peligroso, por qué colapsarlo a “permite” es peor, y qué debería hacer un PEP maduro con NotApplicable frente a Indeterminate.

Ejercicios prácticos

1. Mapea a los cuatro roles un sistema que uses. Elige cualquier plataforma con autorización externalizada (Kubernetes con OPA/Gatekeeper, un service mesh, un servicio de autorización en la nube). Identifica en concreto qué hace de PEP, de PDP, de PIP y de PAP, y dónde se guarda la política. Si algún rol falta o está fusionado en otro, anótalo — eso te dice algo sobre los compromisos del sistema.
2. Traza una solicitud en papel. Toma la regla del cashback (“un agente de soporte puede ver una cuenta solo con un ticket abierto asignado, en horario laboral”) y escribe los mensajes ordenados entre PEP, manejador de contexto, PDP, PIP y PAP para un caso Permit y un caso Deny. Marca qué paso es de tiempo de configuración y cuáles de tiempo de solicitud.
3. Elige algoritmos de combinación deliberadamente. Escribe tres reglas en lenguaje llano para un recurso donde al menos dos puedan aplicar a la misma solicitud, luego decide el resultado bajo deny-overrides, permit-overrides y first-applicable. Anota dónde discrepan los tres — ese hueco es exactamente la decisión de seguridad que el algoritmo de combinación toma por ti.