En nuestro sistema, cada recurso tiene una lista de control de acceso (ACL), que enumera las entradas (ACE) que tienen un tipo específico de acceso a ese recurso. El ACE puede ser para entidades finales (por ejemplo: usuarios como "Mr Q") o entidades de grupo (por ejemplo: "Atlántico Norte"); la inclusión de las entidades del grupo hace que este sea un sistema híbrido ACL / RBAC.

Datos de ACL

Resource #1 => ACL
ACL => ACE#1 Entity(Type:User, ID:006), Rights(~Read, ~Write)) /* Deny */
       ACE#2 Entity(Type:User, ID:007), Rights(Read, Write))
       ACE#3 Entity(Type:User, ID:101), Rights(Write))
       ACE#4 Entity(Type:Group, ID:A01), Rights(Read, Write))
       ACE#5 Entity(Type:Group, ID:B04), Rights(Read, Write))

Cualquier cosa que no aparezca en la ACL será denegada y DENY anulará cualquier otra cosa.

Información del sistema

Hay un servidor central en línea que media el acceso a dichos recursos. Las escrituras en la ACL serán raras, principalmente se leerán (quizás en una proporción de 1:50 o más).

Question

¿Cuál es una estructura de datos adecuada para almacenar la ACL anterior? El almacenamiento de toda la ACL como una sola cadena JSON en un almacén NoSQL parece simple, pero también podemos normalizar los datos de ACL y almacenarlos en las tablas SQL. Si alguien tiene experiencia operativa sobre las ventajas y desventajas de cualquiera de los enfoques, me gustaría saber de ellos. También nos preguntamos si vale la pena explorar almacenando esto en LDAP, pero quería permanecer alejado de X.500 / DER y otras tecnologías de telecomunicaciones ... quizás haya opciones modernas de LDAP (enraizadas en el mundo CS) para explorar más allá de NoSQL / SQL ?