This section covers the topic of BrightstarDB server security from multiple viewpoints. The security features of BrightstarDB are basic but designed to be customizable to fit with different schemes of user authentication and authorization.
Access controls for BrightstarDB services is a work in progress. Previous releases had no form of access control and there is much work to complete to reach the desired state. Rather than wait until everything is all completed, this release provides the framework for access controls and future releases will build on that framework to deliver incremental increases in functionality. Comments and suggestions for improvements in this area are most welcome.
BrightstarDB is secured at the store level. A user that has read access to a store has read access to all the data in the store. A user with the required update privileges can update or delete any of the triples in the store. The permissions for a user on a store can be any combination of the following:
- The user has no permissions on the store and can perform no operations on it at all
- The user has permission to perform SPARQL queries on the store
- The user can run an export job to retrieve a dump of the RDF contained in the store
- The user can view the commit and transaction history of the store
- The user can post updates to the store using the SPARQL update protocol
- The user can post updates to the store using the BrightstarDB transactional update protocol
- The user can re-execute previous transactions; revert the store to a previous transaction; and delete the store
- The user can grant permissions on this store to other users
- A combination of all of the above permissions
In addition to permissions on individual stores, users can also be assigned permissions on the BrightstarDB server as a whole. These permissions control only the ability to list, create and delete stores. The system permissions for a user can be any combination of the following:
- The user has no system permissions. This level denies even the listing of the stores currently available on the server.
- The user can list the stores available on the server. Note that the listing is not currently filtered by store access permissions, so the user will see all stores regardless of whether or not they have any permission to access the stores.
- The user can create new stores on the server.
- The user can delete stores from the server regardless of whether they have permissions to administer the individual stores themselves.
- A combination of all the above permissions.
User authentication is the responsibility of the host application for the BrightstarDB service. There are several different approaches which can be taken to user authentication for a REST-based API and the structure of BrightstarDB enables you to plug or leverage the form of authentication that works best for your solution.
If the BrightstarDB service is hosted under IIS, you can use IIS Basic Authentication or Windows Authentication to protect the service. This requires that the client provides credentials and that those credentials are checked for each request made. If the credentials are valid, the user identity for the request will be set to the identity associated with the credentials. If the credentials are invalid, the request will be rejected without further processing.