Role-based access control for Perspectives and Scenes

As mentioned in Storage and sharing, when the Bloom server plugin is used, Perspectives are stored in a persistent Neo4j database. This means that not only can Perspectives and Scenes be shared between users, but also that administrators can control user-access to them. For a user to be able to create and/or edit a Perspective, they need to have WRITE access to the _BLOOM_PERSPECTIVE_ label and to the _BLOOM_SCENE_ label to be able to write to a Scene. Note that WRITE access is only needed to these two labels specifically, not the entire database.

Also mentioned in Storage and sharing, is creating custom roles for users which allows administrators to be more explicit with access control.

Even more fine-grained access control is also possible, where administrators can control access down to which property a user can access/edit. Access control, including role management, is described in detail in the Cypher Manual → Access control section.

In addition to WRITE access to _BLOOM_PERSPECTIVE_ and the _BLOOM_SCENE_ labels, a role can be further refined with the CREATE and the SET PROPERTY privileges. By explicitly granting these, instead of a more universal WRITE, administrators can limit access to just creating new nodes and/or update properties in a Perspective or a Scene. See the example further on for an example on how to create a custom role with limited access.

If a user lacks appropriate access, applicable functionality is hidden in Bloom. For example, if a user has not been granted WRITE access to a Perspective, they are not able to see the Create option in the Perspective gallery, they are not able to edit saved Cypher, and they are excluded from any modifications of the Perspective. Accordingly, if a user has not been granted WRITE access to a Scene, they are not able to see the Add new Scene option in the Scene drawer.

temporary scene

If a user lacks WRITE access to Scenes, their access is restricted to a Temporary Scene. This allows for styling and editing of the Scene, but the changes can’t be saved and the Scene is lost at the end of the session.

Example role

Below is an example of how to create a role, custom, with READ access. Users with this role can use a Scene fully, without having WRITE access.

CREATE ROLE custom AS COPY OF reader
GRANT CREATE ON GRAPH `neo4j` NODE _Bloom_Scene_ TO `custom`
GRANT CREATE ON GRAPH `neo4j` RELATIONSHIP _Bloom_HAS_SCENE_ TO `custom`
GRANT SET PROPERTY {*} ON GRAPH `neo4j` NODE _Bloom_Scene_ TO `custom`
GRANT DELETE ON GRAPH `neo4j` NODE _Bloom_Scene_ TO `custom`
GRANT DELETE ON GRAPH `neo4j` RELATIONSHIP _Bloom_HAS_SCENE_ TO `custom`

Perspective actions by database privileges

The following table maps various Perspective actions available to a user according to the database privileges granted to them. Note that this table is applicable for the Bloom plugin setup only, when storage is provided by the plugin and Perspectives may be shared across users. For setups without the plugin, Perspectives are stored locally on the user’s machine and thus the user can perform all relevant actions.

Table 1. Database privileges (with plugin)
Actions Read only Write Write + list roles Write + list and create roles

Open Gallery

Yes

Yes

Yes

Yes

Select Perspective from Gallery

Yes

Yes

Yes

Yes

Allow local Perspective edits

No

Yes

Yes

Yes

Save edits to store

No

Yes

Yes

Yes

Delete Perspective

No

Yes

Yes

Yes

Create new/Generate Perspective

No

Yes

Yes

Yes

Sharing tab

Yes

Yes

Yes

Yes

See already mapped roles

Yes, can view own role(s) but not change

Yes

Yes

Yes

See list of roles

No

No access

Yes

Yes

Map to a role

No

Yes (only default db roles)

Yes

Yes

Delete role mapping

No

Yes

Yes

Yes

Create new role

No access

No access

No

Yes

Export

Yes

Yes

Yes

Yes

Import

No

Yes

Yes

Yes

Users that have write access to the database, i.e. users that can create Perspectives, also have the ability to export and import Perspectives.