Modelos de autorización: ACL, RBAC, ABAC y ReBAC

El permiso no está en el login

Northstar Systems procesa pagos de proveedores. Elena inicia sesión en el portal de tesorería y solicita approve sobre payment-882, una transferencia de 8.400 euros del tenant northstar-eu. El registro de identidad de la sesión es correcto y el segundo factor fue verificado. Aun así, la decisión profesional no es «Elena puede aprobar»: hay que determinar qué sujeto representa la sesión, qué acción concreta pide, qué objeto se modifica, qué contexto acompaña la petición, qué política está vigente y dónde se aplica el resultado.

La autorización es el proceso que decide si un principal puede realizar una acción sobre un objeto bajo condiciones declaradas. La autenticación del capítulo 37 aporta una atribución operativa; no convierte esa atribución en permiso. La sesión mantiene continuidad y estado, pero su ciclo de vida se estudia en el capítulo 41. Los protocolos que transportan credenciales federadas y delegaciones se verán en el capítulo 45. Aquí se estudia el mecanismo que transforma una petición ya atribuida en una decisión y en un enforcement observable.

Resultado de aprendizaje

Al terminar, el lector debe poder:

• formalizar una solicitud como (sujeto, acción, objeto, contexto, sesión) y separar decisión de enforcement;
• reconstruir una decisión basada en lista de control de acceso (ACL), incluyendo valores por defecto, precedencia, herencia y combinación de entradas;
• distinguir usuario, rol, permiso y sesión activa en control de acceso basado en roles (RBAC), y analizar jerarquías y separación de funciones;
• evaluar un control de acceso basado en atributos (ABAC) atendiendo a atributos del sujeto, objeto, acción y entorno, así como a procedencia, frescura y errores del proveedor;
• modelar un control de acceso basado en relaciones (ReBAC) como un grafo con evaluación recursiva, ciclos, consistencia, caché y revocación;
• diseñar una composición híbrida que declare qué modelo responde a cada parte de la política, sin asumir que uno domina universalmente a los demás;
• diagnosticar qué ocurre cuando el punto de decisión permite pero el punto de enforcement falla o cuando los datos usados por la decisión son obsoletos.

Una petición, una decisión y dos puntos de control

Usaremos esta representación mínima:

request = (s, a, o, c, session)
decision = evaluate(policy, request, inputs)
enforcement = PEP.apply(decision, request)

s es el principal efectivo; a, la operación —por ejemplo approve, no sólo «acceder»—; o, el objeto y su tenant; c, el contexto como región, hora, importe o estado del dispositivo; session, la continuidad que enlaza la petición con el evento de autenticación. policy contiene reglas y prioridades. inputs contiene identidades, relaciones y atributos, cada uno con una autoridad y un tiempo de observación.

El policy decision point (PDP, punto de decisión de política) evalúa esos datos y devuelve un resultado. El policy enforcement point (PEP, punto de enforcement de política) bloquea o deja pasar la operación. El policy information point (PIP, punto de información de política) obtiene atributos y relaciones que el PDP necesita. El policy administration point (PAP, punto de administración de política) crea, modifica y versiona políticas. NIST presenta estas funciones en §2.4.3, «Access Control Mechanism Distribution in Enterprise ABAC» (Figura 5 y definiciones de PDP, PEP, PIP y PAP). NIST también describe un Context Handler opcional; aquí se omite para mantener el modelo mínimo. Una implementación puede colocar varias funciones en un mismo servicio, pero esa co-ubicación es una decisión arquitectónica, no un requisito de NIST. NIST SP 800-162 upd2, §2.4.3

La separación tiene una consecuencia práctica. Un PDP que devuelve permit no ha ejecutado el pago. Si el PEP aplica permit a otro objeto, ignora el tenant o falla abierto al perder conectividad, la garantía de la política no llega al recurso. Si el PIP entrega employment=active desde una copia de hace dos horas, el PDP puede razonar correctamente sobre un dato incorrecto para el instante actual. La auditoría debe conservar la decisión, la versión de política, los inputs usados y el resultado de enforcement, sin confundirlos.

