Custom Security Plugins & User-Defined Procedures in Neo4j Enterprise Edition [Security Series, Part 5]

When it comes to graph database security, it’s essential that you have the flexibility to customize every factor of authentication and authorization for your specific deployment. After all, no architecture or organization is the same, so you need the versatility of custom security plugins to ramp up database security and access control according to your desired levels.

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 neo4j password.



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 PredefinedRole.



There is also a combined plugin interface that provides both authentication and authorization in a single method. The following shows a combined plugin called authenticateAndAuthorize verifying neo4j/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 getNeo4jRoleForGroupId method:



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:

 
dbms.security.procedures.roles=apoc.convert.*:apoc_reader,apoc_r;

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).

In forthcoming releases, we will continue enhancing support for fine-grained authorization control by introducing declarative Cypher views. We will continue to build out a portfolio of connectors to external 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.




Catch up with the rest of the Neo4j graph database security series:

• Role-Based Access Control in Neo4j [Part 1]
• Native User Security & Access Control in Neo4j [Part 2]
• Using the LDAP Protocol with Neo4j [Part 3]
• Query Management & Security Event Logging in Neo4j [Part 4]