Access Control

The access control in Opsview is dependent on the contact/user logged in and their role.

The flexible access control is introduced in Opsview 3.1.

A contact has one role. This role has many accesses.

The accesses available are listed here: access

To restrict pages, Opsview uses Catalyst::Plugin::Authorization::ACL.

In Opsview/Web.pm, use PACKAGE→allow_access_if and →deny_access_unless to allow or deny access to specified URLs.

Not that the URLs are checked from the most specific backwards up the URL.

If a rule fails, the next rule is examined. This is very important! Make sure you have tests that check whether it works as expected.

CONFIGUREVIEW and CONFIGURESAVE are access points for the configuration. The idea is that a user with only CONFIGUREVIEW can still view all the configuration screens, but not be able to make any changes or run any commands through the UI.

Normally, do not show any screens or links that are not applicable for the current user, but with CONFIGUREVIEW, still show the links, but say that no permission is allowed. This acts as a demonstration of features without allowing changes to be made.

ADMINACCCESS is a catch all access at the moment. As you add new accesses, make sure only that specific access is required to do the task - do not say ADMINACCESS or {new access}.

When adding a new access which is a subset of an existing one (effectively splitting the access), make sure existing roles with that access are also updated to include the new access. This makes upgrades backwards compatible.