test

Oracle Waveset 8.1.1 Deployment Reference

Auditor Rules

To achieve a high level of configurability with minimal complexity, Identity Auditor makes judicious use of rules in audit policy and access scan object configuration.

Table 4–13 provides an overview of the rules you can use to customize how audit policy remediation works and how access scans operate.

Table 4–13 Auditor Rule Types Quick Reference

Rule Type 

Example Rules 

subTypes and authTypes 

Purpose 

Attestor 

Default Attestor 

SubType: ATTESTORS_RULE

AuthType: AccessScanRule

Automates the attestation process by specifying a default attestor for manual entitlements. 

Attestor Escalation 

Default EscalationAttestor 

SubType: AttestorEscalationRule

AuthType: AccessScanRule

Automates the attestation process by specifying a default escalation user for manual attestation. 

Audit Policy 

Compare Accounts to Roles 

SubType: SUBTYPE_AUDIT_POLICY_RULE

SubType: SUBTYPE_AUDIT_POLICY_SOD_RULE

AuthType: AuditPolicyRule

Compares user accounts to accounts specified by current Roles. 
 

Compare Roles to Actual Resource Values 

SubType: SUBTYPE_AUDIT_POLICY_RULE

SubType: SUBTYPE_AUDIT_POLICY_SOD_RULE

AuthType: AuditPolicyRule

Compares current resource attributes with those specified by current Roles. 

Remediation User Form 

 

SubType: USER_FORM_RULE

AuthType: Not specified

Automates the attestation process by allowing audit policy authors to constrain which part of a User view is visible when responding to a particular policy violation. 

Remediator 

Default Remediator 

SubType: REMEDIATORS_RULE

AuthType: AccessScanRule

Automates the remediation process by specifying a remediator for any entitlements created in remediating state. 

Review Determination 

Reject Changed User 

SubType: REVIEW_REQUIRED_RULE

AuthType: AccessScanRule

Automates the attestation process by automatically rejecting user entitlement records. 
 

Review Changed Users 

SubType: REVIEW_REQUIRED_RULE

AuthType: AccessScanRule

Automates the attestation process by automatically approving user entitlement records. 
 

Review Everyone 

SubType: REVIEW_REQUIRED_RULE

AuthType: AccessScanRule

Automates the attestation process by requiring manual attestation for some user entitlement records. 

User Scope 

All Administrators 

SubType: USER_SCOPE_RULE

AuthType: AccessScanRule

Provides flexibility in selecting a list of users to be scanned by an access scan. 
 

All Non-Administrators 

SubType: USER_SCOPE_RULE

AuthType: AccessScanRule

Provides flexibility in selecting a list of users to be scanned by an access scan. 
 

Users Without a Manager 

SubType: USER_SCOPE_RULE

AuthType: AccessScanRule

Provides flexibility in selecting a list of users to be scanned by an access scan. 

ViolationPriority 

ViolationPriority 

SubType: Not specified

AuthType: EndUserAuditorRule

Customization— allows the deployment to specify what are valid violation priorities and the corresponding display strings. 

ViolationSeverity 

ViolationSeverity 

SubType: Not specified

AuthType: EndUserAuditorRule

Customization— allows the deployment to specify what are valid violation severities and the corresponding display strings. 

The following sections provide information about these Identity Auditor rules, how you might customize them, and why:

Attestor Rule

Every user entitlement that is created in a pending state must be attested by someone. During an access review, Identity Auditor passes each User view to the Attestor rule to determine who gets the initial attestation requests.

The idmManager attribute on the WSUser object contains the Waveset account name and ID of the user’s manager.

You can use alternate implementations to designate both IdmManager and any Resource owners as attestors (for Resources included in the view). This rule takes the current User view and a LighthouseContext object as inputs, so you can use any data known to Waveset.

Inputs:

Accepts the following arguments:

You must specify the following for a custom Attestor rule:

AuthType 

AccessScanRule

SubType 

ATTESTORS_RULE

Called 

During access scan; after evaluating all audit policies, but before dispatching the user entitlement 

Returns 

A list of zero or more Waveset attestor names (users responsible for attesting a particular user entitlement) or NamedValue pairs.

  • If the result is a string, it must resolve to an Waveset account ID. If delegation is enabled for the access scan, the access scan will use the delegation settings of the Waveset user returned by the code.

  • If the result is a NamedValue, it assumed to be a bound delegation pair [Delegator, Delegatee], and the access scan will not resolve any further.

    Note –

    If the rule returns NamedValue pair elements, they are passed on without validation.

  • If the result is not a valid Waveset user name, the rule appends errors to the scan task results, but the scan thread continues.

  • If the result is a zero-length list, the attestation request remains in pending state because nobody will process the request.

  • If the result is neither a string or a NamedValue, an exception results and the scan thread aborts.

