Virtual Graph Security

This page discusses security for the data-source and virtual-graph resource types in Stardog’s security model. For more information on what virtual graphs are and how they work, please see the chapter dedicated to Virtual Graphs.

Page Contents

1. Managing Virtual Graphs
2. Accessing Virtual Graphs
   1. OAuth Passthrough Authentication
3. Notes

---

Managing Virtual Graphs

To manage data sources and virtual graphs, the user must be granted access to the data-source and virtual-graph security resource types¹. Managing virtual graphs often requires permissions for a combination of both data-source and virtual-graph resources, as shown in the following table:

For example, to add a virtual graph with a private data source, create permissions for virtual-graph and data-source are required.

   $ stardog-admin user grant -a create 'data-source:*' theUser

   $ stardog-admin user grant -a create 'virtual-graph:*' theUser

And to add a virtual graph with a shared data source, create permissions for virtual-graph and read for data-source are required.

   $ stardog-admin user grant -a read 'data-source:data-source://shareddsname' theUser

   $ stardog-admin user grant -a create 'virtual-graph:*' theUser

To remove a data source that has dependent virtual graphs, delete permissions on data-source and virtual-graph (in this example, a single private data source) are required.

$ stardog-admin user grant -a delete 'data-source:data-source://dept' theUser

$ stardog-admin user grant -a delete 'virtual-graph:virtual://dept' theUser

Accessing Virtual Graphs

Accessing virtual graphs is controlled the same way as regular named graphs, as explained in the Named Graph Security section:

• If named graph security is not enabled for a database, all registered virtual graphs in the server will be accessible through that database.
• If named graph security is enabled for a database, then users will be able to query only the virtual graphs for which they have been granted access.

If the virtual graphs contain any sensitive information, it is recommended to enable named graph security globally by setting security.named.graphs=true in stardog.properties. Otherwise, creating a new database without proper configuration would allow users to access those virtual graphs.

The Named Graph Security settings apply to virtual graphs, regardless of the manner in which they are accessed. The following three queries are identical, with one exception. The attempts to access a virtual graph using the SERVICE keyword result in an error when there are insufficient permissions, while queries that use the GRAPH or FROM keywords will treat the virtual graphs as empty and return no results (but without error).

SELECT * {
   GRAPH <virtual://dept> {
      ?person a emp:Employee ;
           emp:name "SMITH"
   }
}

SELECT * FROM <virtual://dept> {
   ?person a emp:Employee ;
        emp:name "SMITH"
}

SELECT * {
   SERVICE <virtual://dept> {
      ?person a emp:Employee ;
           emp:name "SMITH"
   }
}

OAuth Passthrough Authentication

If Stardog has been configured to perform authentication using Microsoft’s Azure Active Directory, virtual graphs that connect to a Databricks database, that itself is secured using Azure AD, can be configured to pass through the credentials of the Stardog user to the Databricks connection, limiting the virtual graph to that which is accessible to the user’s Databricks account. See Virtual graph pass-through authentication for details.

Notes

---