XACML: el estándar empresarial de control de acceso y su modelo PEP/PDP/PAP/PIP
XACML no ganó la guerra de la sintaxis, pero su arquitectura conceptual PEP/PDP/PAP/PIP sigue siendo la referencia implícita de todo motor de política moderno. Entender XACML es entender por qué OPA, OpenFGA y Cedar resuelven el mismo problema con la misma forma, solo con una sintaxis más humana.
La mayoría de arquitectos que nunca han escrito una línea de XACML están usando todos los días su modelo conceptual sin saberlo. Cuando un motor moderno distingue entre quien intercepta la solicitud, quien decide, quien gestiona las políticas y quien aporta atributos, está reproduciendo la arquitectura que OASIS formalizó hace más de dos décadas. Este artículo forma parte de la serie La evolución de la seguridad en aplicaciones modernas.
Por qué importa un estándar que perdió en sintaxis
XACML (eXtensible Access Control Markup Language) fue publicado por OASIS en 2003 con su versión 1.0 y alcanzó la forma que hoy se estudia en XACML 3.0 en enero de 2013. Durante la primera década del siglo fue el estándar de referencia para ABAC (Attribute-Based Access Control) en grandes organizaciones, especialmente en banca, telco, defensa y administración pública.
La historia posterior es conocida: Rego de OPA, Cedar de AWS y los DSL de OpenFGA le comieron el terreno. La sintaxis XML pesada, la curva de aprendizaje y la dificultad de depurar políticas extensas hicieron que los equipos nuevos eligieran alternativas más ergonómicas. Pero lo que se abandonó fue la sintaxis, no el modelo. El modelo PEP/PDP/PAP/PIP sobrevive intacto en todos los motores modernos, a veces con nombres distintos, siempre con la misma estructura.
Entender XACML conceptualmente es entender por qué cualquier arquitectura seria de autorización separa las mismas cuatro responsabilidades. Y es entender también qué herencias operativas tiene la industria cuando una organización grande sigue ejecutando PDPs XACML en producción porque nada ha roto todavía lo bastante como para justificar migrar.
Los cuatro componentes
PEP: Policy Enforcement Point
El PEP es el componente que intercepta la solicitud al recurso y aplica la decisión. No decide nada: su única responsabilidad es detener el flujo, construir una solicitud estructurada (sujeto, recurso, acción, entorno), consultar al PDP y actuar según el veredicto. En una arquitectura web clásica, el PEP vive en el API Gateway, en un filtro del framework o en un sidecar del service mesh. En Kubernetes, el API server se comporta como PEP cuando consulta un webhook de admisión.
La disciplina que XACML impuso aquí fue clara: el PEP no tiene lógica de autorización, tiene lógica de enforcement. Esta separación es lo que permite cambiar de modelo de autorización sin tocar el código de aplicación.
PDP: Policy Decision Point
El PDP recibe la solicitud y evalúa las políticas aplicables contra sus atributos. Devuelve una de cuatro respuestas: Permit, Deny, NotApplicable (ninguna política se aplica) o Indeterminate (error durante la evaluación). Esta tetralogía es importante: confundir NotApplicable con Deny o con Permit es el tipo de decisión implícita que, mal tomada, abre o cierra accesos de forma inesperada.
Un PDP XACML evalúa políticas agrupadas en PolicySets, cada uno con un Target (qué solicitudes se aplican) y Rules combinadas mediante un rule-combining algorithm. El modelo conceptual del PDP es idéntico al de un motor OPA o Cedar moderno: entrada estructurada, cuerpo de reglas, decisión como salida.
PAP: Policy Administration Point
El PAP es el componente CRUD sobre las políticas: las crea, las versiona, las publica y las retira. En XACML se imaginó como una consola administrativa para seguridad corporativa; en motores modernos suele materializarse como un pipeline GitOps donde las políticas viven en un repositorio, pasan revisión, se empaquetan como bundles y se distribuyen a los PDPs.
La virtud del PAP como concepto separado es que el ciclo de vida de la política es explícito: nadie edita reglas en caliente, hay trazabilidad de quién cambió qué y cuándo, y la política es un artefacto con versión, revisión y firma.
PIP: Policy Information Point
El PIP es la fuente externa de atributos que el PDP consulta cuando la solicitud no trae todo lo necesario. Si una política dice “permitir si el empleado pertenece al departamento de cardiología”, y la solicitud solo incluye el identificador del usuario, el PDP pregunta al PIP correspondiente —normalmente el sistema de RRHH o un LDAP— qué departamento le corresponde.
La existencia del PIP como concepto independiente resolvió un problema real: los atributos relevantes raramente viven en el mismo sistema. Separarlo del PDP permite cachearlos, tolerar su indisponibilidad con degradación controlada y versionar su esquema sin rehacer las políticas.
El flujo de decisión completo
Una solicitud entra al PEP, que construye la XACML Request y la envía al PDP. El PDP carga las políticas publicadas por el PAP, evalúa los Targets para descartar las no aplicables, resuelve los atributos que le faltan consultando al PIP y ejecuta las reglas restantes bajo el algoritmo de combinación definido. Devuelve un Decision junto con, opcionalmente, Obligations y Advice.
Las obligaciones son instrucciones que el PEP debe cumplir si quiere respetar la decisión: registrar un log de auditoría, cifrar la respuesta, notificar al propietario del recurso. El advice es similar pero no vinculante: una sugerencia que el PEP puede o no seguir. Esta distinción, aparentemente menor, es lo que permite que una política diga “permitir, pero registra esta acción como sensible” sin que el logging quede fuera del ámbito del sistema de políticas.
Ignorar obligaciones es la forma elegante de violar una política mientras se respeta la decisión. El PEP debe fallar closed si no puede cumplirlas.
Algoritmos de combinación
Cuando varias reglas son aplicables y dan veredictos distintos, hay que combinarlas. XACML 3.0 define los algoritmos que han pasado al vocabulario general: permit-overrides (un Permit gana frente a cualquier Deny), deny-overrides (un Deny gana), first-applicable (la primera regla que decida gana, útil para políticas ordenadas con excepciones al principio) y ordered-permit-overrides y sus duales, que añaden determinismo al orden de evaluación.
La elección del algoritmo de combinación tiene consecuencias de seguridad directas. Permit-overrides en un conjunto de políticas donde hay reglas de denegación regulatoria es una receta para auditorías fallidas: basta una regla permisiva mal escrita para que todo lo demás sea irrelevante. Deny-overrides es la opción conservadora y la que casi todos los motores modernos recomiendan por defecto.
Por qué el XML perdió
La crítica al XACML rara vez es contra el modelo. Es contra el lenguaje. Una política XACML trivial ocupa docenas de líneas de XML anidado con namespaces, atributos tipados explícitamente y referencias entre elementos por identificador. Escribir, revisar y mantener ese volumen de sintaxis es costoso, y los editores tradicionalmente no han ayudado tanto como en lenguajes modernos con tipado fuerte y autocompletado decente.
El rendimiento del PDP tradicional también sufrió en arquitecturas de alta frecuencia. El coste de parsear XML, instanciar árboles DOM y recorrerlos en cada evaluación era aceptable para transacciones empresariales con SLOs de cientos de milisegundos, pero inviable en un service mesh con objetivo sub-milisegundo. Muchos motores comerciales optimizaron esto con caches de políticas compiladas, pero el punto de partida jugaba en contra.
Las alternativas modernas
Rego, Cedar, OpenFGA DSL y otras sintaxis recientes son, conceptualmente, XACML sin el XML. Rego expresa reglas como cláusulas declarativas al estilo Datalog; Cedar apuesta por un lenguaje diseñado para ser analizable formalmente; OpenFGA usa relaciones tipadas en vez de condiciones lógicas. Los tres mantienen la separación PEP/PDP y muchos conservan el concepto de PIP (datos externos cargados en el PDP) y PAP (pipeline de publicación).
Dónde sigue vivo XACML
La desaparición anunciada de XACML no ha ocurrido, y no va a ocurrir pronto, en dominios donde los ciclos de renovación tecnológica son largos. Grandes bancos, operadores telco, administraciones públicas y ministerios de defensa tienen PDPs XACML con años de políticas acumuladas que pasan auditoría tras auditoría. El coste de migrar —rehacer cada política, revalidar cada decisión, certificar el nuevo motor bajo los mismos estándares— raramente compensa.
Axiomatics, NextLabs y unos pocos vendors más siguen vendiendo PDPs XACML comerciales con herramientas de modelado, simulación y análisis formal de políticas. Para organizaciones donde el regulador exige explicabilidad formal de cada decisión, el ecosistema XACML ofrece garantías que las alternativas más jóvenes aún están construyendo.
Patrones de migración
Cuando la migración sí ocurre, el patrón común es traducir las políticas XACML a Rego o Cedar manteniendo el modelo ABAC, reemplazar el PDP pieza a pieza tras un periodo de doble escritura donde ambos motores evalúan la misma solicitud y se comparan los veredictos, y finalmente retirar el PDP antiguo cuando la divergencia observada se mantiene por debajo de un umbral durante un tiempo suficiente. El paralelo con una migración de base de datos es casi perfecto.
Migrar un PDP XACML en producción sin doble evaluación durante meses es un salto al vacío con consecuencias regulatorias.
Cómo encaja con el resto de la arquitectura
El modelo XACML es el vocabulario común de toda la serie. Cuando hablamos de un motor de política como OPA, CASBIN u OpenFGA, estamos hablando de un PDP moderno. Cuando describimos el control de admisión de Kubernetes, el API server es el PEP y Gatekeeper o Kyverno son el PDP. Cuando comparamos modelos RBAC, ABAC y ReBAC, estamos discutiendo qué tipo de reglas carga ese PDP. Y cuando separamos autenticación de autorización, lo que defendemos es que la autorización viva en un PDP y no repartida por el código. XACML perdió la sintaxis pero ganó la arquitectura.
Artículos relacionados en esta serie
Referencias
- OASIS (2003). eXtensible Access Control Markup Language (XACML) Version 1.0.
- OASIS (enero 2013). eXtensible Access Control Markup Language (XACML) Version 3.0.
- NIST SP 800-162 (2014). Guide to Attribute Based Access Control (ABAC) Definition and Considerations.
- Axiomatics (2018-2023). XACML in the Enterprise. Whitepapers.
- AWS (2023). Cedar Language Guide.