Question

In the past i would use the following simple data model to implement security into my applications. I would have an implicit deny, explicit allow and explicit deny which the later could overide the one preceding it.

The problem i’m facing now is that my current application needs to be scalable to tens of millions of records. In the data model above, for each record i could possibly have many ACL entries. So if my records table (acltest_uspaceData) has 10 million rows my acl security tables could have a lot more.

Is this an appropriate data model for the amount of records we plan on storing? If not, What can i do to this datamodel to make it scalable?

I’m using PostGIS as a Database.

Update – Rules:

1. It’s should be implied that nobody has access to anything if there
   are not security associations made for that record.
2. To allow user or group access, you must explicitly Allow them to access
   that record via some security association.
3. To deny someone access who already has access via group membership,
   you must explicitly deny that person access to that record via a security association.

Answer 1

Based on your security rules, the acltest_role_acl.allowed looks redundant – if a role ACL entry is present then allowed == true can be implied. Unless, of course, you actually want the ability to “revoke” whole groups and not just individual users.

Other than that, your model looks good and you should concentrate on storing it efficiently in the database.

In case your DBMS supports it, it is probably a good idea to store ACLs as a clustered table:

• If you want to efficiently answer the question “which ACL entries does the given record have”, then the order of PK columns in the clustered table should be {record_id, user_id} for user ACLs and {record_id, role_id} for role ACLs.
• If you want to efficiently answer the question “which ACL entries does the given user or role have”, then the order of PK columns should be reversed (i.e. {user_id, record_id} and {role_id, record_id}).
• If you want to efficiently answer both questions, you’ll need an index in both “directions”. Unfortunately, secondary indexes are expensive in clustered tables, so you might consider using a heap-based table and two ordinary indexes in this case.

If your DBMS supports it, you could compress the leading edge of the clustering index (under Oracle, this is known as COMPRESSED INDEX ORGANIZED table). This would remove some of the redundancy stemming from repeated ACLs (from your comments: “it is common to have many people with the same permissions” and “there are many rows with the same permissions”).

---

On the other hand, if you are primarily worried about storage cost (and/or use a DBMS that does not support compression), but don’t mind increased complexity and potential performance impact, you could consider something like this:

Since many records share the same ACLs (as per your comment), this model would avoid most of the repetition.

For example, if N records have the same 5 ACL entries:

• Old model would require N*5 ACL entry rows.
• The new model would only require 6 rows + N fields, which is much cheaper storage-wise (6 rows = 5 ACL entries + 1 group, and the field is: acltest_uspaceData.acl_group_id).

The problem is: when you insert a new record, how do you find the “matching” ACL group? This could be solved roughly like this, but would not be terribly efficient:

SELECT *
FROM acltest_aclGroup
WHERE
    NOT EXISTS (
        SELECT user_id, allowed
        FROM acltest_users_acl
        MINUS -- Or EXCEPT, depending on the DBMS.
        SELECT user_id, allowed
        FROM <user_acl_tmp>
    )
    AND NOT EXISTS (
        SELECT user_id, allowed
        FROM <user_acl_tmp>
        MINUS
        SELECT user_id, allowed
        FROM acltest_users_acl
    )
    AND NOT EXISTS (
        SELECT role_id
        FROM acltest_role_acl
        MINUS
        SELECT role_id
        FROM <role_acl_tmp>
    )
    AND NOT EXISTS (
        SELECT role_id
        FROM <role_acl_tmp>
        MINUS
        SELECT role_id
        FROM acltest_role_acl
    )

First, you create a temporary table for user and role ACLs (<user_acl_tmp> and <role_acl_tmp>), then insert the ACL entries the new record should have into them, then execute the above query which searches the existing ACL groups for set equality with temporary ACLs.