Recertification policies

Recertification simplifies and automates the process of periodically revalidating a target type (account or access) or a membership (role or resource group). The recertification process validates whether the target type or membership is still required for a valid business purpose. The process sends recertification notification and approval events to the participants that you specify. A recertification policy includes activities to ensure that users provide confirmation that they have a valid, ongoing need for a specified resource or membership.

A recertification policy defines how frequently users must certify their need for a resource or membership. The policy also defines the operation that occurs if the recipient declines or does not respond to the recertification request. Recertification policies use a set of notifications to initiate workflow activities that are involved in the recertification process.

There are three recertification target types:
  • User
  • Account
  • Access

A user recertification, unlike an account or access recertification, allows you to certify roles, accounts, and groups (which include accesses) for the specified user within a single activity.

A recertification policy is implemented as a workflow. A default workflow is automatically built for simple policies. A recertification policy can prompt a recipient, such as a manager or system administrator to certify periodically that users still need to use accounts. The workflow generates an e-mail notification of the work item to be completed for recertification and generates To Do activities to request that the participant accept or reject the recertification.

A service owner can create a recertification policy for services and accesses that are administered by the user. A system administrator can create a recertification policy for all users, services, and accesses. For example, as an administrator, you can define a recertification policy that sets a 90-day interval for account recertification. If the recipient of the recertification request declines recertification, the account is suspended. The owner of the account that was rejected during recertification is notified by email based on the message template configured in the policy.

The recertification policy access control item (ACI) controls what a user can view or do with recertification policies. IBM Verify Identity Governance provides default access control items that target recertification policies. The following table shows how changes to the default ACIs affect what you can see or do with the policies.

Table 1. Recertification policies and access control items
Who is permitted Target object and access control item Effect
Service owner group Recertification policy - add, modify, remove, or search Allows service owners to manage recertification policies.
Auditor or manager group Recertification policy - search Allows members of the auditor group or manager group to search or view recertification policies.
Auditor, manager, or service owner groups Reports (recertification pending, history, and policies) run operation Allows members of these groups to view these reports.
Audits that are specific to recertification are created for use by several reports that are related to recertification:
Accounts or access pending recertification
Provides a list of recertifications that are not completed.
Recertification change history (for accounts and accesses)
Provides a historical list of recertifications.
Recertification policies (for accounts and accesses)
Provides a list of all account and access recertification policies.
User recertification history report
Provides a historical list of user recertifications.
User recertification policy definition report
Provides a list of user recertification policies.

Resource selection for recertification

Identity Manager does not select accounts for recertification in the following circumstances:
  • The ITIM Service account of the ITIM administrator (the actual name of the account and service inside Identity Manager) is not selected for recertification so that it is not deleted or suspended inadvertently. Any other ITIM account can be selected.
  • Orphan accounts, which are accounts with no owners, are not selected for recertification.
  • Account and access recertification policies do not select resources if the rejection of the resource results in the same operation. For example, if the rejection action is to suspend the accounts, the recertification policy does not select accounts that are already suspended because the rejection of the recertification would suspend the accounts, which has already occurred. If the rejection action is to delete the accounts after the accounts are suspended, the accounts are selected for recertification because a different action, such as deleting the suspended accounts, had not already occurred.

Recertification policy targets

Recertification policies can target various resources and memberships. Account recertification policies target accounts on specific services. Access recertification policies target specific accesses. User recertification policies can target a combination of role memberships, accounts on services, and groups on services (including groups defined as access).

There is a restriction with account and access policies:
  • A service can be a member of only one account recertification policy
  • An access can be a member of only one access recertification policy

These restrictions do not apply to user recertification policies. A user recertification policy might include services or accesses that are already part of another policy.

Recertification policy configuration modes

The configuration mode determines how you build the policy. The following modes are available:
Simple
If you use the simple mode, a workflow is automatically built, using the options that are selected on the Policy page.
Advanced
If you use the advanced mode, the workflow designer is launched with a simple workflow defined as the base configuration, using the options selected on the Policy page. The workflow can be further customized for business needs.
Note: If a policy is changed from simple to advanced mode, the policy cannot revert to a simple state without losing changes. The policy reverts to the default simple recertification workflow.

Viewing recertification status

Recertification requests can be viewed in View Requests. To find recertification requests, select the View All Requests By Service view or View All Requests view.

For services, see the option in the task list by service to view Account Recertification Status, and navigate to Manage Services > Select a Service. Click the icon adjacent to a service name and select Account Recertification Status to get to the status page.

For group access entitlements, to view Access Recertification Status, navigate to Manage Groups > Select a Service. Select the service and click OK. Then, click the icon adjacent to the group for the accesses and select Access Recertification Status.

Note: On the service protection category for ACIs is a new operation called Recertification Override that specifies which users can view and override the recertification status of an account. A similar ACI exists on the group protection category to specify which users can view and override the recertification status of an access.

Recertification policies and reports

Recertification reports can be requested by system administrators, service owners, managers, and auditors, based on ACIs. Included are reports of the following types:
  • Accounts/Access Pending Recertification Report
  • Recertification Change History Report
  • Recertification Policies Report
  • User Recertification History Report
  • User Recertification Policy Definition Report

The actions taken during an account or access recertification policy run are stored in a database table RECERTIFICATIONLOG that is referenced by the recertification history report.

The actions taken during a user recertification policy run are stored in database tables named USERRECERT_HISTORY, USERRECERT_ROLE, USERRECERT_ACCOUNT, and USERRECERT_GROUP, which are referenced by the user recertification history report.
Note: Recertification audit events are generated from recertification policy workflows only, rather than from operational workflows.