Link Search Menu Expand Document
Start for Free

Security Model

This page discusses Stardog’s security model in detail. See Managing Users and Roles for instructions to create and manage users and roles in Stardog.

Page Contents
  1. Overview
  2. Authentication
  3. Authorization
  4. Default Security Configuration
  5. Permissions
    1. Anatomy of a Permission
    2. Actions
    3. Resources
    4. Valid Permissions
    5. CREATE Permissions
    6. READ Permissions
    7. WRITE Permissions
    8. DELETE Permissions
    9. GRANT/REVOKE Permissions
    10. EXECUTE Permissions
    11. Database Owner Default Permissions
    12. Superusers
    13. Wildcards
      1. Named Graphs and Wildcards

Overview

Stardog’s security model is based on standard role-based access control:

  • users have permissions over resources during sessions
  • permissions can be grouped into roles
  • roles can be assigned to users.

Stardog resources can be managed securely by using the tools included in the Stardog Admin CLI with commands in the user and role commands groups, by programming against Stardog APIs, or via Stardog Studio. See Managing Users and Roles for examples of managing resources from Studio and the CLI.

Authentication

Stardog uses Apache Shiro for authentication, authorization, and session management and jBCrypt for password hashing.

Stardog offers a few different ways to authenticate users:

  1. Default authentication
    • Stardog internally manages user accounts and passwords
    • Users and Roles granted access to Resources
    • Users can be enabled / disabled
    • Password requirements set at server level. See Setting Password Constraints below.
  2. LDAP Authentication
    • Stardog delegates authentication of user accounts to LDAP system
    • Stardog continues to manage User/Role access to Resources
    • Role membership determined from LDAP groups
    • See LDAP Integration for configuration instructions.
  3. Kerberos Authentication
    • Stardog delegates authentication of user accounts to Kerberos system
    • Stardog continues to manage User/Role access to Resources
    • See Kerberos for configuration instructions.

Authorization

Authorization in Stardog works like so:

  1. Users and Roles are granted specific access to Resources independent of how you are authenticating users.
  2. While explicit grants to individual Users are allowed, it is highly encouraged to utilize Roles as much as possible
    • Easily grant batches of permissions to a given User by assigning a Role
    • Easily know what permissions Users have by looking at Roles

Default Security Configuration

Warning

Do not deploy Stardog in production or in hostile environments with the default security settings.

Out of the box, the Stardog security setup is minimal and insecure.

  • user:admin with password set to admin is a superuser
  • user:anonymous with password anonymous has the reader role
  • role:reader allows read of any resource.

Permissions

Anatomy of a Permission

  1. Permissions consist of a Subject, Action, and Resource
    • Subject can perform Action over Resource
  2. Subject is either a User or a Role
  3. Resource consists of a resource type followed by a resource identifier or wildcard.

Actions

Any Action (listed below) can be granted over any Resource.

Some combinations, while allowed, are meaningless. See Valid Permissions below for an explanation of all combinations in addition to see which combinations carry meaning.

Valid actions include the following:

Action Description
read Permits reading the resource
write Permits changing the resource
create Permits creating new resources
delete Permits deleting a resource
grant Permits granting permissions over a resource
revoke Permits revoking permissions over a resource
execute Permits executing actions over a resource
all Special action type that permits all previous actions over a resource

Resources

A resource is some Stardog entity or service to which access is controlled. Resources are identified by their type and their name. A particular resource is denoted as type_prefix:name. The valid resource types with their prefixes are shown below.

Resource Prefix Description Example
User user A user user:admin
Role role A role assigned to a user role:reader
Database db A database db:myDB
Named Graph named-graph A named graph (graph subset); resource name is composed of database name and graph name named-graph:myDb\myGraph
Virtual Graph virtual-graph Virtual graph metadata virtual-graph:virtual://dept
Data Source data-source A data source data-source:data-source://theDs
Database Metadata metadata Metadata (configuration) of a database metadata:myDB
Server Admin dbms-admin Server administration tasks: shutdown server, set server properties dbms-admin:shutdown
Database Admin admin Database admin tasks: Verify, Optimize, Online/Offline admin:myDB
Data Quality Constraints icv-constraints Integrity constraints associated with a database icv-constraints:myDB
Sensitive properties sensitive-properties Sensitive properties associated with a database sensitive-properties:myDB\sensitivePropertyGroupName
Stored Queries stored-query Stored queries associated with a database stored-query:myDB

Valid Permissions

Recall, any Action can be granted over any Resource. Some combinations, while allowed, are meaningless. The table below demonstrates what permissions are valid and in turn have meaning.

The following sections describe what all of these combinations in the above matrix mean. We use the following notation to denote what action is granted over a resource.

[action, "resource_type:resource_type_prefix:name"]

This syntax does not denote a complete permission. Permissions consist of a Subject, Action, and Resource - the Subject being either a user or role.

