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.
## Overview of the Security Model
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.
### Overview
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. (**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, including what:
they can view
they can configure
actions they can take
sections of Opsview Monitor they can access
... and more.
Once a Role is configured, i.e. the blueprint is created, then Users can be assigned to the Role. This means that if a new User called 'John' is placed into a Role he will only be able to do and see whatever is configured within the Role. This means if the 'John's Role is configured in a way that he cannot configure or view Business Service Monitoring, then when 'John' 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 to 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 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.