Rules for determining the valid permissions for tables and columns
When a system user is used to log into the system, the permissions for the objects that are currently in effect, are determined on the basis of the permissions groups. The following rules are used to determine the resulting permissions:
- Permissions from hierarchical permissions groups are inherited from top to bottom. That means that a permissions group contains all the permissions belonging parent permissions groups.
- The number of objects is determined first for hierarchical permissions groups. Column permissions are decided afterward. In some cases, this results in more permissions than are defined on individual permissions groups.
- A system user receives a permission when are least one of its permissions groups has the permission (directly or inherited).
- The limiting permissions conditions for all the system user’s permissions groups are grouped together and used to determine a valid condition for each permission for viewing, editing, inserting, and deleting an object.
- Fixed viewing permissions for the database system files are granted by the system, which are sufficient for logging a system user into One Identity Manager tools.
- A system user with read-only permissions only obtains viewing permissions to objects irrespective of any other permissions.
- If permissions are granted on a table for inserting, editing, or deleting, viewing permissions are implicit.
- If permissions are granted on a column for inserting, editing, or deleting, viewing permissions are implicit.
- If permissions are granted for a table, then viewing permissions are implicitly granted on the primary key column of the table.
- If viewing permissions are granted on a primary key column as a minimum, then viewing permissions are implicitly granted for references table, the primary key column and the columns that are necessary on the referenced table for viewing according to the defined display pattern.
- Columns that need to be in a defined display pattern in the table are given implicit viewing permissions.
- Permissions for database views of the Proxy type also apply to the underlying tables.
- For database views of the ReadOnly type, only the viewing permissions apply irrespective of other permissions.
- If a table or column is disabled due to preprocessor conditions, permissions are not determined for those tables and columns. The table or column is considered not to exist.
- If a permissions group is disabled due to preprocessor conditions, permissions are not taken into account for this permissions group. The permissions group is considered not to exist.
Example of permissions grouping using permissions groups
The following example shows how to group permissions if the user is directly assigned in permissions groups and the permissions groups are not connected hierarchically.
A system user obtains permissions to the ADSAccount table through different permissions groups.
In addition, it is granted permissions to the LDAPAccount table through these permissions groups.
Therefore, the system user has effectively the following permissions:
| ADSAccount |
1 |
1 |
1 |
1 |
| LDAPAccount |
1 |
1 |
1 |
0 |
Example of limiting conditions
A system user obtains viewing permissions to the Person table through different permissions groups:
| A |
| Lastname |
| B |
Lastname like 'B%' |
Lastname, Firstname, Entrydate |
| C |
Lastname like 'Be%' |
Lastname, Firstname, Gender |
| D |
Lastname like 'D%' |
Lastname |
This results in the following permissions for the individual employee objects.
| Smith |
Lastname |
| Bishop |
Lastname, Firstname, Entrydate |
| Bennett |
Lastname, Firstname, Gender |
| Dummy |
Lastname |
Processing permissions groups
One Identity Manager provides permissions groups with a predefined user interface and special edit permissions for the One Identity Manager schema's tables and columns. In certain isolated cases, it may be necessary to define custom permissions groups. You need custom permissions groups, for example, if:
- The default permissions groups grant too many permissions,
- Selected default permissions groups are to be summarized to form a new permissions group,
- Additional role-based permissions groups are required for the custom application roles,
- Permissions for custom adjustments such as schema extensions, forms, or menu structures.
When the One Identity Manager database is installed using the , custom permissions groups that you can use are already created.
- For non role-based login, the CCCViewPermissions and CCCEditPermissions permission groups are created. Administrative system users are automatically added to these permissions groups.
- For role-based login, the CCCViewRole and CCCEditRole permission groups are created.
In the Designer, permissions groups are managed in the Permissions | Permissions groups category. Here you will find an overview of edit permissions and user interface components that are assigned to individual permissions groups. In addition, the system users are displayed, to which the permissions groups are assigned.
Use the Designer to create and edit permissions groups in User & Permissions Group Editor. User & Permissions Group Editor displays the permissions groups in their hierarchy. Each permissions group is represented by a permissions group element. Each permissions group element has a tooltip. The contents of the tooltip is made up of the name and description of the permissions group.
You can run the following tasks:
- Editing the master data of a permissions group
- Defining new permissions group dependencies
- Copying Permissions Groups
- Creating a new permissions group
Related topics
Permissions groups properties
Table 17: Permissions group properties
| Permissions group |
Name of the permissions group. Label custom permission groups with the CCC prefix. |
| Description |
Detailed description of the permissions group’s purpose. |
| Remarks |
Text field for additional explanation. |
| Preprocessor condition |
You can add a preprocessor condition to permissions groups. This means that the permissions group is only effective when the condition is met. |
| Permissions group binary pattern |
The permissions group binary pattern is used to calculate effective system user permissions. It is provided by the DBQueue Processor. |
| Only use for role-based authentication |
This group includes permissions, form assignments, menu items and program functions for role-based authentication. The permissions group can be assigned to One Identity Manager application roles and is assigned to dynamically determined system users. A direct assignment to non-dynamic system user is not permitted.
NOTE: This function is available if the Identity Management Base Module is installed. |
Related topics
Permissions group dependencies
You can enable permissions and user interface components to be passed on from one permissions group to other permissions groups by structuring permissions groups hierarchically. This means that inheritance is top down within the hierarchy.
The following applies to permissions group dependencies:
- A role-based permissions group can inherit from role-based permissions groups and non role-based permissions groups.
- A non role-based permissions group can inherit from non role-based permissions groups. A non role-based permissions group must not inherit from role-based permissions groups.
Example
Two permissions groups are defined with the following permissions and user interface components.
| A |
Viewing permissions |
Menu structures and forms |
| B |
Edit permissions |
Task definitions |
Permissions group B is arranged below permissions group A in the hierarchy and inherits from permissions group A. Consequently, a user of permissions group B has access to the viewing permissions and editing permissions as well as the menu structure, forms, and task definitions.
Related topics
