E-mail
This page reviews using Role Restrictions in GroundWork Monitor.
About Role Restrictions
By default system roles do not have monitoring viewing restrictions. In other words, users can view all host groups and service groups for the entire infrastructure. Now in GroundWork Monitor you can control which host groups and service groups are visible to specific roles and their users. These role / user restrictions extend within the Status, Event Console, Dashboards (including My GroundWork), and the Advanced Reports applications. Additionally, administrators can now set restrictions for dashboard links to the Status application.
Outside of this document, see Administration How To's for how to reference on common Role Management tasks.
Listed below are some rules that an Administrator must be aware when creating a new system role:
- If a user is member of multiple roles unrestricted access takes precedence.
- If a user is member of multiple roles which is a mix of restricted (MSP view) and unrestricted access a user will inherit the unrestricted view (e.g. all host groups and service groups are visible to the user).
- If a user is a member of multiple roles, the user can see a union of the host groups and service groups defined for the roles.
- If a user is member of multiple roles that enable and disable links into the Status application, the user will have the links to the Status application enabled.
- In all cases unrestricted access takes precedent over restricted access.
- When creating a new system role, the administrator must check the Enable Actions Portlet box to allow a new custom role's members to utilize the Actions Portlet in the Status application.
Figure: Editing Role Restrictions
Dashboard Restrictions
Dashboards are the preferred way to show the current status of the system or sub systems for executives. In some cases it is desirable to disable the user's ability to drill-down from dashboard components, e.g. Event Console portlet, Service List portlet, and the Seurat view to the Status application. Selecting the box next to Disable links to Status viewer from all dashboards in the Edit Role page disables a roles associated users from being able to drill-down to status information from all dashboards.
 | The system Read only dashboard role, ro-dashboard, is included in a clean installation and does not have any default members assigned and there are no default restrictions for host group and service group visibility. This role's restrictions have be set to disable links to the Status application from all dashboards. See User Management . |
Figure: Dashboard Restrictions
Figure: Dashboard Restrictions (CA Role 1 associated user causer1 - disabled dashboard links)
Host Group and Service Group Restrictions
By default all roles and its associated users can view the entire infrastructure of available host groups and service groups. However, using role administration it is possible to restrict a role's visibility of host and service groups to show only a subset of a network's infrastructure. This means that only the selected host groups and service groups for a role will be visible within the Status, Event Console, Dashboards (including My GroundWork), and the Reports applications. Note that users associated with the GWAdmin role can see the entire infrastructure in all cases.
Within the selected host and service groups to be visible, a default host group and a default service group can be selected. These selections result in default page that is displayed in the Status and Dashboards applications versus the display of the Entire Network view.
|
|
MSP Use Case
The diagram below shows a Managed Service Provider (MSP) use case for defining Dashboards and Host and Service Group restrictions. The MSP Network is comprised of Company A and Company B in which associated roles and users have been defined. The GWAdmin role is used universally by the MSP. Under Restrictions, you can see the role restriction settings for our two example roles CA Role1 and CA Role2. The paragraphs below explain the use case in detail.
Figure: MSP Use Case for Role Restrictions
Scenario 1
- User login causer1 (Company A User 1) who is a member of role CA Role1
- Restrictions - Disable links to Status and show only host group CA HG1 and service group CA SG1
- This scenario is accented in green
In this first scenario we use the user causer1, a login for Company A and a member of the role: CA Role 1. Looking at the Restrictions area of the image you can see that the role CA Role 1 has been defined to disable links to the Status application from all dashboards, and that the visible host and service groups have been set to include CA HG1 and CA SG1.
The result then is shown in the MSP Network area of the diagram. Here you can see in green the MSP Network visibility; host group CA HG1 and service group CA SG1 with the rest of the network as non-accessible. Additionally, user causer1 does not have the permissions to view Status information through any dashboard links.
Scenario 2
- User login causer2 (Company A User 2) who is a member of role CA Role1 and CA Role2
- Restrictions - Show only host group CA HG1 and service group CA SG1, and host group CA HG2 and service group CA SG2
- This scenario is accented in green and blue
In this second scenario we use the user causer2, another user login for Company A and a member of the roles; CA Role 1. and CA Role2. This means user causer2 will have the permissions and restrictions defined for both of these roles since this user is a member of both.
Looking at the Restrictions area of the image you can see that in addition to role CA Role 1, CA Role 2 has been defined to enable links to the Status application from all dashboards (no check), and that the visible host and service groups have been set to include host groups and service groups from both the CA Role1 and CA Role2 roles.
The results again are displayed in the MSP Network area of the diagram. Here you can see in green and blue the MSP Network visibility; host groups CA HG1 and CA HG2, and both service groups CA SG1 and CA SG2, and the rest of the network as non-accessible.
Additionally, user causer2 now has the permission to view Status information through any dashboard links. In this scenario, a user is member of multiple roles that both enable and disable links into the Status application, so the user will have access to these links in the Status application because the links have been enabled.