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
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 he cannot create their own dashboards, or restrict it so he 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 ‘blue print’ of what a User can and
cannot do or see within Opsview Monitor. (Note: a User can only belong to one Role
at any one time.)
Roles enable you to
control various facets of the User's experience within Opsview Monitor,
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 the Role. This means that if a new User called ‘sam’ is placed into a Role he will only be able to do and see whatever is configured within the Role. This
means if the ‘sam’s Role is configured in a way that he cannot configure or
view Business Service Monitoring, then when ‘sam’ logs in, he will not have any
concept of Business Service Monitoring within the Opsview Monitor software.
The general workflow
is to create the Role, i.e. define what can or cannot be done, and then create
the Users and assign them into that Role. Once everything is
configured, you simply need to modify the Role to change the access control for
every User within 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
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,