Desliza horizontalmente para leer el diagrama a tamaño completo.

Defaults, indeterminación y precedencia

Toda política debe declarar qué sucede cuando no hay una regla aplicable, falta un atributo, el evaluador agota su presupuesto o dos reglas discrepan. Recomendamos deny by default para operaciones sensibles: ausencia de una concesión no es una concesión. Es una decisión de diseño, no una propiedad de todos los modelos. RFC 2820 es un documento informativo sobre requisitos de ACL para directorios LDAP, no un estándar de implementación. Su requisito S9 dice que el modelo debe poder soportar default-grant o default-deny; S11 añade que la ausencia de política debe poder interpretarse como grant o deny y que deny prevalece entre entradas de igual especificidad. Northstar elige deny para pagos, pero esa elección no se transfiere automáticamente a cualquier ACL. RFC 2820, §§1 y 3.2, S9–S11

Una evaluación profesional separa al menos permit, deny, not-applicable e indeterminate. not-applicable significa que ninguna regla se dirigió a la petición; indeterminate significa que la política pretendía decidir pero faltó un dato, hubo un error o se superó un límite. Es una taxonomía mínima de este capítulo, no un contrato ABAC universal. La política de combinación debe declarar cómo convierte cada estado en una decisión final; no basta con decir «unión» o «intersección». En Northstar, la regla de aprobación define missing, stale, error del PIP y ciclo no resuelto como indeterminate, y el contrato de operación convierte ese estado en deny o revisión explícita. No se debe ocultar la causa bajo un simple «403» si después hay que diagnosticarla.

La precedencia tampoco es universal. Puede existir una regla explícita de denegación que domine una concesión, una regla más específica que sobrescriba una heredada o una combinación por unión/intersección. RFC 2820 propone que una política más específica prevalezca sobre una menos específica, que las políticas de igual especificidad se combinen de manera comprensible y que el resultado no dependa del orden textual de las entradas. RFC 2820, §3.2, requisitos S2–S12 Una implementación que evalúa de arriba abajo y se detiene en la primera coincidencia necesita declarar que su orden es parte de la semántica; no puede describirse como «ACL estándar» sin más.

ACL: concesiones ligadas al objeto

Una access control list (ACL, lista de control de acceso) asocia un objeto —o un ámbito de objetos— con entradas que nombran sujetos o grupos y derechos que se conceden o deniegan. La pregunta central es local: «dado este objeto, ¿qué puede hacer este principal?». Una entrada sintética puede verse así:

object: payment-882
entries:
  - subject: group:treasury-approvers
    actions: [read, approve]
    effect: allow
  - subject: user:elena
    actions: [approve]
    effect: deny

El ejemplo no decide todavía el resultado: hay que conocer membresía, tenant, herencia, acciones equivalentes y la regla que combina allow y deny. RFC 2820 define una ACL como una lista asociada a uno o varios objetos y señala requisitos de granularidad por entrada y atributo, agregación de usuarios, revisión de acceso efectivo e identificación del origen de políticas heredadas. RFC 2820, glosario y §§3.2–3.3

Herencia y precedencia

Northstar puede colocar una ACL en tenant:northstar-eu, heredarla a payments/ y permitir una excepción en payment-882. En este diseño local, la herencia reduce duplicación de entradas, pero aumenta la distancia entre la política visible en el objeto y su fuente. El administrador debe poder reconstruir qué entradas llegaron por herencia, cuál fue reemplazada y qué permiso efectivo queda después de combinar niveles. Si la ACL del tenant permite read y la del pago deniega read a un usuario, la excepción sólo es defendible si la semántica de especificidad está fijada y versionada.

