Your access model affects which access items appear in certifications, and your connectivity configurations define how revoked access is removed from enterprise systems.
Certifications may include entitlement, access profile, and role data. However, based on the way access is granted to users, only some of those items appear in certifications or can be revoked through them.
All roles can appear in certifications, with these behaviors:
Roles obtained through an access request can be approved or revoked.
Roles assigned to users through automated assignment criteria can only be acknowledged since the role model controls the role assignment.
Access profiles obtained through access requests or detected based on users' existing entitlements can be certified. Access profiles granted through a role or lifecycle state do not appear individually in certifications.
Access profiles included in the user’s assigned lifecycle state do not appear in certifications at all.
Access profiles granted to a user through a role are encapsulated in the role and can only be managed through that role.
Entitlements can be individually certified only if they are not encapsulated in the user's access profiles or roles.
Source Owner certification campaigns only include access items (access profiles and entitlements) that were granted to a user without the use of a role or lifecycle state.
Identity Details in Certifications
Certifications display details about identities to help reviewers make decisions about their access. By default, an identity’s email, lifecycle state, and manager attributes display. You can add up to 5 additional attributes using the Update Public Identity Config endpoint.
IdentityNow prevents users from certifying their own access by automatically splitting their access into a separate certification and assigning review responsibilities to another identity.
IdentityNow uses the following process to prevent self-approvals:
- The certification is first sent to the identity’s manager.
- If the identity does not have a manager, the certification is sent to the owner of the campaign.
- If the identity is the owner of the campaign, the certification is sent to an administrator.
Automatic certification reassignments from work reassignments follow the same process. However, when a user attempts to manually reassign a certification to a new owner, IdentityNow will block the reassignment if the certification contains any of the new owner's access.
When a certifier signs off on their certification, IdentityNow initiates removal of any revoked access in one of two ways:
Automated remediation: If IdentityNow has a direct connection to a source with the ability to provision changes to it, the access removal process is automatic and immediate.
Manual remediation: If IdentityNow cannot write changes directly to the source, it creates a task, assigned to the source owner, instructing them to make the required change in the source system. Administrators can oversee and verify this manual remediation process.
- Certification revocations are included in the Certifications service.
- It is possible to force a direct-connected source to use the manual remediation path by removing IdentityNow’s ability to provision changes to that system. This requires an API-based configuration change for the source. That change means that all provisioning actions for that source, whether adding or removing access, will be managed through tasks and completed through actions taken outside of IdentityNow. Consult SailPoint Services or your partner organization for assistance with this configuration.
Revoke decisions that are not signed off will not be applied. At campaign completion, unsigned certifications are treated as though no decisions were made at all. The campaign configuration determines whether those items are auto-approved or whether the admin can choose to approve or revoke all.