Security & administration
|
This section documents the current Neo4j This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production, as Neo4j iterates quickly. This section’s bibliography lists the reference material consulted while preparing these pages. |
Neo4j controls access in two layers: authentication decides who a connecting client is, and authorization — a role-based privilege system — decides what that identity may read, write or administer. This page covers both, plus the administration tasks (multi-database, backup/restore, transport encryption and auditing) that sit alongside them.
Authentication: native, LDAP and OIDC
A fresh installation ships one native user, neo4j, that must change its password on first login. Beyond
that default, three authentication providers can be configured, and more than one can be enabled at once so
different clients authenticate different ways
(Auth & Authorization):
-
Native — users and their hashed passwords are stored inside Neo4j itself, managed with
CREATE USER/ALTER USER/DROP USER. -
LDAP — delegates authentication (and optionally role mapping) to a directory server, so credentials never live in Neo4j.
-
OIDC — delegates to an external OpenID Connect identity provider (Okta, Entra ID, Keycloak, …) for single sign-on, mapping token claims to Neo4j roles.
// Native user management -- run against the system database.
CREATE USER alice SET PASSWORD 'a-temporary-value' CHANGE REQUIRED
SET STATUS ACTIVE;
ALTER USER alice SET PASSWORD CHANGE NOT REQUIRED;
SHOW USERS YIELD user, roles, suspended;
DROP USER alice;
LDAP and OIDC are turned on in neo4j.conf (dbms.security.authentication_providers,
dbms.security.authorization_providers); the directory/provider connection details and the claim-to-role
mapping live alongside them. That configuration surface is large enough that it is only linked here, not
reproduced — see
Auth & Authorization for the
full provider setup.
Role-based access control: built-in roles and privileges
Every user is granted one or more roles, and every role holds a set of privileges — each privilege
names an action (MATCH, TRAVERSE, WRITE, CREATE INDEX, …), a target (a database, a graph, a
label, a relationship type, a property) and an effect (GRANT, DENY). A user’s effective access is the
union of their roles' grants, minus any deny — deny always wins over grant, even from a different role
held by the same user
(Manage
Privileges).
Five built-in roles ship out of the box (Built-in Roles):
| Role | Grants |
|---|---|
|
Full administrative privileges over the whole DBMS: users, roles, databases, privileges. |
|
|
|
Read and write data, and start/stop the roles' assigned databases, but no schema changes. |
|
Read and write data only — no schema administration. |
|
Read-only access to the roles' assigned databases. |
Custom roles compose the same privilege grammar. A typical pattern is a purpose-built role scoped to one label and one database:
// Create a role that may only read Movie nodes in the "moviesdb" database.
CREATE ROLE movieReader;
GRANT ACCESS ON DATABASE moviesdb TO movieReader;
GRANT MATCH {*} ON GRAPH moviesdb NODE Movie TO movieReader;
// Assign it to a user, then confirm what the role can do.
GRANT ROLE movieReader TO alice;
SHOW ROLE movieReader PRIVILEGES;
DENY overrides any broader GRANT — useful for carving an exception out of a wide role without
rewriting it:
// alice keeps broad read access via another role, but is explicitly denied
// Salary, even if a future grant would otherwise expose it.
DENY READ {salary} ON GRAPH moviesdb NODE Employee TO movieReader;
Privileges are removed with the mirror-image REVOKE, which takes an optional GRANT or DENY to remove
only that half:
REVOKE GRANT MATCH {*} ON GRAPH moviesdb NODE Movie FROM movieReader;
REVOKE DENY READ {salary} ON GRAPH moviesdb NODE Employee FROM movieReader;
SHOW PRIVILEGES audits the full picture across every role:
SHOW ALL PRIVILEGES YIELD role, graph, segment, action, access;
Compare this label/relationship-scoped grant model with MongoDB’s built-in and custom roles, which scope privileges to actions and resources (a database, a collection, or a cluster) rather than to graph labels and properties — the same GRANT/DENY-style idea, applied to a different data model.
Administration: multi-database, backup, encryption and auditing
This section is an overview only — the full treatment of multi-database topology, Fabric and clustering lives in Clustering & multi-database.
Multi-database. A single DBMS instance hosts several independent databases, each with its own data,
schema and (via the privilege grammar above) its own access rules. SHOW DATABASES lists them; CREATE
DATABASE / DROP DATABASE manage the set.
CREATE DATABASE moviesdb IF NOT EXISTS;
SHOW DATABASES YIELD name, currentStatus, role;
STOP DATABASE moviesdb;
Backup and restore. neo4j-admin database backup takes an online backup of a running database (Aura and
self-managed clusters differ in exact availability); neo4j-admin database restore loads a backup set back
into a stopped, empty database.
# https://neo4j.com/docs/operations-manual/current/backup-restore/
neo4j-admin database backup moviesdb --to-path=/backups/moviesdb
neo4j-admin database restore moviesdb --from-path=/backups/moviesdb/moviesdb --overwrite-destination=true
Bolt+TLS. Client-driver traffic can be encrypted independently of intra-cluster traffic. Enable it in
neo4j.conf (server.bolt.tls_level=REQUIRED, plus a certificate under server.directories.certificates),
then require it from the driver:
// Driver connection URI schemes select the TLS behaviour, not a Cypher statement:
// neo4j+s:// -- encrypted, full certificate trust
// neo4j+ssc:// -- encrypted, self-signed certificates accepted
// neo4j:// -- unencrypted (only for trusted internal networks)
Auditing. The security event log records authentication attempts and privilege-relevant administrative
actions (user/role/privilege changes, database lifecycle commands) to a dedicated log file, configured
under db.logs.security.* in neo4j.conf. It is a durable trail for who did what, separate from the
regular query log.
Continue with Clustering & multi-database for causal clustering, Fabric and the full multi-database story.