El valor por defecto debe quedar fuera de la ambigüedad. Una ACL vacía puede significar «nadie salvo una regla global», «todos según una regla por defecto» o «error de configuración». Usar una ACL vacía como sinónimo universal de deny es una simplificación que sólo vale cuando el sistema lo documenta. Para decisiones monetarias, una política útil explicita propietario, administradores de emergencia, derechos heredados y la forma de revocarlos.

Los grupos hacen que una ACL parezca RBAC, pero no son lo mismo. Una ACL puede nombrar directamente a un usuario y, además, a un grupo; el grupo puede ser una relación administrativa, un rol funcional o una simple lista de distribución. No se debe inferir la semántica de rol por el texto del nombre. Si Elena pertenece a treasury-approvers, la ACL sólo concede lo que su combinación de entradas permita sobre ese objeto. No concede por sí sola el derecho a crear o modificar el grupo.

Ventajas y fronteras

En el escenario de Northstar, una ACL ofrece trazabilidad directa para objetos con pocos administradores: se inspecciona el recurso y se enumeran sus concesiones. La hipótesis de coste del caso es que muchos objetos pueden repetir la misma política, que una revocación puede tener que recorrer listas dispersas y que el permiso puede depender de contexto cambiante. Por eso la pregunta «¿qué puede leer Elena?» puede obligar a invertir el índice y buscar en objetos y herencias; no es una propiedad cuantitativa de toda ACL.

Una ACL tampoco resuelve la procedencia de un nombre. user:elena sólo es útil si el namespace y el ciclo de vida de ese principal están definidos en el capítulo 37. Tampoco resuelve enforcement: una ACL correcta almacenada en el PDP no protege si el PEP omite comprobarla o aplica el resultado a un identificador textual sin validar tenant y tipo de objeto.

Desliza horizontalmente para leer el diagrama a tamaño completo.

RBAC: permisos a roles, roles a usuarios

En el role-based access control (RBAC, control de acceso basado en roles), los permisos se asignan a roles y los usuarios reciben roles. Un permiso no es una acción abstracta: enlaza una operación con uno o más objetos o clases de objetos. Un usuario puede activar un subconjunto de sus roles en una sesión, y la política evalúa los permisos de esa sesión activa.

user Elena ──assigned──> role TreasuryApprover
role TreasuryApprover ──grants──> permission approve:payment
session σ ──activates──> TreasuryApprover
PEP ──enforces──> approve(payment-882)

El modelo NIST de RBAC fue formalizado en trabajos de 1992 y 2000 y se adoptó como ANSI/INCITS 359-2004; la propia página histórica de NIST identifica después INCITS 359-2012 como actualización y marca el proyecto como archivado. Por tanto, 359-2004 es una referencia histórica para el modelo y no debe citarse como si fuera la edición vigente o una especificación de producto. NIST, Role Based Access Control, estado y referencias del modelo

Roles, jerarquías y sesiones

Un rol es una agrupación administrada de permisos, no necesariamente un cargo humano. TreasuryApprover puede existir aunque varias personas compartan el mismo cargo o aunque un servicio técnico lo active. La asignación responde «qué roles puede activar este usuario»; la activación responde «qué roles están operativos en esta sesión». Mantener ambas relaciones evita que una sesión de soporte herede todas las capacidades permanentes del usuario.

En el modelo RBAC, una jerarquía de roles es una relación parcial ordenada: Northstar puede declarar que SeniorTreasuryApprover es superior a TreasuryApprover y hereda sus permisos, según la convención elegida por la política. Esa dirección semántica debe quedar explícita y acotada; no es una flecha que cada producto pueda invertir sin cambiar el modelo. El evaluador debe rechazar ciclos y registrar la versión de la jerarquía. La jerarquía reduce asignaciones, pero puede ocultar un permiso peligroso detrás de un rol aparentemente administrativo.

