To create a business role, you must define a membership policy and an authorization policy for the business role based on your business needs. OpenText Identity Governance allows you to create business roles using role mining, or by creating the role manually.
OpenText Identity Governance can use advanced analytics to mine business data and to identify role candidates. Business role mining is the process of discovering and analyzing business data to group multiple users and access rights under one business role candidate. OpenText Identity Governance allows you to use one of three role mining methods to create business roles.
To create a business role using role mining:
Log in to OpenText Identity Governance as a Customer, Global, or Business Roles Administrator.
Select Policy > Business Roles.
Click the Mining tab.
Select a role mining approach (See Table 16-1 to determine which role mining approach to use).
Click Generate New Suggestions.
NOTE:If you already generated new suggestions, you can click Load Previous Suggestions, click Load for the mining suggestion you want to use to load potential role candidates, then skip to Step 9. Only saved suggestions still within the specified retention interval appear as Previous Suggestions.
WARNING:You might not see recommendations if the Generate New Suggestions > Minimum potential members value is set too high, or if the role mining settings in Configuration > Analytics and Role Mining Settings do not meet the required conditions. For more information, see Configuring Analytics and Role Mining Settings.
Provide the requested role mining options relevant to the business role you want to create.
HINT:To differentiate among mining suggestions you generate, provide a description that lists the attributes you want to use for role mining, or that specifies the purpose for the role.
Click Start.
Click Load next to the mining suggestion you want to use to load potential role candidates.
Select one or more potential candidates.
IMPORTANT:If you selected visual role mining, you must select one or more criteria from the visual representation before you can select potential candidates.
NOTE:You can click Change Authorizations to modify the authorizations used to create the mining suggestions. Changing the authorizations can modify the values for Users, Permissions, Roles, and Applications.
Click Actions > Find Matching Roles to determine if the specified potential candidates match members or authorizations of existing roles.
(Optional) Exclude potential candidates identified in the previous step that would create a duplicated role.
NOTE:If you choose to create a business role candidate with members and authorizations that match those in existing roles, you can analyze the candidate to calculate the match percentage. For more information, see Section 16.5, Analyzing Business Roles.
Click Actions > Create Candidates.
Select Create separate candidates for each criteria or Create a single business role candidate. If you select the latter, specify a name for the business role.
(Optional) Select Create associated technical roles for common permissions to generate the technical roles with users who have the same permissions.
(Optional) Select Group permissions added to technical roles by application to create application-specific technical roles.
(Optional) Select Create business role hierarchy, then select the attributes by which to group values for each available level, to create role hierarchy when mining business roles.
NOTE:The number of available levels is one less than the number of attributes you selected in Role Mining Options. For example, if you selected three attributes, you would be able to group the roles for up to two levels.
On the Roles tab, select one or more newly generated inactive roles.
NOTE:OpenText Identity Governance creates role candidates in a pending state, and administrators must promote them before anyone can either approve the role candidates or publish them as a role. Click the role candidate to ensure that the membership criteria and authorizations are as you want them to be before publishing. You can edit the role candidate to estimate impact, analyze SoD violations, and make changes such as make the business role requestable or assign a risk value.
(Optional) If your environment has advanced authorization policy capability, select Actions > Set Authorization Role.
Select Actions > Promote.
Select the new role, then select Actions > Publish.
After you create the business role and assigned owners and administrators, the business role is ready for approval, depending on your approval policy. The approval policy allows you to have people review the business role and approve or request changes to the business role. For more information, see Section 16.3, Adding a Business Role Approval Policy.
To detect users that meet the business role criteria in reviews or in the catalog, you must publish the business role. For more information, see Section 16.4, Publishing or Deactivating Business Roles.
To create a business role manually, you must define a membership policy and an authorization policy for the business role based on your business needs.
To define a business role manually:
Log in to OpenText Identity Governance as a Customer, Global, or Business Roles Administrator.
Select Policy > Business Roles.
Click the Roles tab, then click the plus sign (+).
Specify the following information to create the business role:
Name of the business role
Business role description
Grace period
NOTE:A grace period specifies the number of days that you want OpenText Identity Governance to consider the user as a member of the role when it detects that the member no longer meets the membership policy requirements.
Risk level
Potential SoD approval
NOTE:OpenText Identity Governance disables potential SoD approval by default, you can enable it for specific business roles or set it globally. For specific business roles, OpenText Identity Governance checks for potential SoD violations that require approval on auto-grants arising from those business roles. If you select the global setting, OpenText Identity Governance will check for violations on requests from those business roles where Potential Sod Approval is not enabled or disabled. However, you can override the global configuration by explicitly setting this option to enabled for each business role. To enable the global setting, select Use Global for the option Potential SoD Approval or configure potential SoD violations by accessing the Auto Requests tab.
Select the Membership tab, if not already selected, and provide information for one or membership configuration items. For detailed information see Section 16.2.3, Configuring Business Role Membership.
Select the Authorizations tab, then provide configuration information for one of more of the authorization configuration items.
NOTE:Applications must have an account collector to allow you to specify automatic grant or revoke.
For detailed information about authorizing permissions, technical roles, and applications, see Section 16.2.4, Adding Authorizations to a Business Role.
Select the Owners and Administration tab to assign ownership for the following:
Role owner
Role manager
Fulfiller
Categories
Approval Policy
NOTE:If you do not make selections on this tab, OpenText Identity Governance makes default assignments for the owner and fulfiller and assigns a default approval policy to the business role.
(Optional) On the Membership tab, click View Membership to view the list of business role members.
NOTE:During migration or upgrades, you must always run publication to refresh the list of business role members. For more information about publishing data sources, see Section 9.0, Publishing the Collected Data.
Under What-if Scenarios, click:
Estimate Publish Impact to estimate changes that would occur if the role were published, such as the users who would be added to or deleted from the business role, the resource authorizations that would be added or deleted, and the change requests that would be made.
Estimate Deactivate Impact to estimate changes that would occur if the business role is deactivated or deleted, such as the resource authorizations that would be deleted, and the change requests that would be made.
Analyze SoD Violations to analyze the SoD violations that would occur if users held the permissions and technical roles authorized by this business role.
(Conditional) Resolve SoD violations or edit the business role definition to resolve any issues. For more information about SoD violations, see Approving or Resolving an SoD Violation.
(Optional) Enable users to request business role membership through the Access Request interface.
HINT:After specifying a business role as requestable, make sure to publish the business role before assigning it to a Access Request policy. Unpublished business roles will not be available for request.
Click Save to save your modifications to the business role.
NOTE:When editing an existing business role, the Owners and Administration tab has a separate Save button, which allows you to change these items independent of other items that refer to the business role.
Select the saved role, then select Actions > Publish.
(Optional) If your environment has advanced authorization policy capability, select Actions > Set Authorization Role.
A membership policy determines which users are members of a business role. The membership policy can include membership expressions, membership policy from other business roles, user or group inclusion lists, and user or group exclusion lists. Regardless of how users become members of a role, they are authorized to have the resources specified in the business role for as long as they are members of the business role.
NOTE:Business role authorization of a resource (permission, technical role, or application) for a user is independent of assigning the resource to the user. For example, the business role might authorize a user to have a permission, but OpenText Identity Governance might not have assigned the permission. Similarly, OpenText Identity Governance might have assigned a permission, but the business role might not authorize the permission.
Optionally, specify business roles whose membership criteria, users, and groups you want to include in the new business role. When combining the included roles, OpenText Identity Governance includes only membership of published roles and eliminates duplicates. For example, you can include BR1 and BR2 in the membership of BR3. Then, role BR3 becomes the union of BR1 and BR2 along with any membership criteria specified for BR3.
NOTE:Excluded members of the including role takes precedence over the inclusion of included business role members. For example, when BR3 includes BR1, and BR1 has a member User A, and BR3 excludes User A then OpenText Identity Governance also excludes the user.
Also, note that OpenText Identity Governance does not allow circular inclusions. For example, you:
Cannot include BR1 in BR1 (self inclusion)
Cannot include BR2 in BR1 then include BR1 in BR2
Cannot include BR2 in BR1 and BR3 in BR2 and then include BR1 in BR3
Membership expressions are criteria that specify a set of users that are considered members of the business role. OpenText Identity Governance converts your specified criteria to create SQL SELECT statements to find the users that match the criteria. When you use the role mining feature, OpenText Identity Governance provides recommendations for role candidates based on your data and auto-generates the membership expressions when you create a role candidate. To optimize specific SELECT statements, follow query optimization principles such as creating indexes for attributes you are going to query. To optimize specific SELECT statements that might not be performing as expected, contact your database administrator. To set effective dates for authorizations, click the calendar icon at the top of the Membership Expression menu section.
HINT:When adding date attributes such as start date to membership expression, you can specify a date using the calendar date picker or use the date formula. For example, if you want to automatically make new employees a member of a business role two days before their start date, use the date formula.
Optionally, define specific users and groups that you want to include in the business role that might not match any membership expression. You can also specify users and groups to exclude from the business role who would otherwise match membership expressions. For example, you can have a membership expression that matches all managers in engineering, but you do not want John Smith or managers in the CTO group even if they match that criteria. You can also define a time period for when these inclusions or exclusions are valid.
NOTE:Excluding a user or group takes precedence over including them. For example, suppose you include the Sales group and exclude the Contractors group. Then, OpenText Identity Governance would exclude a user who belongs to both of those groups because exclusion takes precedence over inclusion.
You can click View Membership to view the list of business role members.
NOTE:During migration or upgrades, you must always run publication to refresh the list of business role members. For more information about publishing data sources, see Section 9.0, Publishing the Collected Data.
A business role authorization policy defines the permissions, technical roles, and applications authorized by the business role. Users are not automatically assigned the permissions of a business role, nor are business role permissions removed if users no longer meet the criteria for a business role. The business role authorization policy defines only whether the user is authorized the access but does not assign the resource.
A business role can authorize technical roles, so the business role authorizes all business role users and groups for all of the permissions included in each technical role. For more information, see Section 15.0, Creating and Managing Technical Roles.
You add an authorization policy to the business role on the Authorizations tab when you create or edit the business role.
There are many different components to an authorization policy. The following information explains the different components.
OpenText Identity Governance might preauthorize permissions when you mine for roles or you might need to define them. Select permissions from the entire catalog or from a list of permissions held by the business role members. Specify whether the permission is mandatory or optional. Specify whether OpenText Identity Governance should automatically grant or revoke permissions. If needed, select the calendar control to set an authorization period for when OpenText Identity Governance authorizes these permissions for users in the business role. The authorization policy can authorize a user in the business role for all of the permissions included in the authorization policy.
OpenText Identity Governance might preauthorize technical roles when you mine for roles or you might need to define them. The technical role acts as a grouping for the permissions. If all of the appropriate permissions are included in a technical role, you can add the technical role instead of the individual permissions. If needed, select technical roles from the entire catalog or from a list of technical roles held by the business role members. Determine whether the technical role is mandatory or optional. Specify whether OpenText Identity Governance should automatically grant or revoke the technical role authorization. If needed, select the calendar control to set an authorization period for when the permissions in the technical role are valid for the business role. The authorization policy can authorize a user in the business role for technical roles included in the authorization policy.
NOTE:If you select Auto-grant or Auto-revoke on a technical role, the selected option applies only to the permissions explicitly specified in the technical role. It does not apply to any of the permissions that those permissions might contain.
OpenText Identity Governance might preauthorize applications when you mine for roles or you might need to define them. If needed, define which applications the members of the business role are authorized to hold. This means OpenText Identity Governance can create accounts for the members of the business role in the listed applications. Select applications from the entire catalog or from a list of applications held by the business role members. Specify whether OpenText Identity Governance should or should not automatically grant or revoke the application authorization. If needed, select the calendar control to set an authorization period for when the members of the business role have access to the application. The authorization policy can authorize a user in the business role to have accounts in the applications included in the authorization policy.
NOTE:Applications must have an account collector to allow you to specify automatic grant or revoke.
When an authorization policy specifies Mandatory on a permission, technical role, or application, it means that a user is expected to have it if the user is a member of the business role. However, there is no enforcement of having the mandatory item. Optional means the authorization policy allows a user to have a resource, but the authorization policy does not require it.
You can select whether to automatically grant or revoke each permission, technical role, and application. Applications must have an account collector to allow you to specify automatic grant or revoke. When the authorization policy applies the auto-grant or the auto-revoke policies in the business roles, OpenText Identity Governance might issue grant requests if the user does not have a resource, and revoke requests if the user has a resource. Under certain conditions, OpenText Identity Governance might issue grant requests even if a user has a resource, and revoke requests even if a user does not have a resource.
For more information, see Section 16.8, Automated Access Provisioning and Deprovisioning.
The authorization policy can authorize a user in the business role for a set period of time defined in the authorization policy. Typically, you might need to set the authorization period only during transitions like mergers or changes related to compliance. Avoid setting an authorization period for business roles to change a specific role authorization, as you handle it more efficiently using periodic business role membership reviews.