Policy enforcement

Policy enforcement reevaluates accounts to determine whether they violate provisioning policies.

Provisioning policies govern the access rights of users for specific services. Provisioning enforcement is incorporated into all business processes that manage the identities and access rights of users on a managed resource. Policy enforcement performs appropriate actions to ensure that user access rights comply with the corporate policies.

Policy enforcement is automatically triggered when you create, modify, or delete the provisioning policies. The following table lists the activities that can automatically start policy enforcement.

Class Operations
Account Create, modify, delete, request account
Service Group Request access
Service Configure policy enforcement, reconcile
Provisioning policy Change policy
Role modify membership

However, you must manually start policy enforcement when:

  • You create a new service.
  • You tag a service or change a service tag.

These situations can cause accounts to become noncompliant or require new accounts to be provisioned. The policies governing this service must be reevaluated to ensure that all accounts are compliant with the provisioning policies. If policy enforcement finds any missing accounts for users who are automatically entitled to an account, it provisions new accounts for them.

You can configure policy enforcement globally or for a specific service. You can choose these enforcement actions:

  • Mark
  • Suspend
  • Correct
  • Alert
  • Use Global Enforcement: Mark

All services except DSML Identity Feed services have policy enforcement. You can perform policy enforcement at any time. When you select to enforce a policy, policy enforcement is scheduled to take action.

Policy enforcement actions

To resolve noncompliant accounts on a service, you can take one of these actions:

Mark
Flags the disallowed account or an account that has noncompliant attribute value.
Suspend
Deactivates the disallowed account or an account that has noncompliant attribute value.
Correct
Replaces a noncompliant attribute on an account with the correct attribute.
The disallowed accounts from the policy evaluation can be exempt from this Correct action. IBM Verify Identity Governance provides the default exemption handler. This handler uses the correct.enforcement.exemption.account.criteria property in the enRole.properties file to determine the matching criteria of exempt accounts. The accounts that match any of the specified criteria are orphaned instead of being removed. The exempt action is defined by the correct.enforcement.exemption.account.action property value specified in the enRole.properties file.
You can also plug in your own custom exemption handler. You can implement the com.ibm.itim.policy.dynanalysis.ICorrectEnforcementExemptionHandler Java™ Interface and specify the implementation class name in the correct.enforcement.exemption.account.handler property of the enRole.properties file. For more information about the Java interface and writing your own exemption handler, see the API documentation.
Alert
Notifies the user about a disallowed account or value.
Use Global Enforcement Action: Mark
Uses the current global enforcement action for a noncompliant account value.

Policy enforcement alerts

Policy enforcement alerts notify a dedicated user about security compliance violations so that they can correct them. When an account becomes noncompliant, the person designated in the compliance alert configuration is notified. To make a noncompliant account compliant, a service owner can then create a compliance process for Identity Manager to bring the account back into compliance.

Depending on the privilege rules defined on the account attributes, accounts are considered noncompliant when users:
  • Possess account privileges for reasons that are no longer valid.

    In this situation, you must revoke the privileges to make the accounts compliant. When privileges are revoked, you must define a compliance process for policy enforcement. When the policy enforcement action is set as Alert, the compliance alert process is triggered.

  • Do not possess account privileges that they must have.

    In this situation, you must grant privileges to these users to make the accounts compliant. If an account is noncompliant because additional privileges are needed, those privileges are granted automatically.

When you define a compliance process to enforce a policy, the noncompliant accounts are flagged. Separate compliance alert items are generated for each privilege to be revoked for each account. For example, if an account has two groups that violate the provisioning policies, you address these two groups separately. You can remove one group while you can add a policy to the other group to make it compliant. Different people can perform these corrective actions at different times.

Two types of operations can trigger policy enforcement:
  • System-triggered operations, also called indirect operations. They include service reconciliation, policy change, and identity change operations.
  • Manually triggered operations, also called direct operations. They include the operations performed directly or manually on an account.
The following actions might trigger a policy enforcement action:
  • Changing a policy.
  • Performing a service reconciliation.
  • Changing an identity in the user interface or through an identity feed. You can revoke privileges through dynamic role changes or entitlement parameter recalculation based on identity information.
  • Adding a role to a user.
  • Removing a role from a user.
  • Changing the definition for a dynamic role.
  • Manually modifying an account.

The following table shows the default compliance alert settings.

Table 1. Default compliance alert settings
Operation type Check box status Required changes Action taken for Account state Request state
Granting changes Revoking changes
System-triggered Checked Granting Added - Compliant Success
Revoking - Alerted Noncompliant #
Both Added Alerted Noncompliant #
None - - Compliant Success
UNCHECKED** Granting Added - Compliant Success
Revoking - Removed Compliant Success
Both Added Removed Compliant Success
None - - Compliant Success
Manually triggered Checked Granting Alerted - Noncompliant #
Revoking - Alerted Noncompliant #
Both Alerted Alerted Noncompliant #
None - - Compliant Success
UNCHECKED** Granting Exception* - Same as previous state Failed
Revoking - Exception* Same as previous state Failed
Both Exception* Exception* Same as previous state Failed
None - - Compliant Success
Notes:
  • * Generates the workflow exception CREATE_ACCOUNT_IS_DISALLOWED.
  • ** UNCHECKED results in the same behavior as selecting Correct as the enforcement action.
  • # The request remains in the Pending state until the compliance process completes.

Compliance alerts

When a change to an account causes privileges to be revoked, the system can generate a compliance alert and send it to a designated user. The Compliance Alert To Do item in the compliance alert contains information about the noncompliant account. The recipient of the alert can either accept or reject some or all of the changes to this account.