Examples:

  • [CREATE, “db:*”]
  • [READ, “db:myDb”]
  • [GRANT, “virtual-graph:virtual://myVG”]
  • [READ, “named-graph:myDb\http://stardog.com/graphs/graph1”]

CREATE Permissions

Granting a resource CREATE access can mean different things depending on what resource it was granted over. Recall the valid permissions table:

We describe what each of these permission combinations mean:

Permission Combination Description
[CREATE, “type:*”] Create instances of a given Resource type
[CREATE, “virtual-graph:*”] - With [READ, “data-source:data-source://mySource”] - Add a virtual graph with given data source

- With [CREATE, “data-source:*”] - Add a virtual graph with a private data source

- With [DELETE, “virtual-graph:virtual://myVg”] - Update an existing virtual graph

The [CREATE, “user:*”] permission allows a non-superuser to create new, non-superuser users. Creating a superuser requires that the creating user also be a superuser. With Stardog versions 7.8.0 and earlier there were no restrictions on what kind of users that could be created with the [CREATE, “user:*”] permission.

READ Permissions

Granting a resource READ access can mean different things depending on what resource it was granted over. Recall the valid permissions table:

We describe what each of these permission combinations mean:

Permission Combination Description
[READ, “db:myDb”] Database appears in list of databases. Full query access (except with respect to named graph security). Access to BITES document store count and documents
[READ, “user:myUser”] User appears in list of users. Can see enabled status, permissions, and roles
[READ, “role:myRole”] Role appears in list of roles. Can see effective permissions
[READ, "dbms-admin:set-property"] allows user to read server properties.
[READ, "dbms-admin:metrics"] allows user to read server metrics.
[READ, “metadata:myDb”] Read access to database properties/settings
[READ, “named-graph:myDb\myGraph”] When named graph security is enabled, read access to triples in the graph
[READ, “virtual-graph:virtual://myVG”] Virtual graph appears in list of virtual graphs. Full read access to virtual graph metadata.
[READ, “data-source:data-source://mySource”] Data source appears in list of data sources. Can view data source options. Can create virtual graph backed by it.
[READ, "sensitive-properties:myDb\sensitivePropertyGroupName"] Allows user to read the values of sensitive properties in database

WRITE Permissions

Granting a resource WRITE access can mean different things depending on what resource it was granted over. Recall the valid permissions table:

We describe what each of these permission combinations mean:

Permission Combination Description
[WRITE, “db:myDb”] Perform SPARQL Update queries and SNARL (Java) update operations. Add/remove/clear documents from BITES store
[WRITE, “user:myUser”] Change user’s password
[WRITE, dbms-admin:set-property] Allows one to set server properties
[WRITE, “metadata:myDb”] Modify database properties/settings. Add/remove stored queries
[WRITE, “named-graph:myDb\myGraph”] When NG security enabled, write access to the graph
[WRITE, “data-source:mySource”] Can share a private data source. Can refresh data source metadata and row-count estimates.
[WRITE, “icv-constraints:myDb”] Modify and delete a database’s ICV Constraints

DELETE Permissions

Granting a resource DELETE access can mean different things depending on what resource it was granted over. Recall the valid permissions table:

Permission Combination Description
[DELETE, “type:*”] Delete instances of a given Resource type
- Can also explicitly name DBs, Users, etc.
- With [CREATE, “virtual-graph:*”] - Update or online a given virtual graph
- With [CREATE, “data-source:*”] - Update or online a given data source
Onlining a data source or virtual graph requires CREATE and DELETE on the data-source used by the virtual graph as well as CREATE and DELETE on all virtual graphs that depend on that data source

GRANT/REVOKE Permissions

Granting a resource GRANT and REVOKE access can mean different things depending on what resource it was granted over. Recall the valid permissions table:

Permission Combination Description
[GRANT, “type:name”] Add other users to the Access Control List (ACL) of a given resource
- If and only if the user doing the granting has the permission being granted
[REVOKE, “type:name”] Remove other users from the ACL of a given resource

EXECUTE Permissions

Granting a resource EXECUTE access can mean different things depending on what resource it was granted over. Recall the valid permissions table:

Permission Combination Description
[EXECUTE, “admin:myDb”] Backup, Verify, Optimize, Online/Offline a database
[EXECUTE, “dbms-admin:shutdown”] Explicit permission to remote shutdown a server
[EXECUTE, “user:myUser”] Special case allowing a user to run a command impersonating another user
- Allows an admin user to test read/write access of a given user

The [EXECUTE, “user:*”] permission would allow a user to impersonate any other non-superuser. Impersonating a superuser, however, requires superuser privileges. With Stardog versions 7.8.0 and earlier there were no restrictions on what kind of users that could be impersonated with the [EXECUTE, “user:*”] permission.

Database Owner Default Permissions

When a user creates a resource, it is automatically granted delete, write, read, grant, and revoke access over the new resource.

If the new resource is a database, then the user is additionally granted write, read, grant, and revoke permissions over icv-constraints:theDatabase and execute permission over admin:theDatabase. These latter two permissions give the owner of the database the ability to administer the ICV constraints for the database and to administer the database itself. More specifcally it will allow the user to online, offline, optimize, and verify the database.

Superusers

It is possible at user-creation time to specify that a given user is a superuser.

  • Being a superuser is equivalent to having been granted an all permission over every resource, i.e., *:*. Therefore, as expected, superusers are allowed to perform any valid action over any existing (or future) resource.

Example creating a superuser from the command line using the user add Stardog Admin CLI command:

$ stardog-admin user add --superuser theNewSuperUser

Wildcards

Stardog understands the use of wildcards to represent sets of resources. A wildcard is denoted with the character *. Wildcards can be used to create complex permissions; for instance, we can give a user the ability to create any database by granting it a create permission over db:*. Similarly, wildcards can be used in order to revoke multiple permissions simultaneously.

Wildcards can be used for resource types only if the resource name is also a wildcard.

Named Graphs and Wildcards

Wildcards cannot be used to grant permissions over named graphs. Named graph permissions should always be granted over a specific graph.