Very simplistic way of doing role-based access control (RBAC) with Neo4j.

GraphGist-SimpleRBAC.adoc

This is a very simple approach to doing role-based access control with Neo4j. It is optimistic, in the sense that all items are assumed to be world-readable unless they have specific constraints. Item visibility can be constrained to either individual users or all users who belong to a role. Roles are also hierarchical, so can inherit privileges from other roles.

First, lets create our basic example data:

CREATE
    (admin { type: 'role', name: 'admin'}),

    (role1 { type: 'role', name: 'role1'}),
        role1-[BELONGS_TO]->admin,

    (user1 { type: 'user', name: 'user1'}),
        user1-[BELONGS_TO]->role1,

    (role2 { type: 'role', name: 'role2'}),

    (user2 { type: 'user', name: 'user2'}),
        user2-[BELONGS_TO]->role2,

    (item1 { type: 'item', name: 'item1'}),
        item1-[ACCESSIBLE_TO]->admin,

    (item2 { type: 'item', name: 'item2'}),
        item2-[ACCESSIBLE_TO]->role2

RETURN admin, role1, role2, user1, user2, item1, item2

Hi @mikesname! This looks nice! Did you use it in a real project, did you run into any issues (performance, manageability or whatnot)?

@mrts wow, this is a blast from the past! Yes, this approach (slightly simplified here from IRL) is taken in the EHRI project database of archival collections and its associated admin system. It has worked well for the past 6 years or so. We have not had any issues with performance but there is definitely an overhead to adding an access control system.

Note also that the Cypher here is a bit outdated.

Good to hear, thanks! Another thing - were Neo4j, Tinkerpop and GraphQL the right choice or would you choose different building blocks today?

It's hard to say TBH. Today I'd probably just opt for PostgreSQL because it's such a dependable piece of infrastructure. It would make our dataset much more difficult to work with in a variety of ways but dependability means more to me now. Neo4j itself has actually been very stable and enjoyable to work with over the years but because it's one company's product you can never be sure they won't change direction or deprecate something you rely on in the next release.

We mainly used Tinkerpop at the outset in case we had to switch away from Neo4j, but in the event they went in a different direction at version 3 and now version 2 remains a bit of legacy in our codebase, while we still use Neo4j several versions on.

Overall, the graph stuff has been a win for us because it's great for tree structures and hierarchies, which we deal with a lot in our dataset. I find Cypher a great language for analytics and the lack of a strict SQL-style schema has been more of a blessing than a curse, though obviously there are trade-offs with that.

Ah, great points, heartfelt thanks for the advice!