Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

DPOD uses Role Based Access control Control to splice user access to the information available through the system.

User and Group Registries

DPOD supports two types of authentication user and authorization registries. group registries:

  • DPOD's internal database registry
  • Lightweight Directory Access Protocol (LDAP) user registry

An installation may choose to use either LDAP or DPOD's internal database registry or an LDAP user registry.

DPOD's Internal database registry

For ease of use, DPOD uses its internal database registry by default. Note however that it . Within this registry:

  • Users and security groups are defined via the Web Console.
  • Users may be members of several groups.

For more information, read the Users and Security Groups sections under Security Management.

Note

This registry should only be used for non-production environments or during an evaluation process of DPOD.

...

note

For production environments, it is highly recommended to use an LDAP user registry.

Users and Groups

Managing Users and Groups in DPOD's Default Database Registry

  • Users are managed under [Manage → System → Users].

  • Groups are managed under  [Manage → System → Groups].

Users may be members of several groups.
For more information, read the Users and Security Groups sections under Security Management

Managing users & groups in LDAP

LDAP's configuration procedure is described in Working With LDAP. Follow that procedure to enable LDAP registry as the users and groups registry of DPOD.

Note

When LDAP is enabled, users and groups are managed in LDAP registry only.

...

LDAP User Registry

DPOD may be configured to use an LDAP user registry. In that case:

  • Users and security groups are managed within the LDAP user registry.
  • DPOD performs LDAP queries to authenticate users and to assign them with security groups and 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 user registry is described in Configuring LDAP.

Security Roles

Security roles are used to provide a means for the administrator to filter the view users have of the system. Administrators can use the roles to filter out devices, domains, services, client IP addresses, 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 own built-in roles, which can not be added, deleted or altered.
  • Custom Roles - defined by the administrator. These roles 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 of DPOD's Web Console or REST API.

Each user must be assigned to at least one built-in role, or they will not be able to login to the console. It is up to the administrator to decide whether to assign a built-in role directly to the user, or use the group membership mechanism to provide built-in role(s).

The built-in roles are available for view-only under [Manage→ System Security → Roles] page (As described in Security Roles). Each

When using DPOD's internal database registry, users and security groups may be assigned with a built-in role can be linked to users or groupsfrom the Web Console. When using an LDAP user registry, built-in roles are assigned based on LDAP queries.

The table below lists the available built-in roles:

Role NameDescription
OpDashAdminRoleBuilt-in Administrator role. Provides full access.
OpDashPowerUserRoleBuilt-in Power User role. Allows access to Dashboards, Investigate, Explore, Reports execution
and viewing services configuration.
OpDashOperatorRoleBuilt-in role for controllers. Allows access to Dashboards, Investigate and Explore views.
OpDashInvestigatorRoleBuilt-in role for investigators. Allows access to some of the Dashboards and Investigate views.

Custom roles

Custom roles are optional, application-level , roles managed by the administrators. They can be used to limit access to certain data such as specific devices, domains, payload etc.

Each custom role is configured with several permission directives that dictate the allowed or denied access to devices, domains, services etc.

A user does not have to be assigned with custom roles. Users that are not assigned with any custom roles have access to all the data in the system, as limited by their built-in role to certain pages of the Web Console.

The custom roles are accessed and managed using the [Manage → System → Roles] page (As described in Security Roles). Each custom role can be linked to users and/or groupsor groups (defined in DPOD's internal database registry or in the LDAP user registry).

Effective Access Rights

A user may be assigned with several custom roles, directly or via groups. The effective access rights of a user is calculated according to the rules described below:

  • If the user has access to certain items (devices/domains/services/client IP addresses), 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 items, they are allowed to all other items 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 items, they will not be able to access them, even if they have access to the same items 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.