When Access Certification Campaigns are created in Okta, it is possible that the reviewer is the same user as the subject being reviewed. This use case is defined as “Self-Attestation” and can be an undesirable result of the Okta Access Certification Campaign setup.

Example of Self-Attestation as an end-user

• Okta Access Certification
• Okta Workflows
• Okta Identity Governance API

Preventative Measures

Currently, within Okta Access Certification Campaigns, there is no way to completely prevent a user from being assigned to themselves, but there are some preventative measures that can be taken to stop users from being initially assigned to themselves.

With the expression language in the Reviewer tab of the campaign, it is possible to write logic to automatically reassign the Reviewer to somebody else if they are also the subject. For example, the below expression could find the custom reviewer attribute in each user’s Okta profile and assign them to their reviews in a campaign:

user.profile.reviewerId

But what happens when a user's reviewer attribute is set to themselves for some reason or another? This would create a situation where the user is self-attesting to their own access. To prevent this, we can wrap the expression with a conditional statement to check if the user would be assigned themselves, and reassign to an outside party. An example would be:

This solution would assign any reviewers who would be the subjects of their own reviewers to another Okta admin. In this case, I chose myself. 

While this solution will prevent most reviewers from being assigned to themselves, it will not prevent all of these cases. There are still events that could cause Self-Attestation, and as such, it can be important to create notifications for self-attestation events.

Notifications

It is also possible to leverage Okta workflows to create notifications whenever self-attestation occurs. In order to build a workflow capable of recognizing when self-attestation occurs, we have to check each campaign as it launches to check each subject and reviewer pair to make sure they’re not the same.

Event 1: Campaign Launch

The most obvious way to start this workflow is to define the event that requires the workflow to check for self-attestation. Unfortunately, there are currently no Event Hooks or Okta workflow events for campaigns being launched, so I have chosen to scan the system log every 5 minutes for newly launched campaigns.

Here are the settings to schedule a flow to run every 5 minutes:

Here is an example of how to scan the system log for the last 5 minutes of activity. The query I am running on the system log is effectively: 

‘eventType eq "certification.campaign.launch"’

After this query, the workflow can pull the campaignID’s for all of the campaigns involved. For each of the System log records pulled, we know there is exactly one campaign involved, so we can send the target of each record to a subflow to do that, since the campaign is the “target” of the record in the system log. Send each record to a subflow:

Now, given the target object data structure, we can pull the campaignID and send it to a subflow to check for self-attestation:

In that subflow, we can filter all of the active reviews based on the campaign ID. This will return a list of all reviews that were just assigned.

After the custom API call, we can send each review in the list to a subflow to check for Self-Attestation.

The final comparison is pretty simple! If the principal is the same as the reviewer, it is self-attestation!

Now that we know self-attestation is occurring, we need to send notifications. In my case, I chose to link myself to the campaign via Slack message.

The final result looks like this:

Event 2: Reassignment

It is also possible that a reviewer is assigned to themselves via reassignment. This would occur if a different reviewer re-assigns a review to the subject they are reviewing! That would look something like this:

Since it is possible to accidentally or purposefully reassign a review to the subject you are reviewing, we must solve for this case, too!

Luckily, there is a workflows event for whenever a user makes a decision on a campaign review. In this example, we can check if the event was a reassignment and continue if it was:

Finally, we can take the review ID from the event and use the same subflow from event #1 to compare the reviewer Id and subject Id and send notifications if they’re the same person.

These are just a few examples of how we can leverage workflows to send notifications after an occurrence of Self-Attestation. There are many more channels to notify yourself if necessary!

Related References

• ​Okta Identity Governance API
• Okta Access Certification documentation
• Okta Workflows documentation

Looking for Okta Identity Governance help? Visit the Okta Identity Governance Product Hub or schedule Office Hours with the Okta Identity Governance team.