Defining roles
When you create users in IBM® Control Center, you give them credentials, or permissions, to access the system by using roles. You create roles and subordinate roles to give structure and hierarchy to permissions to meet the needs of your organization.
Roles are sets of permissions that specify the data users might see and the IBM Control Center actions users can perform and the servers and server groups they can perform these actions on. When roles are set up, data visibility groups can be used to segregate the data collected from servers or server groups that users can view. Data visibility groups facilitate the segmentation of data beyond server-level restrictions accomplished by assigning servers and server groups to roles.
IBM Control Center is distributed with two roles: superuser and user. By default, there are no data restrictions, and all IBM Control Center “manage” permissions are granted to the superuser role. This means that users assigned this role can view all data collected and that they can perform all IBM Control Center functions on all managed servers. The superuser can create additional user roles or modify existing ones to serve business requirements. When additional roles are based on the default superuser role, data restrictions might be added with data visibility groups and “manage” permissions changed as needed to limit the permissions granted to those roles.
By default, the user role has no data restrictions and “view only” permission for all IBM Control Center functions. The default user role cannot perform management functions such as adding servers or creating SLCs or rules. If additional roles are based on the user role, data restrictions might be added through data visibility groups. Permissions can be added to define those roles and expand the permissions granted those roles.
Some roles might require a mixture of permissions: they might need view-only permission for rules for a server or group of servers, but manage permissions for processes for those same servers. In other words, they cannot add or edit rules for those servers, but they can delete, resume, or suspend processes. This example illustrates why it is important to consider your business requirements and plan a role hierarchy based on those requirements. Your hierarchy might be based on geographic region, server type, service line, or business unit.
For example, the superuser role would typically be assigned to the person ultimately responsible for IBM Control Center. This superuser would have full permissions for setting up/configuring monitoring and full rights to all managed servers. There might be another administrator who is responsible for configuring Sterling Connect:Direct®. Therefore, a role can be defined that grants that user the permissions necessary to configure Sterling Connect:Direct servers from IBM Control Center. For security reasons, another administrator might be responsible for configuring Sterling Connect:Direct Secure Plus. Perhaps the business unit wants to do self-service monitoring. In this case, user roles can be defined that have view-only permissions for a restricted number of servers.
The following illustration shows a sample role hierarchy:
Subordinate roles cannot be given permissions higher than the permissions of a superior role. Also, subordinate roles can be given access only to the servers or server groups a superior role can access.
For example, an Eastern region administrator role has manage permissions on server groups A, B, and C. Any of its subordinate roles can manage or view only server groups A, B, and C (or a subset). Likewise, a Western region administrator role can have view permissions only for a server group. As a result, it cannot assign the manage permissions for that group to any subordinate roles.