Access control

This section explains how to manage Neo4j role-based access control and fine-grained security.

Neo4j has a complex security model stored in the system graph, which is maintained on a special database called the system database. All administrative commands need to be executed against the system database. When connected to the DBMS over bolt, administrative commands are automatically routed to the system database. For more information on how to manage multiple databases, refer to the section on administering databases.

The concept of role-based access control was introduced in Neo4j 3.1. Since then, it has been possible to create users and assign them to roles to control whether users can read, write and administer the database. In Neo4j 4.0 this model was enhanced significantly with the addition of privileges, which are the underlying access-control rules by which the users rights are defined.

The original built-in roles still exist with almost the exact same access rights, but they are no-longer statically defined (see Built-in roles). Instead, they are defined in terms of their underlying privileges, and they can be modified by adding or removing these access rights.

In addition, any newly created roles can be assigned to any combination of privileges, so that you may set specific access controls for them. Another new major capability is the sub-graph access control, through which read access to the graph can be limited to specific combinations of labels, relationship types, and properties.

Syntax summaries

Almost all administration commands have variations. The most common are parts of the command that are optional or that can have multiple values.

See below a summary of the syntax used to describe all versions of a command. These summaries use some special characters to indicate such variations.

Table 1. Special characters in syntax summaries
Character Meaning Example

|

Used to indicate alternative parts of a command (i.e. or). Needs to be part of a grouping.

If the syntax needs to specify either a name or *, this can be indicated with * | name.

{ and }

Used to group parts of the command. Commonly found together with |.

In order to use the or in the syntax summary, it needs to be in a group: {* | name}.

[ and ]

Used to indicate an optional part of the command. It also groups alternatives together, when there can be either of the alternatives or nothing.

If a keyword in the syntax can either be in singular or plural, we can indicate that the S is optional with GRAPH[S].

...

Repeated pattern. Related to the command part immediately before this is repeated.

A comma separated list of names would be name[, ...].

"

When a special character is part of the syntax itself, we surround it with " to indicate this.

To include { in the syntax use "{" { * | name } "}". In this case, you will get either { * } or { name }.

The special characters in the table above are the only ones that need to be escaped using " in the syntax summaries.

Here is an example that uses all the special characters. It grants the READ privilege:

GRANT READ
  "{" { * | property[, ...] } "}"
  ON {HOME GRAPH | GRAPH[S] { * | name[, ...] }}
    [ ELEMENT[S] { * | label-or-rel-type[, ...] }
    | NODE[S] { * | label[, ...] }
    | RELATIONSHIP[S] { * | rel-type[, ...] }]
  TO role[, ...]

Note that this command includes { and } in the syntax, and between them there can be a grouping of properties or the character *. It also has multiple optional parts, including the entity part of the command which is the grouping following the graph name.

However, there is no need to escape any characters when creating a constraint for a node property. This is because ( and ) are not special characters, and [ and ] indicate that the constraint name is optional, and therefore not part of the command.

CREATE CONSTRAINT [constraint_name] [IF NOT EXISTS]
FOR (n:LabelName)
REQUIRE n.propertyName IS NOT NULL