2.4 Using Coverage Maps

In the review definition and the access request approval policy, administrators can select coverage maps to specify:

Reviewers of a User Access or Account Review definition

NOTE:To specify coverage map as a reviewer for unmapped accounts, make sure All unmapped accounts is selected as review items and then specify Review by Coverage Map as the reviewer.
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 by entity-entity relationships

You should understand Identity Governance supported coverage map types, keywords, syntax, and enitity-entity relationships to create and load coverage maps. For more information, see:

2.4.1 Creating Coverage Map

To create a coverage map, create a CSV file with header and criteria cells. For greater flexibility use only keywords. For more information, see:

Supported Coverage Map Types and 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	Reviewer ReviewItem
REQUEST	Maps for request based approver determination	Approver RequestItem

Supported Syntax

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>

HINT: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 with 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:Though the format allows for time to be specified, Identity Governance stores only the date in the catalog for date entity types.

Supported Relationships

Relationships can be nested in coverage maps. However, relationships cannot be referenced in the ReviewItem criteria cell; they can be accessed only from the Reviewer or Approver criteria cell.

The supported predefined relationships appear below:

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, because it resolves to a table. The complete expression should be: APPLICATION.applicationOwners.USER.<attributeName> or APPLICATION.applicationOwners.GROUP.<attributeName>

User Access Review Coverage Map Examples

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. When a review item matches, the example uses the displayName attribute from the User entity to select a reviewer.

All 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 the permission 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 line is the header row 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 who are not members of the Finance department. The fourth row assigns Henry Morgan as reviewer for users who are members of a department.

During coverage map processing, a matching row is searched for in the order they appear in the CSV file. After a match is 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 are 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 use only keywords, and the first criteria row uses relationships to assign a reviewer. Note that the ReviewItem is referenced within the Reviewer criteria cells. For users under review who are in the Transportation or Tours department, a reviewer is assigned based on the location of the supervisor.

The second criteria row specifies multiple reviewers based on the owners of the application under review if the department attribute is null.

Account Review Coverage Map Examples

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 header 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, the supervisor of the account owner is specified as the reviewer for all shared accounts and the supervisor of the holder of the account is specified as reviewer for single accounts.

Access Request Coverage Map Example

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.

2.4.2 Loading the Coverage Map

To load the coverage map:

Log in to Identity Governance as a Global or Data Administrator.
Select Configuration.
Select Coverage Maps to expand the section.
To add a new coverage map:
1. Select +.
2. Select the coverage map type: REVIEW or REQUEST.
3. Type coverage map name and description.
4. Browse for the coverage map CSV file.
5. Select Save.
Repeat the above steps to add additional coverage maps.
To preview the map, select the number of segments.
To modify a coverage map:
1. Select the coverage map.
2. Browse for a different CSV file.
3. Click Open to upload and replace the selected CSV file.
To delete a coverage map, click Delete.

NOTE:You can delete only coverage maps not in use.