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.
To open the Access Control app, log in as a user with an administrative role, such as
From the app, you can manage ACL rules and authentication resources.
The Authentication tab allows you to browse, edit and create the following resources:
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
searchguard.restapi.roles_enabled in the
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.
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.
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.
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,
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.
In addition to role-level permissions, it is possible to define permissions for specific objects by going toand clicking the Permissions button that is next to an object:
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
dashboard and set the
View permission for
everyone can see dashboards but you would like to hide the
dashboard to users, set the
View permission for