Configuring ACL in Siren Investigate

This section describes how to configure the Siren Investigate access control list (ACL) system. The ACL system allows you to define access rules for saved objects and to control access to parts of the user interface.


Before you begin, ensure that Siren Investigate has been configured to work with the security system that is enabled in your Elasticsearch cluster.

For systems that use Elasticsearch security, see Elastic Stack security overview .

For systems that use Search Guard, see Search Guard overview .

The Access Control app

To open the Access Control app, log in as a user with an administrative role, such as sirenadmin. From the app, you can manage ACL rules and authentication resources.

The Access Control app


The Authentication tab allows you to browse, edit and create the following resources:

  • Internal users

  • Roles

  • Role mappings

  • Action groups (only applicable when using Search Guard)

To verify that the application is working correctly, click Roles then click Open; you should see the list of roles that are defined in the system.

If you get an error when you try to open the Authentication tab, your user might not be authorized to use the REST API. When using Search Guard, verify that the setting searchguard.restapi.roles_enabled in the elasticsearch.yml file contains the role of your administrative user.


The ACL tab allows you to define Siren Investigate roles, which are collections of permissions for saved objects and UI elements.

Each Siren Investigate role can be mapped to one or more Elasticsearch roles.

For each Siren Investigate role, you can define two kinds of rules:

  • Saved object rules: Permissions for saved object types, such as dashboards and visualizations.

  • UI rules: Permissions for the visibility of user interface elements, for example, to block access to the Siren Alert app or the Export CSV button.

The everyone role defines the default permissions for all of the users in the system. By default, it grants the following permissions:

  • Read-only access to the Siren Investigate configuration in Advanced settings, saved searches and index patterns.

  • Permission to view all applications and UI elements.

The everyone role

Usually, it is not required to create explicit UI rules for the Dashboard application, because access to specific dashboards can be restricted by using saved object rules.

For most setups it makes sense to grant view permissions on visualizations as well, then set specific permissions on dashboards and dashboard groups for each role.

When a user does not have permission to view an application or section, or such permission is explicitly denied, the system will hide links in the navigation menu and deny access when these are accessed through a direct link.

Defining a new ACL role

To define a new role, click Create role, then set the following parameters:

  • Role ID: The ID of the role, for example, sirenuser. The role ID must be a lowercase, alphanumeric string.

  • Elasticsearch roles: The Elasticsearch roles that will be mapped to this Siren Investigate role, for example, sirenuser.

  • Saved object rules: The list of rules for saved object types.

  • UI Rules: The list of rules for UI elements.

Each rule is defined by the following three parameters:

  • Action: Allow or deny.

  • Permission: The permission to allow or deny.

  • Context: The saved object type or UI element on which the permission is enforced.

Creation of an ACL role

Object permissions

In addition to role-level permissions, it is possible to define permissions for specific objects by going to Management > Save Objects and clicking the Permissions button that is next to an object:

The object permissions button

The object permissions form allows you to set the owner of the object and define custom access rules.

By default, the owner is set to the user that created the object; the owner has all permissions on the created object; it is possible to unset the owner of an object by leaving the field blank and clicking the Save button.

Custom access rules can be used to grant access to an object that would be otherwise hidden; for example, if everyone is not granted to display dashboards but you want to display the Overview dashboard to all users, visit the object permissions form for the Overview dashboard and set the View permission for everyone to Allow.

If everyone can see dashboards but you would like to hide the IT dashboard to users, set the View permission for everyone to Deny.

The object permissions form