Identity Governance
This feature is available if you have purchased the [IGA – Identity Governance] module. Administrators can define custom strategies and rules to enforce fine-grained governance of permissions on the IAM platform, supporting enterprise-level access governance in complex scenarios.
Account Governance
Platform Account Policies
| No. | Anomaly Type | Description |
|---|---|---|
| 1 | Dormant Account | A user account that has not logged in for an extended period. |
| 2 | Empty Account | A user account that is not linked to any application account. |
Supported platform account policy actions:
| No. | Action | Description |
|---|---|---|
| 1 | Notification | Can send alerts (see Policy Management – Notifications). If using email, a valid business email must be maintained in the user profile. |
| 2 | Lock User | Automatically lock user accounts identified by the policy. |
| 3 | Disable User | Automatically disable user accounts identified by the policy. |
| 4 | Delete User | Automatically delete user accounts identified by the policy. |
Note: The
sysadminaccount is excluded when executing the Empty Account Policy.
Application Account Policies
| No. | Anomaly Type | Description |
|---|---|---|
| 1 | Dormant Account | Application accounts with no login activity for an extended period. |
| 2 | Orphan Account | Application accounts not linked to any user. |
| 3 | Duplicate Account | A user associated with multiple application accounts. |
Supported application account policy actions:
| No. | Action | Description |
|---|---|---|
| 1 | Notification | Can send alerts (see Policy Management – Notifications). If using email, ensure the user has a business email set. |
| 2 | Disable Account | Automatically disable accounts identified by the policy. |
| 3 | Delete Account | Automatically delete accounts identified by the policy. |
Retention Strategies for Duplicate Accounts:
- Keep Newest: Retain the account with the latest creation and update time (only if status is Requested or Active). If timestamps are identical, retain both.
- Keep Oldest: Retain the account with the earliest creation and update time (same logic as above).
Permission Governance
The permission governance function provides fine-grained control over user entitlements. It allows defining rules to restrict or validate which permissions a user may hold and supports ongoing permission audits.
Permission Rules
These rules serve as pre-authorization controls, validating permissions before assignment.
| No. | Rule Type | Description |
|---|---|---|
| 1 | Mutual Exclusion | An account cannot be assigned two or more permissions marked as mutually exclusive. |
| 2 | Maximum Compliance | Sets the upper boundary for permissions; exceeding this scope is considered over-privileged. |
| 3 | Minimum Compliance | Sets the lower boundary; falling below this scope is considered non-compliant. |
Actions supported for mutual exclusion rules:
| No. | Use Case | Description |
|---|---|---|
| 1 | Application Permissions | Prompts or blocks assignment of mutually exclusive permissions. |
| 2 | Permission Models | Prompts or blocks mutual exclusivity violations during model configuration. |
Authorization Policies
Authorization policies enforce real-time permission checks during the assignment process. When permissions are granted, the system checks whether the assignment conforms to policy.
Supported actions for authorization policies:
| No. | Use Case | Description |
|---|---|---|
| 1 | Account Management | Prompts or blocks when assigning mutually exclusive permissions. |
| 2 | Application Permissions | Same as above during permission assignment at the application level. |
Policy Priority
Authorization policies can be prioritized. If multiple policies apply to the same user, application, and rule set, the one with the highest priority takes effect.
Validation Policies
Validation policies perform post-assignment audits to detect and correct violations in already-assigned permissions. Only Active personal accounts are evaluated.
Execution Order
Validation policies also support priority settings. When multiple policies apply, they are executed sequentially based on priority. Unlike authorization policies, the last validation policy executed determines the final outcome.
Deprovisioning Policies
Deprovisioning policies allow reclaiming accounts and entitlements from downstream systems back into the IAM platform.
Currently supported sync plugins for deprovisioning:
| No. | Plugin | Description |
|---|---|---|
| 1 | DB Plugin | Only AD and DB plugin applications are supported. Others will have no effect. |
| 2 | AD Plugin | Supports real AD account recovery (details below). |
Currently supported data types for deprovisioning:
| No. | Data Type | Description |
|---|---|---|
| 1 | Application Account | Only AD plugin supports real account recovery. DB plugin performs virtual recovery by inserting records into the ac_user table, enabling recovery execution. See Account – AD Plugin for configuration. |
| 2 | Application Role | Only supported in DB Plugin (virtual). Roles are inserted into the ac_role table. Supports role hierarchies (role-to-role, role-to-resource). These relationships are inserted via the appropriate fields. Important: Contained roles or permissions must be deprovisioned first. Existing permissions in IAM are not supported for recovery. |
| 3 | Application Resource | You can specify which resource types to recover. |