In our system, every resource has an access control list (ACLs), which list entries (ACEs) that have a specific kind of access to that resource. The ACE can be for end-entities (eg: users like "Mr Q") or group entities (eg: "North Atlantic"); the inclusion of the group entities makes this a hybrid ACL/RBAC system.

ACL data

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))

Anything that doesn't appear on the ACL will be denied and DENY's overrule anything else.

System info

There is a central online server that mediates access to said resources . Writes to the ACL will be rare, mostly it'll be reads (perhaps at 1:50 ratio or more).


What is a suitable data structure to store the above ACL? Storing the entire ACL as a single JSON string in a NoSQL store seems simple but then we can also normalize the ACL data and store it in SQL tables. If someone has operational experience on the pros/cons on either approaches, would like to hear from them. We're also wondering if it's worth exploring storing this in LDAP but wanted to stay away from X.500/DER and other telecomm sourced technologies ... maybe there are modern LDAP options (rooted in CS world) to explore beyond NoSQL/SQL?

1 Answer 1


The best way to structure an ACL is as a bitmask which makes it easy to quickly determine complex access rights for a resource.

The best way to store that might be a key-value store such as Redis or any object-caching technology that integrates well with your environment. The decision to go with NoSQL vs SQL would be more of a business or IT decision rather than technical because a simple lookup could be just as fast either way.

Of course LDAP would also be an excellent way to go but doesn't make much sense unless you are integrating permissions with some other system.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .