Motor y administrador de políticas, vistos desde la identidad

En la arquitectura de referencia, el motor de políticas (PE) toma la decisión de conceder, negar o revocar el acceso a un recurso. El administrador de políticas (PA) la lleva a la práctica: establece o cierra el camino entre el sujeto y el recurso, y le indica al punto de aplicación qué hacer. Juntos forman el punto de decisión. El punto de aplicación está del lado del recurso.

Una consecuencia para la identidad: el motor necesita los atributos del usuario y, por eso, el sistema de identidades es su proveedor de datos más importante.

Abre politica.txt. Es un algoritmo por criterios: reglas explícitas, lo que nadie permite se niega y una negación prevalece sobre un permiso. Evalúa en orden cada solicitud de solicitudes.txt: primero, ¿alguna regla de negación aplica?; si no, ¿alguna regla de permiso se cumple completa?; si no, se niega.

Una de las solicitudes cumple por completo una regla de permiso y aun así se niega, porque otra regla prevalece. Es el comportamiento esperado de una política bien escrita: la señal de riesgo del usuario pesa más que el grupo al que pertenece.

Cuando se niega una solicitud, quien opera la política necesita el atributo exacto que falló: de eso depende qué se le explica al usuario y qué se corrige. Hay una solicitud del grupo correcto, con el segundo factor más fuerte, cuyo único problema es el equipo desde el que se hace.

El motor decide, pero lo que queda en el mundo real es la sesión que abre el administrador. Una sesión corta limita el daño si la cuenta se compromete a mitad de camino. El archivo sesiones_pa.txt registra cada decisión de permitir y cuánto durará la sesión.