Las separation of duties (SoD, separación de funciones) son restricciones que impiden concentrar funciones incompatibles. En una static separation of duties (SSD, separación estática de funciones), una misma identidad no puede recibir simultáneamente PaymentCreator y PaymentApprover. En una dynamic separation of duties (DSD, separación dinámica de funciones), la restricción se comprueba sobre los roles activados en la sesión: Elena puede tener ambos roles asignados, pero no activarlos juntos. Northstar añade por separado una restricción de workflow: quien creó un pago no puede aprobarlo y una segunda aprobación no puede repetir la misma etapa; esa regla sí necesita consultar historial/estado de la transacción. La elección cambia el estado que el PDP necesita y el lugar donde el PEP debe hacer cumplir la restricción. Ningún nombre de rol garantiza SoD; hay que modelar la regla y sus datos de estado.

En Northstar, la sesión σ activa TreasuryApprover después de una reautenticación reciente. El PDP comprueba DSD sobre roles activos y, como política de workflow aparte, que payment-882.created_by != Elena, que no existe otra aprobación de la misma etapa y que el rol pertenece al tenant correcto. Si sólo mira un claim role=TreasuryApprover copiado al token al iniciar la sesión, una revocación posterior o un cambio de DSD puede quedar fuera de la decisión.

Cuándo encaja y dónde se atasca

En la matriz de Northstar, RBAC hace legible una colección estable de responsabilidades: el administrador revisa el catálogo de roles en lugar de editar cada objeto. Es una observación local que encaja cuando los permisos corresponden a funciones repetibles y las sesiones activan un conjunto acotado de capacidades. El trade-off aparece si el catálogo crece para capturar cada combinación de región, proyecto, clasificación, hora y excepción. Crear Approver-EU-Under10k-ManagedDevice para cada combinación ilustra role explosion en este diseño; no es una conclusión cuantitativa universal sobre RBAC.

RBAC tampoco reemplaza una identidad o una sesión. La asignación de roles requiere un ciclo de vida con autoridad; la activación requiere un estado de sesión; la revocación exige decidir si termina sesiones existentes o sólo futuras activaciones. Es posible combinar RBAC con atributos —por ejemplo, un rol de aprobador más device.managed=true—, pero entonces hay que documentar qué parte es RBAC y cuál es ABAC.

Desliza horizontalmente para leer el diagrama a tamaño completo.

ABAC: atributos, reglas y procedencia

El attribute-based access control (ABAC, control de acceso basado en atributos) decide evaluando atributos del sujeto, del objeto, de la acción y, cuando corresponde, del entorno contra reglas o políticas que describen operaciones permitidas. Esa definición es el centro de NIST SP 800-162 upd2: ABAC no es simplemente «RBAC con más campos», sino una forma de expresar una relación entre atributos y condiciones. NIST SP 800-162 upd2, definición y componentes funcionales

Para approve(payment-882), una regla podría expresarse así:

permit approve when
  subject.tenant == object.tenant
  and subject.employment_status == "active"
  and subject.department == "treasury"
  and subject.role == "approver"
  and object.state == "awaiting_approval"
  and object.amount <= 10000 EUR
  and environment.device_managed == true
  and environment.authentication_age <= 5 minutes
  and environment.region in subject.allowed_regions

El lenguaje es deliberadamente sintético. Cada atributo necesita una fuente, una semántica, una hora de emisión y un control de integridad. department=treasury procedente de una interfaz del cliente no equivale al mismo valor firmado por recursos humanos. device_managed=true puede ser válido para el instante de una atestación y falso después de una baja. NIST discute la autoridad, procedencia, validación y riesgo de datos obsoletos; Northstar añade el contrato concreto de frescura y error que usará en esta operación. El PIP debe responder con valor y metadatos de procedencia/frescura; el PDP debe decidir qué edades admite y qué ocurre si no puede verificarlas. NIST SP 800-162 upd2, §§3.2.2.10 y 3.3.1

PAP, PIP, PDP y PEP en una petición real

