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.
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:
- 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.
- 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.
- 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:
- Users and Roles are granted specific access to Resources independent of how you are authenticating users.
- 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 toadmin
is a superuseruser:anonymous
with passwordanonymous
has thereader
rolerole:reader
allowsread
of any resource.
Permissions
Anatomy of a Permission
- Permissions consist of a Subject, Action, and Resource
- Subject can perform Action over Resource
- Subject is either a User or a Role
- 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.