Link Search Menu Expand Document
Start for Free

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
  1. Overview
  2. Named Graph Operations
  3. How Named Graph Permissions Work
    1. Querying a Secured Named Graph
    2. Writing to a Secured Named Graph
    3. Reasoning

Overview

With Named Graph Security added in Stardog 3.1, Stardog lets you specify which named graphs a user can read from or write to; that is, named graphs are now 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 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 (for backwards compatibility with the installed base). It can be enabled globally by setting security.named.graphs=true, in stardog.properties globally, or per database.

Querying a Secured Named Graph

An effect of named graph permissions is changing the RDF Dataset associated with a query. The default and named graphs specified for an RDF Dataset will be filtered to match the named graphs that a user has read access to.

A read query never triggers a security exception due to named graph permissions. The graphs that a user cannot read from would be silently dropped from the RDF dataset for the query, which 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 named graph is being updated by a user that does not have write access to the 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 either succeed as a whole or fail. 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 even though some users might not have been granted explicit read access to schema graphs. But non-schema axioms in those named graphs would not be visible to users without authorization.