Link Search Menu Expand Document
Start for Free

Security

This chapter discusses Security in Stardog. This page discusses Stardog’s security model in detail. For a short description of what else is included in this chapter please see the Chapter Contents.

Page Contents
  1. Overview
  2. Resources
  3. Permissions
    1. Wildcards
    2. Superusers
    3. Database Owner Default Permissions
    4. Default Security Configuration
    5. Setting Password Constraints
    6. Using a Password File
      1. Password File Format
  4. Understanding the Permission Model
    1. Users
    2. Roles
    3. Databases
    4. Permissions
  5. Chapter Contents

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)
  • roles can be assigned to users.

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

Stardog resources can be managed securely by using the tools included in the admin CLI or by programming against Stardog APIs.

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
User user A user (e.g., 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) (named-graph:myDb\named-graph-id)
Virtual Graph virtual-graph A virtual graph (virtual-graph:virtual://dept)
Database Metadata metadata Metadata of a database (metadata:myDB)
Database Admin admin Database admin tasks (e.g., admin:myDB)
Data Quality Constraints icv-constraints Integrity constraints associated with a database (e.g., icv-constraints:myDB)
Sensitive properties sensitive-properties Sensitive properties associated with a database

Permissions

Permissions are composed of a permission subject, an action, and a permission object, which is interpreted as the subject resource can perform the specified action over the object resource.

Permission subjects can be of type user or role only. Permission objects can be of any valid type.

write permission in Stardog refers to graph contents, including mutative operations performed via SPARQL Update (i.e., INSERT, DELETE, etc.). The other permissions, i.e., create and delete, apply to resources of the system itself, i.e., users, databases, database metadata, etc.

Valid actions include the following:

Action Description
read Permits reading the resource properties
write Permits changing the resource properties
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 administration actions over a database
all Special action type that permits all previous actions over a resource

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.

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 user add command:

$ stardog-admin user add --superuser theNewSuperUser

Database Owner Default Permissions

When a user creates a resource, it is automatically granted delete, write, read, grant, and revoke permissions 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.

Default Security Configuration

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.

Setting Password Constraints

To setup the constraints used to validate passwords when adding new users, configure the following settings in the stardog.properties configuration file:

Property Description Default
password.length.min Sets the password policy for the minimum length of user passwords, the value can’t be lower than password.length.min or greater than password.length.max. 4
password.length.max Sets the password policy for the maximum length of user passwords. 1024.
password.regex Sets the password policy of accepted chars in user passwords, via a Java regular expression. [\w@#$%!&]+

Using a Password File

To avoid putting passwords into scripts or environment variables, you can put them into a suitably secured password file. If no credentials are passed explicitly in CLI invocations, or you do not ask Stardog to prompt you for credentials interactively, then it will look for credentials in a password file.

  • On a Unix system, Stardog will look for a file called .sdpass in the home directory of the user Stardog is running as;
  • On a Windows system, it will look for sdpass.conf in Application Data\stardog in the home directory of the user Stardog is running as.

If the file is not found in these locations, Stardog will look in the location provided by the stardog.passwd.file system property.

Password File Format

The format of the password file is as follows:

  1. Any line that starts with a # is ignored

  2. Each line contains a single password in the format:

     hostname:port:database:username:password
  3. Wildcards, *, are permitted for any field but the password field; colons and backslashes in fields are escaped with \.

For example:

#this is my password file; there are no others like it and this one is mine anyway...
*:*:*:flannery:aNahthu8
*:*:summercamp:jemima:foh9Moaz

Of course you should secure this file carefully, making sure that only the user that Stardog runs as can read it.

Understanding the Permission Model

In this section we describe permissions required in order for a user to perform certain actions.

Users

Action Permission Description
Create a user create permission over user:*. Only superusers can create other superusers.
Delete a user delete permission over the user.
Enable/Disable a user User must be a superuser.
Change password of a user User must be a superuser or user must be trying to change its own password.
Check if a user is a superuser read permission over the user or user must be trying to get its own info.
Check if a user is enabled read permission over the user or user must be trying to get its own info.
List users Superusers can see all users. Other users can see only users over which they have a permission.

Roles

Action Permission Description
Create a role create permission over role:*.
Delete a role delete permission over the role.
Assign a role to a user grant permission over the role and user must have all the permissions associated to the role.
Unassign a role from a user revoke permission over the role and user must have all the permissions associated to the role.
List roles Superusers can see all roles. Other users can see only roles they have been assigned or over which they have a permission.

Databases

Action Permission Description
Create a database create permission over db:*.
Delete a database delete permission over db:theDatabase.
Add/Remove integrity constraints to a database write permission over icv-constraints:theDatabase.
Verify a database is valid read permission over icv-constraints:theDatabase.
Online/Offline a database execute permission over admin:theDatabase.
Migrate a database execute permission over admin:theDatabase.
Optimize a database execute permission over admin:theDatabase.
List databases Superusers can see all databases. Regular users can see only databases over which they have a permission.

Permissions

Action Permission Description
Grant a permission grant permission over the permission object and user must have the permission that it is trying to grant.
Revoke a permission from a user or role over an object resource revoke permission over the permission object and user must have the permission that it is trying to revoke.
List user permissions User must be a superuser or user must be trying to get its own info.
List role permissions User must be a superuser or user must be trying to get its own info.

Chapter Contents