Users and Roles

Overview of the security model Copied

This section provides an overview of the Users and Roles model within Opsview Monitor, how to add new Users, configure Roles to limit access for certain Users and more.

This document explains the concept of Users, Roles, and Tenancies within Opsview Monitor, explain how to configure and add new Users, secure their access via Roles and create Tenancies for extra security and configuration options.

After reading the User Guide, Users should be able to create their own Users, Roles, and Tenancies and fine-tune the access control of Opsview Monitor for a range of different scenarios and requirements.

User and Roles Copied

Opsview Monitor provides a security model that allows you to easily restrict Users and what they can access. This means that if you want to restrict a User so that they cannot create their own dashboards, or restrict it so they can only see Hosts tagged with a certain Hashtag, then you can.

The access control within Opsview Monitor is all controlled via Roles. A Role is essentially a ‘blueprint’ of what a User can and cannot do or see within Opsview Monitor.

Roles enable you to control various facets of the User’s experience within Opsview Monitor, including what:

• they can view
• they can configure
• actions they can take
• sections of Opsview Monitor they can access

Once a Role is configured, i.e. the blueprint is created, then Users can be assigned to one or more Roles. A user gains the combined permissions from all assigned roles — see Combining multiple roles below. For example, if a user called ‘John’ is assigned only a Role that does not include Business Service Monitoring, he will not have any concept of Business Service Monitoring when he logs in.

The general workflow is to create Roles, i.e. define what can or cannot be done, and then create Users and assign them to those Roles. Modifying a Role changes the access control for every User assigned that Role.

In additional to Roles and Users, there is a concept of Tenancies. Tenancies are a grouping of Roles and Users together, so end-users can make changes to Roles and Users without knowing any information about other tenants.

Essentially, a Tenancy is a single Primary Role, which defines what objects (Hosts, etc.) the Tenancy can modify and see. This Primary Role becomes the basis for access control within the Tenancy. Unlike Roles, where it is a simply ‘One Role can ‘contain’ many Users’, a Primary Role (and thus a ‘Tenancy’) can be created to contain further sub Roles, as shown in the graphic below:

In the example above, there are two standard Roles; Customer A and Customer B. When a User is a member of the ‘Customer A’ Role, he can view all objects specified within the Role.

With ‘Customer C’ we have created a primary Role for the purpose of Multi-Tenancy. At this level, we have determined that all objects relating to ‘Customer C’ are available for Sysadmins to add to ‘sub Roles’. There are then two Roles created by the Tenancy Sysadmin; ‘Network team’ and ‘Apps Team’. These ‘sub Roles’ can take what is defined with the ‘Customer C’ primary Role and further limit it. For example, if Customer C can view 10 hosts, while ‘Network team’ Users can only view four of them.

Tenancies are a great way to give a control of Opsview Monitor to your users by allowing them to create new Hosts and further Roles and Users ’ all within their own secure, private environment.

Combining multiple roles Copied

When a user has multiple roles, permissions from all assigned roles are combined. How this works depends on which part of the role defines the permission.

Status access Copied

Permissions for status access are combined as follows:

• Viewing (VIEWSOME): the user can see status for objects selected on any assigned role’s Status Objects tab — see Selection of objects in Roles.
• Other object-level permissions (DOWNTIMESOME, ACTIONSOME, and similar *SOME access levels): each permission applies only to the objects on the Status Objects tab of the role that grants it. It does not extend to objects selected by another role.
• VIEWALL, ACTIONALL, and similar *ALL access levels: if any assigned role includes the permission, it applies to all objects — see Current role definitions.
• All other status access levels (for example DASHBOARD, NAVOPTIONS, VIEWPORTACCESS, NETFLOW, or TESTCHANGE): if any assigned role includes the permission, the user has it for their whole account. These are not limited by the Status Objects tab.

For example, suppose Role A grants VIEWSOME and DOWNTIMESOME for Host Group A, and Role B grants VIEWSOME and ACTIONSOME for Host Group B. A user assigned both roles can view hosts in Host Group A and Host Group B, but can only schedule downtime on Host Group A and can only take actions (such as acknowledgments or rechecks) on Host Group B.

Configuration and administration Copied

For permissions on the Configuration and Administration tabs:

• If any assigned role includes an access level (for example CONFIGUREVIEW, CONFIGURESAVE, or ADMINACCESS), the user has that capability for their whole account.
• Permissions that are limited to selections on the Configuration tab (for example which host groups can be edited with CONFIGUREHOSTS, or which monitoring clusters are visible) combine across roles. The user can access host groups and monitoring clusters selected on any assigned role.

BSM Copied

For permissions on the BSM tab:

• If any assigned role includes BSM access (for example BSM, CONFIGUREBSM, or CONFIGUREBSMCOMPONENT), the user has access to those Business Service Monitoring features.
• Business services and components configured on a role’s BSM tab are combined across all assigned roles.