Predefined Rules 

Default Attestor 

Location 

Compliance > Manage Policies > Access Scan > Attestor Rule 

Attestor Escalation Rule

A workflow calls the Attestor Escalation rule when an attestation times out because the attestor did not take action within a specified period of time. This rule returns the next person in the escalation chain based on the cycle count.

Inputs:

Accepts the following arguments:

You must specify the following for a custom Attestor Escalation rule:

AuthType 

AccessScanRule

SubType 

AttestorEscalationRule

Called 

During an attestation workflow when a workitem times out. (Default timeout is 0— never times out).

Returns 

A single attestor name or a list of attestor names, which must be valid Waveset account names.

  • If the attestor does not have a manager, the Attestor Escalation rule returns Configurator.

  • If the result is an invalid account name or null, the attestation workitem is not escalated.

Predefined Rules 

Default EscalationAttestor 

Location 

Compliance > Manage Policies > Access Scan > Attestor Escalation Rule 

Audit Policy Rule

An audit policy contains a set of rules that it applies to data representing an object being audited. Each rule can return a boolean value (plus some optional information).

To determine whether a policy has been violated, the audit policy evaluates a logical operation on the results of each rule. If the audit policy has been violated, a compliance violation object might result, with (typically) one compliance violation object per policy, rule, or whatever was being audited. For example, an audit policy with five rules might result in five violations.

Inputs:

None

You must specify the following for a custom Audit Policy rule:

AuthType 

AuditPolicyRule

Note –

When you use the Audit Policy Wizard to create an Audit Policy rule, the wizard uses the AuditPolicyRule authType by default.

If you use the Identity Manager IDE to create an Audit Policy rule, be sure to specify the AuditPolicyRule authType.

SubType 

  • SUBTYPE_AUDIT_POLICY_RULE (for an audit policy rule)

  • SUBTYPE_AUDIT_POLICY_SOD_RULE (for an audit policy SOD rule)

    SOD (separation of duties or segregation of duties) rules differ from regular rules in that they are expected to produce a list element in the rule output. A list element is not required; but if one is not present, it causes any corresponding violations to be ignored in SOD reporting.

Called 

During an Audit Policy Evaluation 

Returns 

An audit policy rule must return an integer value, but the value can be expressed as one of the following: 

  • A pure integer:


    <i>1</i>

  • An integer within a map of additional data:


    <map>
  <s>result</s>
  <i>1</i>
  ...
</map>

    If the audit policy returns a map, other elements can affect the resulting compliance violation. These elements include:

    • resources element: Causes the compliance violation to refer to two resources, resource one and resource two. These values must be real resource names because the compliance violation contains actual object references (so the names are resolved to IDs). (Default is no resource.)


      <s>resources</s>
<list>
    <s>resource one</s>
    <s>resource two</s>
</list>

    • severity element: Causes the compliance violation to have the specified severity. (Default is 1.)


      <s>severity</s>
<i>3</i>

    • priority element: Causes the compliance violation to have the specified priority. (Default is 1.)


      <s>priority</s>
<i>2</i>

    • violation element: Prevents the audit scanner from creating a rule violation— even if the audit policy evaluates to true.

      By default, if the audit policy evaluates to true, it creates compliance violations for each rule that returns a non-zero. Setting this element to zero allows the rule to return true, but does not create a violation for the rule.


      <s>violation</s>
<i>0</i>
Note –

The Audit Policy Wizard only creates rules that reference a single resource and return an integer value (not a map).

To use any of the preceding map-related features, you must write the rule yourself. Some very sophisticated audit policy rule examples are provided in sample/auditordemo.xml.

Predefined Rules 

  • Compare Accounts to Roles: Compares user accounts to accounts specified by roles. Any account not referenced by a role is considered an error.

  • Compare Roles to Actual Resource Values: Compares current resource attributes with those specified by current Roles. Any differences are considered errors, and any resources or resource attributes not specified by a role are ignored.

Note –

The RULE_EVAL_COUNT value equals the number of rules that were evaluated during a policy scan. Waveset calculates this value as follows:

RULE_EVAL_COUNT = # of users scanned x (# of rules in policy + 1)

The +1 is included in the calculation because Waveset also counts the policy rule, which is the rule that actually decides if a policy is violated. The policy rule inspects the audit rule results, and performs the boolean logic to come up with a policy result.

