Authorization

Roles

Roles (Configuration > Authentication > Roles) are named sets of permissions and restrictions that make it easier to allow many similar users to carry out common tasks, or to assign permissions in sets if multiple users have overlapping needs for different modules. If you have multiple users or groups of users needing similar sets of permissions, assigning a single role is much faster than assigning a large number of permissions to multiple users one at a time.

As the Icinga 2 documentation explains, by default all actions are prohibited. Permissions granted by multiple roles are summed together, while multiple restrictions have a bit more complex behavior.

In general, permissions allow users to perform a certain set of actions. They are separated into hierarchical namespaces corresponding to the names of modules, where the * (wildcard) character can be used to designate all permissions within a given namespace. Restrictions instead are used limit information that can be viewed in forms, dashboards, reports, etc. and support the same filtering expressions used in monitoring.

Some examples of roles include:

• A root role can give all permissions at once by enabling the Administrative Access setting.

• Assigning users permissions per module such as:

  • Access to the Analytics module

  • Configuring elements in Director

  • Showing all business processes (see the example in Fig. 9)

• Allowing operators to do only specific tasks like:

  • Allow configuration of notifications (director/notifications)

  • Allow processing commands for toggling active checks on host and service objects (monitoring/command/feature/object/active-checks)

  • Allow adding comments but not necessarily deleting them (monitoring/command/comment/add)

To create a new role, click on the action Create a New Role as shown in Fig. 8. You can also edit an existing role by clicking on the role’s Name in the table, and remove a role by clicking on it at the right side of that role’s row.

Fig. 8 The list of existing roles.

Permissions can be granted on a per-module basis using the form at the bottom of the New Role panel as shown in:numref:figure-create-role. An incomplete list of permissions can be found in Icinga’s official documentation. For restrictions, you must enter the appropriate filtering expression. These expressions can reference defined variables such as user and group names and use regular expressions.

Note

Whenever you change permissions or restrictions for any module, you will need to log out of NetEye and then log back in before the new settings will take effect.

Fig. 9 Adding a new role with permissions and restrictions.

Single Page Application in NetEye

NetEye implements the possibility to work in Single Page Application mode, in order to meet the requirements of all those users that need to use a single NetEye module.

For all the users belonging to roles where the Single Page Application is configured, NetEye will redirect them immediately to the configured application right after the login. This means that the user will not have access to the full NetEye sidebar and dashboard, but will see only the applicationq he is allowed to use in fullscreen mode (i.e. without topbar and sidebar).

How to correctly setup a role for Single Page Application

The Single Page Application is managed as an additional restriction. To correctly set up a role for users that have access only to one of the NetEye modules you should:

• set desired module permission as usual; for example if you want to grant user access to GLPI, you can follow the GLPI configuration guide <glpi-permissions>

• set the correct redirect URL in the icingaweb2-module-neteye restriction section, where you will find the option single-page-application/redirect-url. Here, put the URL the user will be redirected to, upon login.

Note

If a user belongs to more than one role with Single Page Application enabled, he will see the NetEye interface as usual, this means that he will not be redirected to one of the module, but he will land to NetEye main dashboard, and he will be able to navigate through NetEye using the sidebar.

Module Permissions and Single Sign On Within NetEye

NetEye modular architecture allows to integrate third-party modules to increase its functionalities. However, accessing some module in NetEye may require a dedicated user, proper of the module. This situation therefore implies that to carry out some activities within NetEye different users are required: one for NetEye itself, one for the module.

In order to ease access to all third-party modules installed on NetEye 4, the Single Sign On (SSO) functionality has been implemented for a few modules and will be soon extended to other. This chapter describes how module permissions work in NetEye and then presents the SSO’s underlying logic.

Users, Roles, and Module Permissions

In this section we define and quickly outline the main properties and interaction of Users, roles, and permissions on modules.

1. A User is an account that allows to login to NetEye and can have different Roles.

2. A Role is a set of permissions on one or multiple modules.

3. A Permission on a module is a rule that define the level of access to a module. Modules offer usually different levels of access; there are however two permissions common to every module:

   • Full Module Access grants administrative access to the module. In other words, every functionality of the module is available.

   • General Module Access permits only to see the module in the menu, but is a requirement to assign other permissions, if available for that module.

4. A Restrictions allow to specify one or more subsets of either allowed actions, or accessible entities for the Role.

   Except these two permissions Full Module Access and General Module Access, each module can have extra permissions and restrictions. Those are defined in their respective modules and explained how to use them.

Note

If a user has more than one Role, the “merging” behaviour is up to each module

Single Sign On Architecture

The SSO mechanism implemented in NetEye allows one to log in to NetEye with a unique user, call it john-acme, and access all modules configured for SSO, provided the role associated to john-acme, has the corresponding permissions on those modules.

If john-acme has role with the permission to access the SSO-enabled module, when first time he tries to access module from neteye, a new profile for john-acme will be created automatically with defined permission and restriction in the module.