El PAP publica la política pay-approval-v17 con un conjunto de reglas y su fecha de activación. El PIP consulta el directorio laboral, el inventario de dispositivos y el estado del pago. El PDP recibe la petición y esos atributos; bajo el contrato de Northstar, devuelve indeterminate si employment_status es desconocido o si un valor está fuera de su ventana de frescura, y deny si object.tenant no coincide. El PEP del servicio de pagos comprueba que el resultado corresponde a payment-882 y, como decisión específica de Northstar para una transición monetaria, ejecuta awaiting_approval → approved con control de concurrencia y operación atómica. TTL, fail-closed y atomicidad no son requisitos universales de NIST: son precondiciones del diseño de este caso.

Un error frecuente es tratar un caché de atributos como si fuese una autoridad. El caché puede ser aceptable para department con una frescura de horas, pero no para estado de empleo durante una revocación inmediata. Northstar define un time to live (TTL, tiempo de vida) por atributo, reloj de referencia, invalidaciones y fallback; otra organización podría elegir una ventana diferente. PIP unavailable y attribute absent no son equivalentes a attribute=false; si se colapsan, el sistema puede conceder por error o hacer imposible auditar el motivo. Servir un dato obsoleto queda permitido sólo para reglas que lo declaren.

Desliza horizontalmente para leer el diagrama a tamaño completo.

Las combinaciones de políticas también requieren contrato. La unión/intersección es una ilustración de cómo combinar concesiones de ACL o sujetos agregados, no el catálogo completo de algoritmos ABAC. Para pay-approval-v17, Northstar fija una combinación all-of: una denegación bloquea; not-applicable no crea permiso; indeterminate deriva a deny o revisión según la causa; sólo todos los permit producen permit. Si una regla permite por importe y otra deniega por dispositivo no gestionado, el resultado es denegación bajo ese contrato. La política debe conservar el resultado de cada regla y la regla de combinación, no sólo el booleano final.

ABAC no elimina la administración

En el diseño de Northstar, ABAC evita parte del role explosion que produciría codificar cada combinación contextual en roles, pero desplaza trabajo a la gobernanza de atributos: quién los emite, qué significan, qué tenant abarcan, cómo se revocan, cómo se transforman al cruzar una frontera y quién puede cambiar la política. Un atributo no confiable, fácilmente forjable o fuera del control del administrador puede convertirse en un permiso disfrazado. RFC 2820 formula una cautela comparable para su modelo ACL de LDAP: no basar decisiones en atributos que el administrador no puede gobernar o que se forjan con facilidad. RFC 2820, requisitos S5–S7

ABAC tampoco sustituye las relaciones. subject.department=treasury no expresa que Elena sea miembro de un proyecto concreto, que un documento esté compartido con ese equipo o que un grupo contenga otro grupo. Puede consultar esas relaciones como atributos derivados, pero entonces el PIP y la política deben declarar el coste, la frescura y la recursión de esa derivación.

ReBAC: relaciones que forman un grafo

El relationship-based access control (ReBAC, control de acceso basado en relaciones) decide mediante relaciones explícitas entre sujetos, objetos y otros sujetos o conjuntos. Una tupla puede escribirse como:

(folder:treasury, relation:viewer, group:approvers)
(group:approvers, relation:member, user:elena)
(payment:882, relation:parent, folder:treasury)

Las tuplas no bastan para inferir que payment:882 hereda viewer desde la carpeta. Northstar publica además esta configuración de relación:

payment#viewer = this OR tuple_to_userset(parent -> folder#viewer)

La consulta check(user:elena, viewer, payment:882) expande la reescritura: sigue payment:882 --parent--> folder:treasury, consulta folder:treasury#viewer, encuentra group:approvers, y luego comprueba group:approvers --member--> user:elena. Las relaciones tienen dirección, tipo y ámbito; no son una tabla de roles genérica. Una relación puede ser directa (owner), transitiva (member), derivada por una reescritura de userset (viewer a través de parent) o una unión de conjuntos.

