7.1.6. Subgraph access control

This section describes how to configure subgraph access control in Neo4j.

Through the use of user-defined procedures and custom roles, an administrator may restrict a user’s access and subsequent actions to specified portions of the graph. In other words, it is possible to configure access control at the level of a subgraph. For example, a user can be allowed to read, but not write, nodes labelled with Employee and relationships of type REPORTS_TO.

The following sections describe the actions required to configure subgraph access control. The actions can be undertaken in any order.

The section describes the following: Manage the custom role

Native users scenario

Create the custom role, and, subsequently, assign the role to the relevant user(s).

Example 7.18. Create an 'accounting' role and assign it to a pre-existing user, 'billsmith'.
CALL dbms.security.createRole('accounting')

CALL dbms.security.addRoleToUser('accounting', 'billsmith')
Federated users scenario (LDAP)

In the LDAP scenario, the LDAP user group must be mapped to the custom role in Neo4j.

Example 7.19. Map the LDAP group with groupId '101' to the custom role 'accounting':
dbms.security.realms.ldap.authorization.group_to_role_mapping=101=accounting Configure procedure permissions

The procedure to read or write a portion of the data needs to be created, unless it is already available as an in-house or third-party library. Refer to Neo4j Developer Manual → User-defined procedures for a thorough description on creating and using user-defined procedures.

In standard use, procedures will be executed according to the same security rules as normal Cypher statements. For example, a procedure with mode=WRITE will be able to be executed by users assigned to any one of the roles publisher, architect and admin, whereas a user assigned only to the reader role will not be allowed to execute the procedure.

The standard mode of usage can be overridden with the configuration options dbms.security.procedures.default_allowed and dbms.security.procedures.roles. These options allow specific roles to execute procedures they would otherwise be prevented from accessing.

Setting dbms.security.procedures.default_allowed allows a role to execute any procedure that is not matched by the dbms.security.procedures.roles configuration.

The dbms.security.procedures.roles setting provides more fine-grained control over procedures. For example, setting dbms.security.procedures.roles=apoc.convert.*:Converter;apoc.load.json.*:Converter,DataSource;apoc.trigger.add:TriggerHappy will have the following effects:

  • All users with the role Converter will be able to execute all procedures in the apoc.convert namespace.
  • The roles Converter and DataSource will be able to execute procedures in the apoc.load.json namespace.
  • The role TriggerHappy will be able to execute the specific procedure apoc.trigger.add.

The procedure’s role configuration is used to override the permissions given by the user’s roles. This will override the permission of the user with the mode of the procedure during the execution of the procedure. As a consequence, if the procedure attempts to execute database operations that are not included in its mode, it will fail with a 'permission denied' error regardless of the reason as to why the user was permitted to run the procedure.