As a followup to Possible timeline of implementing ACL’s in Dgraph, and a continutation to some parts of the discussion at Indexes and Transactions, I’m creating this thread as an attempt to start a discussion on how Dgraph can be used to support a multi-tenant application.
I will preface this by saying that I am not a SaaS expert, and my security experience is with single-tenant enterprise applications. However, here is a rough outline of the way security of our app should work, and hopefully we can go from a discussion of these high-level requirements to a specific solution for Dgraph.
Multi-Tenant Security Requirements
“Namespace-driven” behavior. Namespaces include:
a. Individual user namespace: private to user, with ability to share items with other specific users
b. Group namespaces, including namespace hierarchies. Examples are “workspaces” and “projects” in Asana. Driven by security groups, controlled by the admin for the given namespace.
- Individual-user authentication with Dgraph database, and to have access to data controlled by individual- and group- level security natively at the database level. Criticality of tenant privacy requires a native database solution to ensure that access to information is predicated on secure authentication and explicit access to the information being requested.
Very interested in feedback on these requirements. Something I found interesting from https://www.experoinc.com/post/multi-tenant-applications-in-neo4j is that even though Neo4j has been around for 10 years, per the article as of December 2016, Neo4j does not have a “comprehensive plan for multi-tenancy”. From my perspective, this is a critical and obvious capability to have in a graph database. Similar to the Dgraph team’s decision to tackle distributed transactions, maybe an early native multi-tenancy solution could provide yet another reason to choose Dgraph over competitors for SaaS applications.