El paper de Zanzibar describe un sistema global de almacenamiento y evaluación de ACL con un modelo uniforme para servicios distintos, configuración para expresar conjuntos y garantías de orden causal/consistencia externa frente a cambios de ACL y objetos. Es un caso de arquitectura de autorización a gran escala, no un estándar de ReBAC ni un sinónimo universal del modelo. Pang et al., “Zanzibar: Google’s Consistent, Global Authorization System”, USENIX ATC 2019, §§1–2

Evaluación recursiva, ciclos y límites

El paper de Zanzibar describe relaciones entre objetos, reescrituras de userset, grupos anidados y técnicas para evaluar conjuntos profundos; no prescribe una detección de ciclos ni una política universal de presupuesto. Para este sistema, un evaluador diseñado por Northstar necesita un conjunto de visitados, un presupuesto de profundidad/nodos y una semántica para indeterminate. Un ciclo no prueba permiso: si A.member → B y B.member → A, una búsqueda sin base directa no puede producir una concesión sólo por circular. Northstar rechaza la rama y la registra como indeterminate; otra implementación podría elegir una semántica de punto fijo, pero tendría que documentarla y probarla. Pang et al., §§2.1–2.3 y §3.2

La recursión hace visible la diferencia entre «existe una relación» y «puede comprobarse ahora». Si group:approvers incluye a otro grupo remoto y ese servicio no responde, el PDP no conoce un false; conoce un error. Una política sensible debe tratarlo como denegación o revisión, y registrar la rama sin exponer datos innecesarios. Un límite de profundidad que devuelve deny sin métrica puede parecer una revocación cuando en realidad es una protección de disponibilidad.

Consistencia, caché y revocación

En un sistema distribuido, eliminar la tupla (group:approvers, member, user:elena) y recibir un permiso positivo desde una réplica obsoleta crea una ventana de revocación. Zanzibar separa la relación almacenada de la configuración que reescribe usersets, la petición Check y el zookie/snapshot que fija un punto de lectura. Pang et al., §§2.1–2.3 También describe cachés de resultados/intermedios para sostener latencia y disponibilidad; esas decisiones pertenecen a su sistema y no se transfieren automáticamente a cualquier ReBAC. Pang et al., §2.2 y §§3.2.3–3.2.5

Desliza horizontalmente para consultar todas las columnas.

Antes de aceptar caché hay que fijar un objetivo: ¿la revocación debe ser efectiva en segundos, en la siguiente operación con un zookie/snapshot posterior, o después de expirar la sesión? Un resultado cacheado necesita una clave de caché completa —sujeto, acción, objeto, contexto relevante, versión de relación y tenant— y una política de invalidación; ésta es una recomendación de Northstar, no una clave normativa de Zanzibar. Cachear sólo por (user, object) puede reutilizar un read como approve o un permiso de un tenant en otro.

En el escenario de compartición de Northstar, ReBAC puede reducir duplicación al representar pertenencia y herencia como relaciones en lugar de copiar permisos a cada objeto. Northstar recomienda además herramientas de trazado. Para responder «¿por qué permitió?», su sistema muestra una ruta de relaciones, la configuración de userset, el snapshot consultado y las ramas negadas o indeterminadas. Esa explicabilidad es un control del diseño local; no se atribuye como requisito universal a Zanzibar. Permite detectar que una carpeta heredó acceso de un grupo que ya no debía administrar.

Desliza horizontalmente para leer el diagrama a tamaño completo.

Caso conductor: una aprobación híbrida

Northstar decide que ningún modelo por sí solo expresa toda la política de payment-882. La decisión compuesta se documenta como una conjunción de controles, no como una afirmación de superioridad:

permit iff
  ACL(object).allows(subject, approve)
  and RBAC(session).has(TreasuryApprover)
  and ABAC(request).satisfies(pay-approval-v17)
  and ReBAC(subject, object).has(viewer_path)
  and PEP.enforcement_target == object

