In review definition and approval policy, administrators can select coverage maps to specify:
Reviewers of a User Access or Account Review definition
Approvers for requested access in the Request application
Coverage maps are CSV files with header and criteria cells. You can use these files to map review or request items to respective reviewers or approvers by specifying:
An entity type or attribute based on the item under review.
Different entity and attribute criteria in a single column
Secondary or related entity or attribute of related entity referenced via entity-entity relationships
It is important to have an understanding of Identity Governance supported coverage map types, keywords, syntax, and enitity-entity relationships in order to create and load coverage maps.
To create a coverage map, create a CSV file with header and criteria cells. For greater flexibility use only keywords.
Identity Governance supports the following coverage map type attributes and keywords:
Type |
Description |
Keywords |
---|---|---|
REVIEW |
Maps for user access and account review based reviews |
|
REQUEST |
Maps for request based approver determination |
|
Header and Criteria Cells Syntax
For |
Syntax |
---|---|
USER or GROUP based reviewer header cell |
<Reviewer.user|Reviewer.group>[.related user or group attribute key] |
Review item header cell |
<Approver.user|Approver.group>[.related user or group attribute key] |
USER or GROUP based approver header cell |
<Application|Permission|User]>[.entity-attribute-key] |
Request item header cell |
[RequestItem.]<Application|Permission|ROLE_POLICY|User>.<entity-attribute-key> |
Keyword(s) only header |
<Reviewer|ReviewItem> or <Approver|RequestItem> |
Attribute based criteria cell |
[<entity-name>.]<attribute-name> <Op> <value(s)> |
Attribute and relationship based criteria cell |
[<entity-name>.]<attribute-name> <Op> ReviewItem.<entity-name>.[<relationship-name>.]<attribute-name> |
NOTE:Specifying only keywords in the header column, and specifying other entity and attributes details in the criteria cells provides more flexibility than other formats.
Operator Syntax
Value entries for attributes that have numeric data types support the following list of comparison prefixes: >, >=, <, <=, !=, <>. For example: "Permission.risk","< 40".
Value entries for attributes that have string data types support multiple values by using the pipe (|) symbol. For example "Reviewer.user.displayName","Sue Smith|Jerry Jones|Tom Carter". Additionally, you can use the following operators:
!IS_EMPTY! or !NULL!
!IN!
!CONTAINS!
!MATCHES!
!ENDS_WITH!
!STARTS_WITH!
!NOT!
Date Type
The system evaluates date types in comparisons using ISO 8601 date and time format. The following are some examples of January 31, 2017:
2017-01-31
2017-01-31T10:00Z
2017-01-31T10:00-05:00
NOTE:Even though the format allows for time to be specified, Identity Governance only stores the date in the catalog for date entity types.
Relationships can be nested in coverage maps. However, relationships cannot be referenced in the ReviewItem criteria cell, they can only be accessed from the Reviewer or Approver criteria cell.
Find below the supported predefined relationships:
Coverage Map Type(s) |
Entity |
Relationship |
Related Entity |
---|---|---|---|
REVIEW and REQUEST |
USER |
supervsior |
USER |
REVIEW and REQUEST |
USER |
affiliate |
USER |
REVIEW and REQUEST |
APPLICATION |
applicationOwners |
applicationOwners (table) |
REVIEW and REQUEST |
applicationOwners |
owner |
USER |
REVIEW and REQUEST |
applicationOwners |
groupOwner |
GROUP |
REVIEW and REQUEST |
PERMISSION |
permissionOwners |
resolved_spermission_owner (table) |
REVIEW and REQUEST |
resolved_spermission_owner |
owner |
USER |
REVIEW only |
ACCOUNT |
accountHolders |
saccount_user (table) |
REVIEW only |
saccount_user |
holder |
USER |
REVIEW only |
ACCOUNT |
accountOwners |
resolved_saccount_owner (table) |
REVIEW only |
resolved_saccount_owner |
owner |
USER |
REQUEST only |
ROLE_POLICY (technical role) |
role_policyOwners |
policy_owner (table) |
REQUEST only |
policy_owner |
owner |
USER |
REQUEST only |
policy_owner |
groupOwner |
GROUP |
NOTE:Any of the relationships that resolve to a table would need another segment to resolve to an ENTITY. For example, APPLICATION.applicationOwners is incomplete, since it resolves to a table. The complete expression should be: APPLICATION.applicationOwners.USER.<attributeName> or APPLICATION.applicationOwners.GROUP.<attributeName>
USER based reviewer with risk and location as criteria
"Reviewer.user.displayName","Permission.risk","User.location" "Sue Smith",">90","Boston" "Charles Smith",">70","New York"
The first line is the header row and contains the column headers that identify the entity attributes that Identity Governance will use to determine reviewers.
The example uses the risk attribute from the permission entity and the location attribute from the user entity to match against review items. Once a review item matches, the example uses the displayName attribute from the User entity to select a reviewer.
All of the review item criteria columns must match for that row to be considered a match to the review item. In this example, the second line only matches a review item where both the permission's risk is greater than 90 and the user's location is Boston.
USER based reviewer with multiple criteria
"Reviewer.user.displayName","User.department" "Armando Colaco","!STARTS_WITH! Opera" "Charles Ward","!NOT! !MATCHES! Finance" "Henry Morgan","!NOT! !NULL!"
The reviewer assignment attempts to perform a match on each row of the coverage map until a match has been found. The first row is the header and contains the entity attributes that are being evaluated. The second row assigns Armando Colaco as reviewer if the department of the user under review starts with Opera. The third row assigns Charles Ward as reviewer for users that are not members of the Finance department. The fourth row assigns Henry Morgan as reviewer for users that are members of a department.
During coverage map processing, a matching row is searched for in the order they appear in the CSV file. Once a match has been found for a review item, the reviewers are assigned based on that matching row, and no further rows are processed for that review item.
NOTE:Any review items that do not find a match will be assigned to the review exception queue.
Keywords only header with review item referenced in criteria cells
"ReviewItem", "Reviewer" "user.department !IN! Transportation|Tours", "user.location == ReviewItem.user.supervisor.location" "user.department !NULL!", "user.uniqueUserId !IN! ReviewItem.application.applicationOwners.owner.uniqueUserId"
In this example, the header cells uses a simpler format by using only keywords, and the first criteria row uses relationships to assign reviewer. Note that the ReviewItem is referenced within the Reviewer criteria cells. For users under review that are in the Transportation or Tours department, reviewer is assigned based on the location of the supervisor of the user
The second criteria row, specifies multiple reviewers based on the owners of the application under review if the department attribute is null.
Self and account owners as reviewers
"ReviewItem.account.relationToUserType","Reviewer.user.uniqueUserId" "==SHARED","!IN!ReviewItem.account.accountOwners.owner.uniqueUserId "==SINGULAR","!IN!ReviewItem.account.accountHolders.holder.uniqueUserId"
In this example, the headers cells use keywords and the criteria cells uses relationships to specify that all shared accounts are reviewed by the account owner, and single assigned accounts are reviewed by the holder of the account (self).
Supervisors as reviewers
"ReviewItem.account.relationToUserType","Reviewer.user.uniqueUserId" "==SHARED", "!IN!ReviewItem.account.accountOwners.owner.supervisorUniqueId" "==SINGULAR","!IN!ReviewItem.account.accountHolders.holder.supervisorUniqueId"
In this example, supervisor of the account owner is specified as the reviewer for all shared accounts and supervisor of the holder of the account is spas reviewer for single accounts.
Policy owners as approvers
"Approver.user.uniqueUserId","Approver.group.uniqueGroupId","RequestItem" "!IN! RequestItem.role_policy.policyOwners.owner.uniqueUserId","!IN! RequestItem.role_policy.policyOwners.groupOwner.uniqueGroupId","role_policy.risk > 30"
In this example, for access requests to technical roles, if risk is greater than 30, then the policy owner is assigned as the approver.
To load coverage map:
Log in to Identity Governance as a Global or Data Administrator.
Select Administration.
Select Coverage Maps to expand the section.
To add a new coverage map:
Select +.
Select coverage map type: REVIEW or REQUEST.
Enter coverage map name and description.
Browse for the coverage map CSV file.
Select Save.
Repeat the above steps to upload additional coverage maps.
To preview the map, select the number of segments.
To modify a coverage map:
Select the coverage map.
Browse for a different CSV file.
Select Open to upload and replace the selected CSV file.
To delete a coverage map, select Delete.
NOTE:Only coverage maps not in use can be deleted.