サポートと今すぐチャット
サポートとのチャット

Identity Manager 9.2.1 - Business Roles Administration Guide

Managing business roles
One Identity Manager users for business roles Hierarchical role structure basic principles Basic principles for assigning company resources Basics of calculating inheritance Preparing business roles for company resource assignments Base data for business roles Creating and editing business roles Assigning identities, devices, and workdesks to business roles Assigning business roles to company resources Analyzing role memberships and identity assignments Setting up IT operational data for business roles Creating dynamic roles for business roles Assigning departments, cost centers, and locations to business roles Defining inheritance exclusion for business roles Assigning extended properties to business roles Creating assignment resources for application roles Dynamic roles for business roles with incorrectly excluded identities Certification of business roles Reports about business roles
Role mining in One Identity Manager

Basics of calculating inheritance

Objects assigned through inheritance are calculated by the DBQueue Processor. Tasks are added to the DBQueue when assignments relevant to inheritance are made. These tasks are processed by the DBQueue Processor and result in follow-on tasks for the DBQueue or in processes for process component HandleObjectComponent in the Job queue. Resulting assignments of permissions to user accounts in the target system are inserted, modified, or deleted during process handling.

Figure 10: Overview of inheritance calculation

Calculating inheritance by hierarchical roles

Identities, devices, and workdesks can only be members in roles that are extensions of the BaseTree table. These role are display in views, each of which represents a certain of the BaseTree table.

Table 3: BaseTree table views
View Meaning

ORG

Graphical representation of business roles

NOTE: Because the views are subsets of the BaseTree table, all the inheritance mechanisms described below also apply to the views.

Inheritance comes from the BaseTree table. The BaseTree table can map any number of hierarchical role structures using the UID_Org - UID_ParentOrg relationship. These are stored in the BaseTreeCollection table. All the roles inherited from the given role are listed and, depending on their subset of the table BaseTree there is a corresponding, so-called *Collection table containing a subset of the role hierarchy.

The following relations apply in the BaseTreeCollection table:

  • UID_Org is the role that inherits.

  • UID_ParentOrg is the role that passes down inheritance.

This principle also applies to bottom-up trees that pass inheritance from bottom to top, even if the parent relationship from the BaseTree table appears to be reversed.

Each role inherits from itself.

Each role in a role hierarchy must be related to the OrgRoot table (Role classes). OrgRoot is the anchor for role hierarchies. A role hierarchy is always mapped for one role class only. Roles from different role classes may not be in one and the same role hierarchical or point to each other through a parent-child relationship.

Figure 11: Hierarchical role structure based on an OrgCollection

A role inherits everything that is assigned to its parents in the role hierarchy including those it assigned to itself. If the number of roles from which the role has inherited something changes, the assigned objects are recalculated for all members of this role. If the number of assigned objects of one class changes, the objects assigned in this class are recalculated for all members of the role. If a software application is assigned to a parent role, the members of the BaseTreeHasApp table are recalculated.

The members of a role inherit all their assignments through primary and secondary role structures in accordance with the BaseTree table and also previous structures in accordance with the BaseTreeCollection table .

Calculation of assignments

When inheritance is calculated, an entry is made for each assignment in the corresponding assignment table. Each table, in which assignments are mapped, has an XOrigin column. The origin of an assignment is stored in this column as a bit field. Each time an entry is made in the assignment table, the bit position is changed according to the assignment type. Each assignment type changes only its allocated bit position.

That means:

  • Bit 0: direct assignment.

  • Bit 1: indirect assignment but not through a dynamic role.

  • Bit 2: assignment through a dynamic role.

  • Bit 3: assignment through an assignment request.

  • Bit 4: module specific bit. For more information, see the administration guide of the module in which the bit is used.

Table 4: Possible values for column XOrigin

Bit 3

Bit 2

Bit 1

Bit 0

Value in XOrigin

Meaning

0

0

0

1

1

Only directly assigned.

0

0

1

0

2

Only indirectly assigned.

0

0

1

1

3

Directly and indirectly assigned.

0

1

0

0

4

Assigned through dynamic roles.

0

1

0

1

5

Assigned directly and through dynamic roles.

0

1

1

0

6

Assigned indirectly and through dynamic roles.

0

1

1

1

7

Assigned directly, indirectly, and through dynamic roles.

1

0

0

0

8

Assignment request.

1

0

0

1

9

Assigned by assignment request and directly.

1

0

1

0

10

Assigned by assignment request and indirectly.

1

0

1

1

11

Assigned by assignment request, directly, and indirectly.

1

1

0

0

12

Assigned by assignment request and through dynamic roles.

1

1

0

1

13

Assigned by assignment request, directly, and through dynamic roles.

1

1

1

0

14

Assigned by assignment request, indirectly, and through dynamic roles.

1

1

1

1

15

Assignment request, direct, indirect, and through dynamic roles.

Special features of inheriting assignments though a role hierarchy

NOTE: If an assignment is inherited through a role hierarchy, bit 1 is set on the inherited assignment. Inherited assignments are consequently, always assigned indirectly even if they were originally created directly though dynamic role or an assignment request.

Example:

An Active Directory group assignment was requested for the "Sales" business role. The "Sales EMEA" child business role inherits this assignment. In the OrgHasADSGroup table, XOrigin is set as follows:

  • Business role "Sales": XOrigin='8' (assignment resource)
  • Business role "Sales EMEA": XOrigin='2' (indirect assignment)
Effectiveness of assignments

The XIsInEffect column shows whether an assignment is in effect. For example, if an identity is deactivated, marked for deletion, or classified as a security risk, inheritance of company resources can be prohibited for this identity. The assignment of company resources is maintained but the assignment has no effect.

DBQueue Processor monitors changes to the XOrigin column. The XIsInEffect column is recalculated when changes are made to the value in XOrigin.

Preparing business roles for company resource assignments

You should check the following settings and make adjustments as required:

  • Specify whether identities, devices, and workdesks and company resources may be assigned to roles.

  • Define the direction of inheritance with the hierarchy.

  • Limit inheritance for specific roles if necessary.

    You can specify whether inheritance of company resources can be limited for single identities, devices, or workdesks.

  • If required, define roles that are mutually exclusive.

    By specifying conflicting roles, you can prevent identities, devices, or workdesks being added to roles which contain mutually excluding company resources.

Detailed information about this topic
関連ドキュメント

The document was helpful.

評価を選択

I easily found the information I needed.

評価を選択