During an access review, every User view is passed to the Review Determination rule to determine whether the corresponding user entitlement record can be automatically approved or rejected, automatically placed into remediation state, or if the record must be manually attested. A user entitlement is a complete User view (in which some resources might be omitted) and some tracking data.
You can use the Review Determination rule to significantly increase the efficiency of an access review by
Encapsulating any institutional knowledge that would allow a user to be automatically approved or rejected. If you express that knowledge in this rule, you reduce the number of manual attestations needed and improve overall review performance.
Configuring this rule to return information that is visible to the attestors as a “hint.” For example, when the rule determines that a user has privilege access to a resource, the rule provides a hint to the attestor, as shown in the following example:
<map> <result> <i>1</i> <s>reason</s> <s><reason the attestation was auto-approved/rejected></s> <s>attestorHint</s> <s><hint to attestor></s> </map> |
Configuring the rule to access the User view (including any Compliance Violations) and compare the user’s previous user entitlements, which allows the rule to approve or reject all user entitlements that are the same as (or different from) a previously approved user entitlement.
You can add an argument that allows the rule to compare subsets of the User view. For example:
<set name=’viewCompare’> <!-- compare the entire view (3rd argument can specify sub-path) --> <invoke name=’compareUserViews’ class=’com.sun.idm.auditor.ui.FormUtil’> <ref>userView</ref> <ref>lastUserView</ref> <s>accounts</s> </invoke> </set> |
This argument compares User views and allows the caller to specify a subpath of the complete User view using GenericObject path expressions. If you just want to compare particular account data, the subpath can specify that data. If you compare just the accounts subpath of the User view, you are less likely to encounter differences that are not reflected on a real resource.
Differences found in the User view comparison are returned in the reason element of the output map. The audit log captures this difference data if the rule returns 0 (reject attestation) or 2 (approve attestation), just as the predefined Reject Changed Users rule does.
You can use the Reject Changed Users rule to verify exactly what Waveset thinks is different and you can look at the auditable attributes in the resulting audit log records.
Inputs:
Accepts the following arguments:
context: LighthouseContext
review.scanId: Current access scan ID
review.username: Waveset account name of user being scanned
review.userId: Waveset ID of user being scanned
attestors: Attestors’ Waveset account names
userView: Current User view
You must specify the following for a custom Review Determination rule: