Managing the Privilege Structure

To add a new role:

Once you have added a role to the role subtree, you can copy it, move it, or rename it. To copy a role, click it, then select Copy Object from the context menu or menu bar. To move a role, click it, then select Move Object from the context menu or menu bar. To rename a role, click it, then select Rename from the context menu or menu bar.

Each role can be associated with one or more role parameters. Role parameters help to reduce the number of roles in a domain.

For example, suppose your organization manages a number of projects and wants to assign a project manager for each of them with project-specific access rights. Instead of defining a role (or permission) for each of the projects, you define one role, let’s say Projectleader, and associate a role parameter project with it. When a user is assigned to this role, a value for the project parameter must be provided. The privilege resolution process grants only those groups that are needed for managing this project.

Another alternative is to use permission match rules. Since permission match rules apply to user attributes, our scenario also needs in this case a special attribute such as projectleader. This solution tends to require a growing number of user attributes as the number of permission match rule scenarios increases.

Each role parameter requires a matching rule that acts as a filter for calculating user-group relationships during the privilege resolution process. When a user is assigned to such a role, for each role parameter at least one value must be provided. The subsequent privilege resolution process grants the user only those groups whose attributes match with the provided role parameter values. The matching is defined by the matching rule: it compares the role parameter values with the selected group attributes. Note that attributes to be used as group attributes must be defined as permissions parameters (see the Domain Configuration object).

Before you can associate a role with a role parameter, you must specify role parameter names - and optionally also the values - that are allowed for the domain. Navigate to the domain configuration folder and select the RoleParams sub-folder in Customer Extensions to add new role parameter definitions.

DirX Identity Provisioning applies the matching rule to all groups that this role grants, even those that are inherited by junior roles. Suppose a role Role1 has a junior role Junior1 with a permission PermissionForJunior1 and an attached group GroupJunior1. This group is only granted if its attributes comply with the role parameter values given for the Role1 assignment. If there are permission match rules defined for the permission PermissionForJunior1, they act as an additional filter; that is, they are "and-ed" with the matching rules of the role parameters. However, if the same group is granted by another role without any role parameters, it is granted independently of the Role1 matching rules.

If more than one role parameter has been defined for a role, groups are only granted if they comply with all match rules. If more than one value has been provided for one role parameter, a group is granted if it complies with at least one of the values.

A matching rule can have the following formats, where "UTRA" stands for "User-to-role assignment":

These operators are available: =, >, <, >=, <=.

Explicit String operators are: eq, gt, lt, ge, le.

Here are some examples:

Note that using the asterisk (*) as a wildcard in a group attribute used for a match rule always results in a match.

To assign or change a matching rule with DirX Identity Manager (Provisioning):

DirX Identity Provisioning supports the concept of junior roles and senior roles. Senior roles contain other roles, while junior roles are contained by other roles. For example, if role "R&D department manager" contains role "R&D software engineer", then "R&D department manager" is a senior role of "R&D software engineer", and "R&D software engineer" is a junior role of "R&D department manager". Thus, a role becomes a "senior" role when you assign another role to it, and a role becomes a junior role when you assign it to another role. That is, assigning "R&D software engineer" to "R&D department manager" makes "R&D department manager" a senior role and "R&D software engineer" a junior role.

The easiest way to create a role hierarchy is to build it from the bottom up: first, create an initial set of roles that have no junior roles assigned to them. Next, create another set of roles, and assign the first set you created as junior roles of the new set.

To assign a junior role to a role or delete a junior role assignment:

To manage role-to-permission assignment with DirX Identity Manager (Provisioning views group):

Now you can use the Manager’s permission assignment function to:

When you click Save or change to another tab, the DirX Identity Provisioning system validates the changes you make to the role, and returns the following information depending on the type of changes you make:

If you have clicked Save, Manager saves the changes in the Identity Store (Provisioning Configuration) (otherwise, it saves the changes in its internal cache until you click Save). In the event that it is unable to save the data because of network failure or an LDAP server error or timeout, Manager notifies you of the error.

To delete a role, click it, and then select Delete in the menu bar or context menu. DirX Identity Manager (Provisioning) checks that:

Manager then reports all senior roles that do not have an assigned permission or an assigned junior role, and/or all permissions that do not have a role assignment, and asks you to confirm the delete. At this point, you can:

Once you confirm the delete operation, the DirX Identity Provisioning system:

A role folder is a DirX Identity Provisioning object that the role administrator can use to organize the role subtree (the tree view of the defined roles that is displayed when "Roles" is selected in the Manager). Placing a role in a role folder does not affect the role’s place in the defined role hierarchy (the role’s junior and senior role assignments); the purpose of the role folder is to make it easy for the administrator to manage the viewable role subtree.

You can make the following changes to the hierarchical tree view of the DirX Identity Provisioning role structure:

To add a new folder, click the root role folder or one of the folders below it, and then select New → Folder from the context menu. Manager prompts you to enter the unique name for the folder.

To copy an existing folder, click it, then select Copy Object from the context menu or menu bar.

To move an existing folder, click it, then select Move Object from the context menu or menu bar.

To change an existing folder, click it, and then click Edit.

To delete an existing folder, click the folder, and then select Delete from the context menu or menu bar.The folder to be deleted must not contain any role objects.

To rename a role or a role folder, click it, then select Rename from the context menu or menu bar.

To add a new permission:

Manager returns an error if the name you supply for the permission is not unique.

Once you have added a permission to the privilege structure subtree, you can copy it, move it, or rename it. To copy a permission, click it, then select Copy Object from the context menu or menu bar. To move a permission, click it, then select Move Object from the context menu or menu bar. To rename a permission, click it, then select Rename from the context menu or menu bar.

Each permission can be assigned a matching rule that acts as a filter for calculating user-group relationships during the privilege resolution process. The matching rule operates as a comparison on user and group attributes that have been defined as permission parameters. The matching rule references these user and group attributes. Note that attributes that shall be used as group attributes must be defined as permissions parameters (see the Domain Configuration object).

When DirX Identity Provisioning is resolving user rights for a given user-role assignment that aggregates the permission or a direct user-permission assignment, it performs the matching rule on every group assigned to the permission and assigns to the user only those groups that match the rule. If there is no matching rule defined for a permission, the privilege resolution process takes all of the groups that are assigned to the permission and assigns them to the user who is assigned to the role.

A matching rule can have the following formats:

These operators are available: '=', '>', '<', '>=', '<='.

Here are some examples:

You can specify a list of matching rules and concatenate them with the AND logical operator or the OR logical operator. However, you cannot use the AND and OR logical operators in the same matching rule specification. For example, the following specification is allowed:

User.l = Group.l OR User.l startsWith "Mch" OR User.l isContained Group.l

While the following specification is not allowed:

User.l = Group.l AND User.l startsWith "Mch" OR User.l isContained Group.l

Note that using the asterisk (*) as a wildcard in a group attribute used for a match rule always results in a match.

To assign or change a matching rule with DirX Identity Manager (Provisioning):

To manage permission-to-group assignment with DirX Identity Manager (Provisioning):

Now you can use the Manager’s group assignment function to:

When you click Save or change to another tab, the DirX Identity Provisioning system validates the changes you make to the permission. Manager returns any errors or warnings that result from the resolution process (these messages are described in the topic "Saving Changes to a Role"). If you have clicked Save, DirX Identity Provisioning then stores in the Identity Store (Provisioning Configuration) the changes to the permission and also stores any changes to user-group relationships. If you have just changed tabs, DirX Identity Provisioning stores the changes in its internal cache.

To delete a permission, click it, and then select Delete in the menu bar or context menu. DirX Identity Manager (Provisioning) checks that:

Manager then requests that you confirm the delete, after which it:

Note that you can click Offline during Manager’s role resolution process to stop interactive privilege resolution and defer it for off-line execution. See the topic "Managing the privilege resolution Process" for further details.

You can use permission folders to organize the permission subtree (the tree view of the defined permissions that is displayed when the "Privileges" view is selected in the Manager). You can make the following changes to the hierarchical tree view of the permissions subtree:

To add a new folder, click the root permission folder or one of the folders below it, and then select New → Folder from the context menu. Manager prompts you to enter the unique name for the folder.

To copy an existing folder, click it, and then select Copy Object from the context menu or menu bar.

To move an existing folder, click it, and then select Move Object from the context menu or menu bar.

To change an existing folder, click it, and then click Edit.

To delete an existing folder, click the folder, and then select Delete from the context menu or menu bar.The folder to be deleted must not contain any permission objects.

To rename a permission folder, click it, and then select Rename from the context menu or menu bar.

To add a new group:

Manager returns an error if the name you supply for the group is not unique.

For hierarchical target systems you can structure your groups with containers:

You can use this feature, for example, to exclude a set of groups (virtual groups) from the target system synchronization or define several subtrees that are synchronized separately into special areas in your target system.

To assign permission parameters and their values to a group:

To view the permissions to which a group is assigned:

When you click Save or change to another tab, the DirX Identity Provisioning system validates the changes you make to the group. If you have clicked Save, DirX Identity Provisioning stores in the Provisioning Configuration the changes to the group and also stores:

If you have not clicked Save, but have only changed tabs, DirX Identity Provisioning stores the changes in its internal cache.

To delete a group, click it, and then select Delete from the menu bar or context menu. DirX Identity Manager (Provisioning) checks that you are authorized to delete the group, and then requests that you confirm the delete. The DirX Identity Provisioning system then validates that:

Manager then requests that you confirm the delete, after which it:

The target system integrator performs the actual deletion of the group in the target system when it synchronizes the information in the Identity Store (Provisioning Configuration) with the target system.At this time, the group in the Identity Store (Provisioning Configuration) is deleted.If the target system integrator is unable to delete the group in the target system, the group remains in the Identity Store (Provisioning Configuration) until its deletion timeout value is reached, at which point it is deleted from the Identity Store (Provisioning Configuration) regardless of whether or not it has been deleted from the target system.

Note that you can click Offline during Manager’s privilege resolution process to stop interactive privilege resolution and defer it for off-line execution.See the topic "Managing the Privilege Resolution Process" for further details.

Role parameters can be used to reduce the number of roles in the DirX Identity domain. The following figure illustrates this concept:

This figure shows two users U1 and U2 that use the same role R1 but with different parameters. Let’s assume that the parameter p stands for "Projectname". User U1 uses role R1 with parameter p set to P1 (project 1) and user U2 uses role R1 with parameter p set to P2 (project 2).

Role R1 uses one permission P1 that itself uses three groups, one for project 1 (P1), one for project 2 (P2) and one group for project 3 (P3).

The match rule of the role defines that the user gets a group assigned dependent on the project (p) attribute of the user-to-role assignment (A1 or A2). If the project attribute of the assignment matches the project (p) attribute of the group, the group is assigned to them.

In this case, the user U1 with p set to P1 gets the group G1 assigned. User U2 with p set to P2 gets the group G2 assigned.

You set up role parameters as separate objects in the Domain view beneath the Customer Extensions → Role Parameters folder. DirX Identity supports several types of role parameter value definition. See the topic "Setting up Role Parameters" in the chapter "Managing Domains" for more information.

You can also define hierarchical role parameters that are typically modeled as an object tree (for example, as a group tree in a target system). Access to these role parameters can be restricted, which results in a special type of delegation. See the section "Policies for Hierarchical Role Parameters" in the chapter "Managing Access Policies" for more information.

Permission parameters can be used to reduce the number of permissions in the DirX Identity domain. The following figure illustrates this concept:

The figure shows two users U1 and U2 that use the same permission P1. This permission uses three groups, one for German users (G1), one for French (G2) and one group for all users (G3).

The match rule of the permission defines that the user gets a group assigned depending on the locality (l) attribute. If the user’s locality attribute matches the locality attribute of the group, the group is assigned to him.

In this case, the user U1 with l set to DE gets the groups G1 and G3 assigned. User U2 with l set to GB gets only the group G3 assigned.