In the same vein, it’s essential that access and permission to execute user-defined procedures remain tightly controlled, especially for certain organizations and deployments.
In Neo4j Enterprise Edition (versions 3.1 and beyond), you have both of these domains – custom security plugins and access control for user-defined procedures – perfectly under your control.
In this series on graph database security and access control, we’ll explore all of the different facets and features available in Neo4j Enterprise Edition to keep your graph data secure. In past weeks, we’ve looked at role-based access control in Neo4j, administering native user security and authorization, using the LDAP protocol, query management, and security event logging.
This week, we’ll take a closer look at custom security plugins as well as fine-grained access control to user-defined procedures.
Custom-Built Authorization and Authentication Plugins
Neo4j 3.1 introduced authentication and authorization plugin interfaces to support real-world deployment scenarios not covered by built-in native users or the built-in configuration-based LDAP connector.
Interface definitions reside in the
org.neo4j.server.security.enterprise.auth.plugin.spi package. Custom-built plugins have access to the
neo4j.conf configuration file to load any custom settings and have ability to write to the security event log.
The authentication plugin implements the
AuthPlugin interface with the
authenticate method. The example below shows a minimal authentication plugin that checks for
neo4j user with
The authorization plugin implements the
AuthPlugin interface with the
authorize method. The example below shows a minimal authorization plugin that assigns the reader role to a user named
neo4j. Note the usage of the helper class
There is also a combined plugin interface that provides both authentication and authorization in a single method. The following shows a combined plugin called
neo4j credentials and returning reader role authorization:
The reason for exposing such a rich extension point is that some deployments may not easily be configured through the standard LDAP connector. One known integration complexity is an LDAP user directory where groups have users as a member and not other way around.
The example below first searches for a group that the user is member of, and then maps that group to the Neo4j role by calling the custom-built
Read more here about this and other customer security plugin examples.
Define Roles with Permission to Execute User-Defined Procedures
Neo4j 3.1 introduces a feature to map specific user-defined procedures with the list of roles that have explicit permission to execute it:
This is especially valuable if the procedure reads or modifies only a portion of the graph. When the created user is assigned only a custom role (e.g., no reader or publisher role, etc.), then that user only has a specific sub-graph access.
Authorizing roles to execute user-defined procedures is an evolving Neo4j feature. While the solution today involves setting execution permissions in a static configuration file, we plan to add an ability to assign permissions interactively.
Conclusion, Best Practices and the Path Forward
The 3.1 release of Neo4j Enterprise Edition raised the bar for safeguarding data and meeting compliance requirements by adding role-based authorization, federated authentication via LDAP/Active Directory, procedure-based fine-grained access control and other high-value database security features.
When deploying in production, follow standard database security best practices:
- Deploy Neo4j on a safe server in a safe network; use subnets and close all unused ports.
- Use the latest patch version of Neo4j and leave RMI turned off.
- Manage access to logs and backups.
- In LDAP deployment, use LDAPS and system-account to access authorization.
- Protect data-at-rest: Use volume encryption (e.g., Bitlocker).
- Protect data-in-transit: Use your own certificates and require establishing encrypted Bolt sessions remotely.
- Protect PII data: Use application-level encryption (e.g., Neo4j’s Object Graph Mapping library).
auth providers – support for Kerberos being highest priority.
We will also propagate native users and roles information across the cluster seamlessly, removing the need for workarounds such as a network file system or rsync.
Read the White Paper
Catch up with the rest of the Neo4j graph database security series: