Named Graph Security
This page discusses security for the named-graph resource type in Stardog’s security model. We discuss how named graph permissions work and how to restrict access to them.
Page Contents
Overview
With Named Graph Security, Stardog lets you specify which named graphs a user can read from or write to; that is, named graphs are an explicit resource type in Stardog’s security model.
Named Graph Operations
Stardog does not support the notion of an empty named graph; thus, there is no operation to create a named graph. Deleting a named graph is simply removing all the triples in that named graph, so it’s also not a special operation. For this reason, only read and write permissions can be used with named graphs, and create and delete permissions cannot be used with named graphs.
How Named Graph Permissions Work
The set of named graphs to which a user has read or write access is the union of the named graphs for which it has been given explicit access plus the named graphs for which the user’s roles have been given access.
To grant a user permissions to a named graph:
$ stardog-admin user grant -a read -o 'named-graph:myDB\http://example.org/g1' myUser
$ stardog-admin user grant -a write -o 'named-graph:myDB\http://example.org/g2' myUser
Note the use of \ to separate the name of the database, myDB, from the named graph identifier, http://example.org/g1.
Named Graph Security is disabled by default. It can be enabled globally by setting security.named.graphs=true in stardog.properties or per database. Additionally, named graph security cannot be disabled per database if it is enabled for the entire server.
Querying a Secured Named Graph
An effect of named graph permissions is the RDF dataset associated with a query changes. The default and named graphs specified for an RDF dataset will be filtered to match the named graphs a user has read access to.
A read query never triggers a security exception due to named graph permissions. The graphs a user cannot read from would be silently dropped from the RDF dataset for the query. This may cause the query to return no answers despite there being matching triples in the database.
The RDF dataset for SPARQL update queries will be modified similarly based on read permissions. The dataset for an update query only affects the WHERE clause.
Writing to a Secured Named Graph
Write permissions are enforced by throwing a security exception whenever a user that does not have write access attempts to update a named graph. Adding a triple to an unauthorized named graph will raise an exception, even if that triple already exists in the named graph. Similarly, trying to remove a non-existent triple from an unauthorized graph raises an error.
The unauthorized graph may not exist in the database; any graph that is not explicitly listed in a user’s permissions is unauthorized.
Updates succeed or fail as a whole. If an update request tries to modify both an authorized graph an unauthorized graph, it would fail without making any modifications.
Reasoning
Stardog allows a set of named graphs to be used as the schema for reasoning. The OWL axioms and rules defined in these graphs are extracted and used in the reasoning process. The schema graphs are specified in the database configuration and affect all users running reasoning queries.
Named graph permissions do not affect the schema axioms used in reasoning, and every reasoning query will use the same schema axioms. This is true even though some users might not have been granted explicit read access to schema graphs. However, non-schema axioms in those named graphs would not be visible to users without authorization.