El conjunto es una elección de Northstar. Otro sistema puede usar ACL para datos y ABAC para operaciones, o RBAC con restricciones de relación. El contrato all-of de Northstar fija que sólo cuatro permit producen permit; cualquier deny bloquea y cualquier indeterminate deriva a deny o revisión según su causa. No se debe ejecutar cuatro PEP independientes que puedan divergir y dejar al recurso en un estado parcial.

Para Elena, la evaluación paso a paso es:

1. Sujeto y sesión. La sesión del capítulo 37 resuelve (issuer, subject) a employee-7319; la sesión σ está vigente y no revocada. El capítulo 41 estudiará su cookie, rotación y expiración. El capítulo 45 tratará el protocolo federado; aquí sólo consumimos el principal ya resuelto.
2. ACL. El objeto payment-882 hereda approve desde tenant:northstar-eu, pero una entrada específica deniega la acción al creador. Como Elena creó el pago, la regla específica produce deny aunque pertenezca a treasury-approvers.
3. RBAC. La sesión activa TreasuryApprover tiene el permiso nominal, pero SoD dinámica confirma que no se activa junto con PaymentCreator. Esta comprobación no revive una denegación de ACL; sólo elimina una ruta adicional de concesión.
4. ABAC. Si la ACL no hubiera denegado, el PDP comprobaría empleo activo, tenant, estado awaiting_approval, importe, dispositivo gestionado, región y edad de autenticación. Un employment_status con procedencia desconocida o más antiguo que el límite produciría indeterminate y no concesión.
5. ReBAC. Las tuples almacenadas tienen estas direcciones: folder:treasury --viewer--> group:approvers, group:approvers --member--> user:elena y payment:882 --parent--> folder:treasury. La consulta check(user:elena, viewer, payment:882) hace un traversal de consulta inverso: parte de payment:882, sigue parent hacia folder:treasury, encuentra el userset viewer que apunta al grupo y comprueba si ese grupo contiene a Elena mediante la tuple group → user. No se deben dibujar esas preguntas de pertenencia como si fueran nuevas tuples user → group o group → folder. Si la eliminación de la membresía sólo está en la región primaria, el contrato de consistencia debe impedir que una réplica obsoleta conceda. La relación viewer no se convierte por nombre en approver; son permisos distintos.
6. PEP. Aunque la decisión final fuese permit, el PEP verifica que el identificador de pago coincide con el evaluado, vuelve a comprobar el estado transaccional y, como decisión local de Northstar, ejecuta la transición con control de concurrencia y atomicidad. Si no puede garantizarlo, falla cerrado o devuelve una revisión explícita; nunca convierte la caída del PDP en una aprobación implícita.

El resultado correcto es deny: creator cannot approve own payment, con versión de política, versiones de atributos/relaciones y resultado de enforcement. Ese mensaje explica causa y alcance sin revelar al cliente toda la topología interna.

Una traza positiva exige cambiar las precondiciones, no borrar la denegación. Considérese payment-914, creado por otra persona y todavía en awaiting_approval. La ACL efectiva concede approve a treasury-approvers sin una excepción específica; la sesión de Elena activa únicamente TreasuryApprover; los atributos proceden de sus autoridades, están dentro de su TTL y satisfacen pay-approval-v17; la ruta ReBAC se evalúa sobre un snapshot posterior a la última modificación; y el PEP recibe una decisión ligada a northstar-eu/payment-914. Los cuatro componentes devuelven permit, el contrato all-of produce permit y, sólo entonces, el PEP vuelve a comprobar objeto, tenant y estado antes de realizar la transición atómica. Si cualquiera cambia entre decisión y uso, el enforcement rechaza o reevalúa: la traza positiva no convierte permit en un cheque en blanco.

Desliza horizontalmente para leer el diagrama a tamaño completo.

