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.

<details open markdown="block"> <summary> Page Contents </summary> 1. TOC </details>

---

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:

Function	Resources
Add data source	CREATE on data-source
Add virtual graph with shared data source	CREATE on virtual-graph<br>READ on data-source
Add virtual graph with private data source	CREATE on virtual-graph<br>CREATE on data-source
Update virtual graph with shared data source	CREATE, DELETE on virtual-graph<br>READ on data-source
Update virtual graph with private data source	CREATE, DELETE on virtual-graph<br>CREATE, DELETE on data-source
See that a virtual graph exists, list, get info	Any of READ, CREATE, DELETE on virtual-graph
Get data source options	READ on data-source
Get virtual graph options	READ on virtual-graph
Get virtual graph mappings	READ on virtual-graph
Online data source	CREATE, DELETE on data-source<br>CREATE, DELETE on ALL dependent virtual-graph
Online virtual graph	CREATE, DELETE on data-source that the virtual graph uses<br>CREATE, DELETE on ALL dependent virtual-graph
Remove data source	DELETE on data-source<br>DELETE on ALL dependent virtual-graph
Remove virtual graph	DELETE on data-source (if private data source)<br>DELETE on ALL dependent virtual-graph
Update data source without dependent virtual graph	CREATE, DELETE on data-source
Update data source with dependent virtual graph	CREATE, DELETE on data-source<br>CREATE, DELETE on ALL dependent virtual-graph
Share private data source	WRITE on data-source
Refresh data source counts	READ, WRITE on data-source
See that a data source exists, list, get info	Any of READ, CREATE, DELETE on data-source
Generate data model	Any of READ, CREATE, DELETE on virtual-graph
Get data source metadata (beta)	READ on data-source
Replace data source metadata (beta)	WRITE on data-source
Query a virtual graph	See Accessing Virtual Graphs
Map a data source in Designer	EXECUTE on data-source

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 Entra ID, virtual graphs that connect to a Databricks database, that itself is secured using Entra ID, 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

Footnotes

1. All CREATE permissions on the data-source and virtual-graph resources should be granted over a wildcard (i.e., the permission should be CREATE data-source:* or CREATE virtual-graph:*). ↩