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 One Identity Manager schema's system data are granted by the system, which are sufficient for logging a system user into the administration 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 the referenced table, the primary key column, and the columns that are necessary in 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: Grouping permissions 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: 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.
|
Name1 |
Lastname |
|
Name2 |
Lastname, Firstname, Entrydate |
|
Name3 |
Lastname, Firstname, Gender |
|
Name4 |
Lastname |
Editing permissions groups
One Identity Manager provides permissions groups with a predefined user interface and special permissions for 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 grouped 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 with the User & Permissions Group Editor. The 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:
-
Edit permissions group main data
-
Define new dependencies between permissions groups
-
Copy permissions groups
-
Create new permissions groups
Related topics
Dependencies between permissions groups
By structuring permissions groups hierarchically, permissions and user interface components can be passed down from one permissions group to another permissions group. 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 permission groups are defined with the following permissions and user interface components.
|
A |
Viewable |
Menu structures and forms |
|
B |
Editable |
Task definitions |
Permissions group B is assigned 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
Permissions group dependencies
You edit dependencies between permissions groups in the hierarchical view of the User & Permissions Group Editor. Permissions groups that are higher up in the hierarchy are displayed further to the right in the User & Permissions Group Editor‘s hierarchical. When a permissions group is selected in the hierarchical view, dependencies to other permissions groups are marked in color thus showing the direction of inheritance.
Figure 1: Visual of the permissions group hierarchy (inheritance from right to left)
Table 21: Meaning of colors in the hierarchical representation
|
Blue |
The selected permissions group. |
|
Purple |
This permissions group is a child of the selected permissions group and directly inherits from the selected permissions group. |
|
Light purple |
This permissions group inherits indirectly from the selected permissions group over the hierarchy. |
|
Red |
This permissions group is a child of the selected permissions group and directly inherits from the selected permissions group. |
|
Light red |
This permissions group passes inheritance indirectly to the selected permissions group over the hierarchy. |
|
Green |
This permissions group does not inherit or pass inheritance to the selected permissions group. |
To specify dependencies of a permissions group
-
In the Designer, select the Permissions > Permissions groups category.
-
Select the permissions group and start the User & Permissions Group Editor using the Edit permissions group task.
-
In the hierarchical view of the permissions groups, select the permissions group and run one of the following actions.
-
Select the Inherit permissions from context menu and select the permissions groups from which the selected permissions group is to inherit.
-
Select the Permissions inherited by context menu and select the permissions groups to be included in the selected permissions group. Child permissions groups inherit permissions from the selected permissions group.
-
Select the Database > Commit to database and click Save.