Fallos de enforcement y observabilidad

Separar PDP y PEP permite aislar cuatro clases de fallo:

• Decisión correcta, objeto equivocado: un gateway usa la respuesta para payment-881 sobre payment-882. El PEP no vinculó request y decisión.
• Decisión correcta, aplicación fallida: el PDP deniega pero una ruta administrativa ejecuta la operación sin pasar por el PEP. Hay una frontera de enforcement incompleta.
• Datos obsoletos: el PDP permite con rol, atributo o relación revocados. El problema está en procedencia, frescura, invalidación o consistencia, no necesariamente en la regla.
• Error tratado como permiso: el PIP o evaluador falla y una capa convierte unknown en true. El contrato de Northstar evita ese fail-open para aprobaciones, pero otro sistema debe declarar su propia política de fallos y sus precondiciones.

Para Northstar, un registro útil contiene request_id, principal efectivo y mediador, acción, objeto y tenant, versión de política, decisión de cada componente, referencias de procedencia y frescura, versión de relaciones, instancia de PDP/PEP, resultado de enforcement y razón acotada. No debe incluir secretos de sesión ni atributos innecesarios. Registrar sólo allowed=true impediría a este equipo distinguir una concesión por ACL de una ruta ReBAC obsoleta; la explicabilidad mínima de Northstar conserva además la reescritura y el snapshot que produjeron la ruta.

Como plan de verificación de Northstar, las pruebas negativas deben atravesar toda la ruta: usuario sin ACL, rol no activo, atributo no fresco, relación eliminada, ciclo, PIP caído, PDP caído y PEP caído. Un test que invoca al PDP sin ejecutar la operación no prueba enforcement en este sistema. Un test que sólo verifica una denegación tampoco demuestra que la ruta permitida respeta tenant, acción y objeto.

Comparación sin ganador universal

Desliza horizontalmente para consultar todas las columnas.

La tabla orienta una decisión, no sustituye el análisis. Un documento compartido puede necesitar ACL y ReBAC; una operación regulada, RBAC más ABAC; un sistema pequeño, una ACL simple con un PEP bien cerrado. La elección debe justificar cardinalidad de objetos, frecuencia de cambios, latencia admisible, revocación, explicabilidad y autoridad que administra cada input.

Fronteras con capítulos vecinos

El capítulo 37 explica cómo una identidad, una cuenta, un autenticador, una assertion y una sesión se relacionan. Este capítulo consume el principal y los atributos disponibles; no decide si el login fue legítimo ni define el namespace.

El capítulo 41 explica cookies, tokens, rotación, expiración y revocación de sesiones. Aquí la sesión aparece sólo como input de autorización —por ejemplo, edad de autenticación o roles activados— y como estado que el PEP debe ligar a la petición.

El capítulo 45 explicará OAuth y sus tokens, scopes, delegación y audiences. Un scope presentado por un cliente no es automáticamente un permiso de negocio: el PDP aún debe evaluar sujeto, objeto, contexto y política local.

Síntesis: hacer explícita la cadena de permiso

ACL, RBAC, ABAC y ReBAC no son etiquetas para clasificar productos. Son formas distintas de representar hechos que una decisión necesita: concesiones por objeto, funciones administradas, condiciones con atributos o rutas de relaciones. Cada forma tiene una semántica de default, precedencia, herencia, revocación y fallo; si queda implícita, el sistema termina con varias políticas incompatibles.

Una autorización defendible puede reconstruirse como una cadena: el principal se resolvió dentro de un namespace; la petición nombró acción, objeto y tenant; el PDP consumió inputs con procedencia y frescura; la política versionada combinó resultados; el PEP aplicó la decisión al mismo objeto; y la auditoría conservó límites y errores. El modelo que minimiza trabajo en un componente puede aumentar trabajo en otro. No hay un ganador universal: hay una decisión acotada por contexto, lifecycle, consistencia y capacidad de enforcement.