For example, if you have Policy A with three rules and Policy B with two rules, and you scanned ten users, the RULE_EVAL_COUNT value equals 70 because

10 users x (3 + 1 + 2 + 1 rules)

Remediation User Form Rule

The Remediation User Form rule allows audit policy authors to constrain which part of a User view is visible when they are responding to a particular policy violation.

When a remediator edits a user during entitlement remediation processing, a JSP (approval/remModifyUser.jsp) calls the Remediation User Form rule. This rule allows the access scan to specify an appropriate form for editing a user. If the remediator has already specified a user form, then the access scan uses that form instead.

Inputs:

Accepts the item argument (Remediation WorkItem)

You must specify the following for a custom Remediation User Form rule:

AuthType 

Not specified 

SubType 

USER_FORM_RULE

Called 

During JSP form processing after the remediator clicks Edit User on the remediation form. 

Returns 

The name of a User Form or a null. 

Predefined Rules 

None 

Location 

  • Compliance > Manage Policies > Access Scan > Remediation User Form Rule

  • Compliance > Manage Policies > Audit Policy > Remediation User Form Rule

Remediator Rule

During an access review, every User view is passed to the Remediator rule to determine who should get the initial remediation requests. This rule is analogous to the Attestors rule, except the Remediator rule is called when a workitem is created in the remediating state.

Inputs:

Accepts the following arguments:

You must specify the following for a custom Remediator rule:

AuthType 

AccessScanRule

SubType 

REMEDIATORS_RULE

Called 

During access scan, after evaluating all audit policies and before dispatching the user entitlement 

Returns 

A list of zero or more Waveset remediator names or NamedValue pairs.

  • If the result is a string, it is resolved to a Waveset user, and if delegation is enabled for the access scan, the user’s delegation data is used.

  • If the result is a NamedValue, it is assumed to be a bound delegation pair [Delegator, Delegatee].

  • If the result is one or more invalid Waveset user names, errors indicating a problem are appended to the scan task results, but the scan thread continues.

  • If the result is not a string or NamedValue, an exception occurs and the scan thread aborts.

  • If the results are a zero-length list, the remediation request remains in a pending state because nobody will process it.

Note –

If the rule returns NamedValue pair elements, they are passed on without validation.

Predefined Rules 

Default Remediator 

Location 

Compliance > Manage Policies > Access Scan > Remediator Rule 

Review Determination Rule

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


<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>
 

<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:

You must specify the following for a custom Review Determination rule:

AuthType 

AccessScanRule

SubType 

REVIEW_REQUIRED_RULE

Called 

During access scan, after evaluating all audit policies and before dispatching the user entitlement 

Returns 

An integer or a map 

  • If the rule returns an integer, its value is interpreted as follows:

    • -1: No attestation required

    • 0: Automatically reject attestation

    • 1: Manual attestation

    • 2: Automatically approve attestation

    • 3: Automatically remediate attestation

      When the attestation is set to auto-remediating mode, Waveset creates an AccessReviewRemediation work item and routes the work item through the Remediator rule associated with the access scan.

  • If the rule returns a map, the output must be similar to one of the following examples:

    Example 1: Manually attests the user entitlement, and the rule provides a hint to the manual attestor.


    <map>
   <result>
   <i>1</i>
   <s>reason</s>
   <s><reason that the attestation was auto-approved/rejected></s>
   <s>attestorHint</s>
   <s><hint to attestor></s>
</map>
    Note –

    The attestorHint value in the output map must be a string or a list of strings.

    Example 2: Automatically rejects the user entitlement. The rejection comment indicates that group membership is disallowed.


    <map>
  <s>result</s>
  <i>0</i>
  <s>reason</s>
  <s>User belongs to group Domain Administrators</s>
</map>
    Note –

    The value of attestorHint is shown to the attestor through the user interface. The value of reason is recorded in the attestation history.

Predefined Rules 

  • Reject Changed Users: Automatically rejects user entitlements that have changed since the last approval state, and automatically approves user entitlements that are unchanged. The rule only compares the accounts section of the User view.

    Each unknown User view is forwarded for manual attestation.

  • Review Changed Users: Automatically approves any users whose account data has not changed since their last approved entitlement. The rule only compares the accounts section of the User view.

    Users with changed account data or no approved data must be manually attested.

  • Review Everyone: Forwards all user entitlement records for manual attestation.

Location 

Compliance > Manage Access Scans > Access Scan > Review Determination Rule 

User Scope Rules

If an access scan has users scoped by a rule, the User Scope rule is evaluated to determine a list of users to scan.

Inputs:

Accepts the lhcontext argument

You must specify the following for a custom User Scope rule:

AuthType 

AccessScanRule

SubType 

USER_SCOPE_RULE

Called 

At the beginning of an access scan 

Returns 

An Waveset user name or a list of Waveset user names. Each name must be a valid Waveset user name.

  • If the results contain any names that cannot be resolved to valid Waveset user names, the rule returns an error.

  • If the results contain any duplicate user names, the rule returns an error.

Note –

  • An access scan that scans the same user multiple times might fail to create the attestation workflow for a subsequent instance of the same user. Therefore, a customized implementation of the User Scope rule should provide checks to avoid duplicate users in the output.

  • This rule can return accounts that are not available to the administrator running the scan. In this case, the scan will attempt to get the account’s User view and fail; resulting in an error in the scan task.

Predefined Rules 

  • All Administrators: Returns all users with administrative capabilities assigned.

  • All Non-Administrators: Returns all users with no administrative capabilities assigned.

  • Users Without Manager: Returns all user accounts with no manager (idmManager) assigned.

Location 

Compliance > Manage Access Scans > Access Scan > User Scope Rule 

ViolationPriority Rule

Use the ViolationPriority rule to allow a deployment to specify what the valid violation priorities are, and what the corresponding display strings will be.

Inputs:

None

You must specify the following for a custom ViolationPriority rule:

AuthType 

EndUserAuditorRule

SubType 

Not specified 

Called 

When displaying the violation list and when changing violation priority. 

Returns 

A list of key/value pairs indicating priority integer value and a corresponding string. The integer values must be contiguous because the rule returns a list, not a map.

Note –

You can customize this rule to change the display value for any priority setting.

When a ComplianceViolation is created, you can change priority values in the Remediation WorkItem list viewer. Select one or more Remediation WorkItems, and then select Prioritize, which enables you to change priority values.

To see these values in the Remediation WorkItem list view, you must change the approval/remediate.jsp page by setting the includeCV option to true (default is false). However, enabling the more detailed view affects performance, which may be unacceptable for deployments with lots of Remediations.

The custom value expects the ViolationPriority rule to be an array rather than a map. So, if you use 100 as the integer value, the rule must have 200 elements (alternate int/string). The list provides both string mapping for the integer and populates the selection in the form where you changed it.

Predefined Rules 

ViolationPriority 

Location 

Called from the Remediation List Form 

ViolationSeverity Rule

Use the ViolationSeverity rule to allow a deployment to specify what the valid violation severities are, and what the corresponding display strings will be.

Inputs:

None

You must specify the following for a custom ViolationSeverity rule:

AuthType 

EndUserAuditorRule

SubType 

Not specified 

Called 

When displaying the violation list and when changing violation severity. 

Returns 

A list of key/value pairs indicating severity integer value and a corresponding string. The integer values must be contiguous because the rule returns a list, not a map.

Note –

You can customize this rule to change the display value for any priority setting.

When a ComplianceViolation is created, you can change severity values in the Remediation WorkItem list viewer. Select one or more Remediation WorkItems, and then select Priority, which enables you to change severity values.

To see these values in the Remediation WorkItem list view, you must change the approval/remediate.jsp page by setting the includeCV option to true (default is false). However, enabling the more detailed view affects performance, which may be unacceptable for deployments with lots of Remediations.

The custom value expects the ViolationSeverity rule to be an array rather than a map. So, if you use 100 as the integer value, the rule must have 200 elements (alternate int/string). The list provides both string mapping for the integer and populates the selection in the form where you changed it.

Predefined Rules 

ViolationSeverity 

Location 

Called from the Remediation List Form 

Sample Auditor Rule Multiple Account Types

The following example demonstrates how to use the Sample Auditor Rule Multiple Account Types rule. The location of the rule is 


sample/rules/SampleAuditorRuleMultipleAccountTypes.xml

ProcedureTo Dynamically Test Multiple User Accounts per Resource

  1. Set up a resource with multiple account types.


    <?xml version=’1.0’ encoding=’UTF-8’?>
<!DOCTYPE Waveset PUBLIC ’waveset.dtd’ ’waveset.dtd’>
<Waveset>
<Rule subtype=’IdentityRule’ name=’Administrator Identity’>
  <concat>
     <s>adm</s>
     <ref>attributes.accountId</ref>
  </concat>
</Rule>
</Waveset>

  2. Add a user with two accounts on the resource and set up a user form so that the new resource attributes are directly assigned separately:


    account[Simulated Resource].department
account[Simulated Resource|admin].department

  3. Assign different values for each account and test the policy rule.

    Location:


    sample/rules/SampleAuditorRuleMultipleAccountTypes.xml