Reports about application roles
One Identity Manager makes various reports available containing information about the selected base object and its relations to other One Identity Manager database objects. The following reports are available for application roles.
Table 18: Reports about application roles
|
Overview of all assignments |
This report identifies all departments, cost centers, locations, business roles or IT Shop structures in which employees from the selected application role are also members. For detailed information about analyzing role memberships, see the One Identity Manager Identity Management Base Module Administration Guide. |
|
Show historical memberships |
This report lists all members of the selected application role and the length of their membership. |
Granting One Identity Manager schema permissions through permissions groups
Permissions for accessing tables and columns of the One Identity Manager schema are themselves mapped in the schema through permissions groups. You can assign permissions groups to system users and to application roles.
Permissions groups are also used to control access to parts of the user interface, such as, menu items, forms, tasks, and program functions. When a user logs in to One Identity Manager tools, all available menus, forms, and methods are loaded depending on the system user's permissions groups, displaying a user interface customized for this system user. For more detailed information about editing the user interface, see the One Identity Manager Configuration Guide.
One Identity Manager provides permissions groups and system users with a predefined user interface and special permissions for One Identity Manager schema's tables and columns. These predefined configurations are maintained by the schema installation and cannot be edited apart from a few properties.
Detailed information about this topic
Related topics
Predefined permissions groups and system users
One Identity Manager provides permissions groups and system users with a predefined user interface and special permissions for One Identity Manager schema's tables and columns. These predefined configurations are maintained by the schema installation and cannot be edited apart from a few properties.
Table 19: Predefined permissions groups
|
Permissions group QBM_BaseRights |
The QBM_BaseRights permissions group defines the base rights that are required for a system user to log in to the One Identity Manager tools. This permissions group is always assigned implicitly. |
|
Permission group VID_Features |
The VID_Features permissions group covers all program functions required for starting the One Identity Manager tools. The permissions group covers additional program functions for running special functions in One Identity Manager. |
|
Permission group VID_View |
The VI_View permissions group has viewing permissions for all tables and columns that map application data.
NOTE: Assign viewing permissions of custom schema extensions to the permissions group. |
|
Permission group VID_Everyone |
The VI_Everyone permissions group is assigned to elements of the overview forms that use links to the corresponding menu items. These permissions groups also provide functions for Web Portal users.
NOTE: Assign the permissions group to your custom system users such that the overview form is fully displayed to the users. |
|
Permissions groups for One Identity Manager application data |
The permissions groups have permissions on the tables and the columns that map application data. These permissions groups are equipped with menu items, forms, tasks, and program functions which allows the application data to be edited with, for example, the Manager. |
|
Permissions groups for One Identity Manager system data |
The permissions groups have permissions on the tables and the columns that map the One Identity Manager's system data. These permissions groups are equipped with menu items, forms, tasks, and program functionality which allows the application data to be edited, for example, with Designer editors.
The vid permissions group has all edit permissions for the system configuration with the Designer. |
|
Role-based permissions group VI_4_ALLUSER |
The VI_4_ALLUSER permissions group provides the base permissions as well as menu items, forms, tasks, and program functions to enable the application data to be edited with the Manager and the Web Portal. This permissions group is always assigned implicitly. |
|
Role-based permissions group VI_4_ADMIN_LOOKUP |
The vi_4_ADMIN_LOOKUP permissions group has the viewing permissions for all tables and columns of the application data.
NOTE: Assign viewing permissions of custom schema extensions to the permissions group. |
|
Role-based permissions group QER_OperationsSupport |
The QER_OperationsSupport permissions group has special permissions for working with the Operations Support Web Portal. The permissions group is assigned to the OperationsSupportWebPortal application. The permissions of the permissions group apply only in the Operations Support Web Portal. |
|
Role-based permissions groups |
Role-based permissions groups have permissions on the tables and the columns that map application data. These permissions groups are equipped with menu items, forms, tasks, and program functionality which allow the application data to be edited with the Manager and the Web Portal. These permissions groups are linked to the One Identity Manager application roles and simplify administration of access permissions in the One Identity Manager role model. |
Table 20: Predefined system users
|
Dynamic system user |
Dynamic system users are used for logging into One Identity Manager tools with role-based authentication modules. First, the employee memberships in the One Identity Manager application roles are determined during login. Assignments of permissions groups to One Identity Manager application roles are used to determine which permissions groups apply to the employee. A dynamic system user is determined from these permissions groups that will be used for the employee’s login. |
|
System user sa |
The sa system user is used exclusively by the One Identity Manager Service. This system user is not assigned to a permissions group but has all the permissions, tasks, and program functionality. |
|
System user viadmin |
The viadmin system user is the default system user in One Identity Manager. This system user can be used to compile and initialize the One Identity Manager database and for the first user login to the administration tools.
IMPORTANT: Do not use the viadmin system user in a live environment. Create your own system user with the appropriate permissions.
The system user has all of the specified permissions and the complete user interface. The system user implicitly receives the authorizations and user interface parts of the custom permissions groups. The system user has the permission to set up an employee as a One Identity Manager administrator for the role-based login. The system user is not a member of the application role themselves. |
|
System user Synchronization |
The Synchronization system user has the necessary permissions to set up and run target system synchronizations using an application server. |
|
System user viHelpdesk |
The viHelpdesk system user has the necessary permissions and the user interface to use the Manager to access One Identity Manager helpdesk resources. |
Related topics
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.
|
Smith |
Lastname |
|
Bishop |
Lastname, Firstname, Entrydate |
|
Bennett |
Lastname, Firstname, Gender |
|
Dreyer |
Lastname |
