Common Expressions Explained in Access Certifications
Last Updated:
Overview
When creating an Access Certification, the builder has the ability to take the default options related to which users are being reviewed and who the reviewer(s) should be. They also have the ability to leverage very powerful expressions to select a subset of targeted users or dynamically look elsewhere for who the reviewer should be.
Applies To
- Okta Access Certifications
Solution
Assumptions
- The user has familiarity with Okta and holds administrative rights to create Access Certification Campaigns.
- User has familiarity with building Access Certifications. Use the Create resource campaigns guide to review how to create campaigns.
Steps
In order to understand how to use Okta Expression Language in Access Certifications, we must discuss the two types of campaigns:
- Resource Campaign
- User Campaign
Resource Campaigns are designed to target Applications, Groups, and Applications with Entitlements, while User campaigns are designed to target resources assigned to a specific user or group of users. Resource Campaigns allow expression language to be used when defining which Users are in scope and which Reviewers. User Campaigns only allow expression language when determining the Reviewer.
When building expressions, remember that:
- && means "And’
- || means "Or’
- ! means is not
- “ or ‘ can be used interchangeably, but not at the same time. Either all of “ or all of ‘ is preferred.
Users Step
When defining users in scope for an Access Certification Campaign, enter the expression on this screen.
Click the Sample expressions to see some common examples listed below.
Users selection expressions:
|
Restrict a campaign to members of Google-Read group |
|
|
Restrict a campaign to members with a certain attribute in their profile |
|
|
More complex restricting a campaign based upon multiple attributes |
|
|
More complex restricting a campaign based upon user having one attribute value or the other |
|
|
Restrict a campaign to non members of Google-Security group |
|
|
Restrict a campaign to members of one group AND not the other group |
|
|
Restrict a campaign to members of “Google-Read” OR not a member of Google-Security |
|
|
Restrict a campaign to users that are a member of a single group |
|
|
Restrict a campaign to users that are a member of multiple groups |
|
|
Restrict a campaign to users that are a member of one group OR another |
|
|
Restrict a campaign to users that are a member of a group based on its name. |
|
Reviewers Step
Reviewer selection expressions:
|
Assign the Reviewer of a campaign to the managerId field for lookup if the user is in either Human Resources or Accounting department. Otherwise assign it to “user@domain.com” |
|
|
Assign a reviewer to the owners of a group |
user.findGroupAndGetOwners({"group.id": "00gdqjkbwxvIBXNWw1d7"}, "USER")[0] |
|
Assign reviewer who belong to a specific Realm |
Use this expression only if the Realms feature is enabled. |
|
Assign the user’s manager to each user |
|
|
Assign a user’s manager to only users with a certain profile attribute (in this case, department is Department 1), and a specific reviewer for all other users. |
|
|
Assign a reviewer for users who are members of two groups. Otherwise, assign the user's manager. |
|
|
Assign a reviewer for users who are a member of at least one of the two groups. Otherwise, assign the Fallback reviewer. |
|
|
Assign a reviewer for users who are a member of one group, but not a member of another group. Otherwise, assign the user's manager. |
|
Happy Governing!
Related References
- To view feature requests and upvote product enhancement requests, please visit Okta Ideas.
- Looking for Okta Identity Governance help? Visit the Okta Identity Governance Product Hub or schedule Office Hours with the Okta Identity Governance team.
