Authorization
Livestatus supports addon developers by helping to implement authorization. You can let Livestatus decide whether a certain contact may see data or not. This is very simple to use. All you need to do is to add an AuthUser header to your query with the name of a Nagios contact as single argument. If you do that, Livestatus will only display data that name is a contact for – either directly or via a contact group. Example:
GET services Columns: host_name description contacts AuthUser: harri
In certain cases it would be possible to replace AuthUser with a Filter header. But that does not work (precisely) in all situations.
Configuration
If your addon uses AuthUser, the administrator has a way to configure authentication details via nagios.cfg – and thus can do this uniformely across all addons using Livestatus. Currently two configuration options are available. Both can be set either to strict or loose:
| option | default | description |
|---|---|---|
| service_authorization | loose | Nagios automatically regards a contact for a host also as a contact for all services of that host. We call this method loose. By setting it to strict, one must be an explicity contact of a service in order to see it. Please note that Nagios makes all services that do not have any contact at all inherit all contacts of the host – regardless whether this option is set to strict or loose. |
| group_authorization | strict | Nagios lets a contact see a host group or service group only if he is contact for all members of that group. We call that method strict. By setting it to loose it will be sufficient to be a contact for at least one member of the group in order to see the group itself. |
Tables supporting AuthUser
The following tables support the AuthUser header (others simply ignore it): hosts, services, hostgroups, servicegroup and log. The log-table applies the AuthUser only to entries of the log classes 1 (host and service alerts), 3 (notifications) and 4 (passive checks). All other classes are not affected.