IBM DataPower Operations Dashboard v1.0.21.x
Role Based Access Control
- Copy Page Tree
- Sara Weisz
Access, functionality and information in DPOD are subject to Role Based Access Control through the system.
Users and Security Groups Registries
DPOD supports two types of users and security groups registries:
- DPOD's internal database registry
- Lightweight Directory Access Protocol (LDAP) registry
DPOD's administrator may choose to use either DPOD's internal database registry or an LDAP registry.
DPOD's Internal Database Registry
For ease of use, DPOD uses its internal database registry by default. Within this registry:
- Users and security groups are defined by DPOD administrators via the Web Console.
- Users may be members of several security groups.
- For more information, read the Users and Security Groups sections under Security Management.
This registry should only be used for non-production environments or during an evaluation process of DPOD.
For production environments, the only supported registry is the LDAP registry.
LDAP Registry
DPOD may be configured to use an LDAP registry. In that case:
- Users and security groups are managed within the LDAP registry.
- DPOD performs LDAP queries to authenticate users and to assign them with security groups and security roles.
- Defining users and security groups is not available via the Web Console.
- The internal database registry is not in use.
Configuring DPOD to use LDAP registry is described in Configuring LDAP.
Security Roles
Security roles are used to provide a means for the administrator to limit the functionality and filter the view users have of the system. For example, administrators can use the roles to limit a user for view-only functionality, as well as filter out devices, domains, services, client IP addresses, APIs, payload and more from a user's view, thereby providing each user with insights to only the parts of the system they are allowed to access.
There are two types of security roles available with DPOD:
- Built-in Roles - DPOD's pre-defined roles, which can not be added, deleted or altered.
- Custom Roles - defined by the administrator, and may be added, deleted or altered by a DPOD administrator.
Built-in roles
Built-in roles are hard-coded, system-provisioned roles that limit access to certain pages and functionality of DPOD's Web Console or REST API:
- Each user must be assigned with at least one built-in role, or they will not be able to sign in to the web console or admin console.
- When using DPOD's internal database registry, users and security groups may be assigned with a built-in role from the Web Console. When using an LDAP registry, built-in roles are assigned based on LDAP queries.
- The built-in roles are available for view-only under [Manage→ Security → Roles] page (As described in Security Roles).
The table below lists the available built-in roles:
| Role Name | Description |
|---|---|
| OpDashAdminRole | Built-in Administrator role. Provides full access for the Web Console. |
| OpDashPowerUserRole | Built-in power user role. Allows access to Dashboards, Investigate, Explore, Reports/Alerts execution and viewing services configuration. |
| OpDashOperatorRole | Built-in role for controllers. Allows access to Dashboards, Investigate and Explore views. |
| OpDashInvestigatorRole | Built-in role for investigators. Allows access to some of the Dashboards and Investigate views. Investigators have no access to the following Dashboards and Investigate views: System Overview, System Health, Restarts, Resources Dashboards, Security Dashboards, Payload Capture, Service Configuration, Service Configuration Changes and Failed Objects. |
| OpDashAppAdminRole | Built-in role for DPOD installation administrators. This role is required for signing in to the Admin Console. |
Custom roles
Custom roles are optional, application-level roles managed by the administrators:
- Custom roles are used to limit the functionality or limit access to certain resources such as specific devices, domains, services, APIs, payload etc.
- Each custom role is configured with several permission directives that dictate allowed functionality as well as the allowed or denied resources for the users or security groups that are assigned with this custom role.
- A user does not have to be assigned with custom roles. Users that are not assigned with any custom role have access to all the data in the system, as limited by their built-in role.
- Each custom role should be linked to users or security groups.
- The custom roles are accessed and managed using the [Manage → Security → Roles] page (As described in Security Roles).
Effective Access Rights
A user may be assigned with several custom roles, directly or via security groups. The effective access rights of a user is calculated according to the rules described below:
- If the user has access to certain resources (devices/domains/services/client IP addresses/APIs), they are denied from all other items of the same type.
For example, if a user is allowed access to devices MyDevice1 and MyDevice2, they can only have access to these devices, and are denied from all other devices. - If the user is denied from certain resources, they are allowed to all other resources of the same type.
For example, if a user is denied from devices MyDevice1 and MyDevice2, they still have access to all other devices. - If the user is denied from certain resources, they will not be able to access them, even if they have access to the same resources in other custom roles they are assigned to.
For example, if a user is assigned with CustomRole1, which denies access to MyDevice1, and the same user is also assigned with CustomRole2, which provides access to MyDevice1, the user will not have access to MyDevice1. - If a user is assigned with several custom roles, field values are merged.
For example, if a user is assigned with CustomRole3, which provides access to MyDevice3, and the same user is also assigned with CustomRole4, which provides access to MyDevice4, the user will have access to both MyDevice3 and MyDevice4.
Copyright © 2015 MonTier Software (2015) Ltd.