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 group, 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.
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

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.
• role:reader allows read of any resource.
• (if create.anonymous.user=true is set in stardog.properties) user:anonymous with password anonymous has the reader role.

The user anonymous was created automatically by default prior to version 9.0. Starting with version 9.0, the anonymous user is created only if stardog.properties contains the setting create.anonymous.user=true.

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 and to see which combinations carry meaning.

Valid actions include the following:

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.

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:

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 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:

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:

DELETE Permissions

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

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:

EXECUTE Permissions

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

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, respectively. More specifcally, it will allow the user to online, offline, optimize, and verify the database.

Superusers

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

• 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 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. In other words, *:<resource_name> is not a valid permission.

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.

---