Mapeo de roles y atributos

Un rol de reino vale para todo el reino y lo puede usar cualquier aplicación. Un rol de cliente pertenece a una aplicación concreta y solo significa algo dentro de ella: «editar notas» no tiene sentido para el correo web. Un grupo reúne personas y puede llevar roles, de modo que quien entra al grupo los recibe. Un rol compuesto incluye otros roles: quien tiene el compuesto tiene todos los que contiene, y los que estos contengan a su vez.

Esa herencia es cómoda, pero esconde poder. El rol que se lee en la lista de una persona puede no ser el que más puede hacer; hay que expandirlo.

Para saber qué puede hacer realmente una persona hay que expandir su rol: sumar los roles que contiene, los que esos contienen, y así hasta que no queden compuestos. Es una cuenta que se hace con la tabla delante, no de memoria.

Abre glosario.txt y roles.txt. Calcula cuántos roles efectivos tiene una persona a la que solo se le asignó el rol direccion, contando el propio direccion.

Los grupos son la vía recomendada para dar roles: la persona entra al grupo y recibe lo que el grupo lleva. Pero un grupo mal puesto concede de más y a muchas personas a la vez. La revisión consiste en tomar cada grupo, expandir sus roles y preguntar si lo que termina pudiendo hacer corresponde a para qué existe el grupo.

Lee grupos.txt y expande los roles con la tabla de roles.txt. Una capacidad de las más delicadas es borrar notas: el rol notas-borrar.

Un mapeador decide qué dato de la persona se escribe en el token de un cliente: el correo, los grupos, un atributo como el documento de identidad. Cada cliente debería recibir solo lo que necesita. Un dato personal que viaja a una aplicación que no lo usa queda en sus registros, en los navegadores y en cualquier lugar donde se guarde el token; es un riesgo sin beneficio.

En mapeos.txt están los mapeadores configurados por cliente, y en necesidades.txt lo que cada responsable de aplicación dijo que necesita. Cuenta los mapeadores que entregan un dato que el cliente no declaró necesitar.

Cuando se encuentra un mapeo que entrega datos de más, la tentación es corregirlo en la aplicación o dejarlo «por si acaso». Lo que se hace es más sencillo: se confirma con el responsable de la aplicación que no lo necesita y se retira el mapeador del cliente, dejando constancia en un cambio con ticket. El dato sigue existiendo en el servidor; solo deja de salir hacia donde no hace falta.