This is a sample scenario, as covered by TestPolicyDrivenRoleLifecycle class.
Imagine we have the constraints for a role to be met:
|C1||Each role must have a risk level.|
|C2||Each role with risk level of high must have a description.|
|C3||Each role must have an approver. High-risk roles must have at least 2 approvers.|
|C4||Each role must have an owner.|
|C5||Each role must have an identifier.|
Then there are the following rules:
|R1||No role that does not meet C1-C4 might be activated i.e. switched to lifecycleState of active.|
|R2||Activation of a role must be approved by its owner.|
|R3||Activation of a role without identifier is subject to an approval by Security Administrators|
|R4||Active role without identifier must be recertified regularly by Security Administrator.|
|R5||Validity of an active role without identifier must be limited to 180 days at most.|
|RE1||See all draft roles that do not meet constraints C1-C4.|
|RE2||See all active roles that do not meet constraint C5.|
Rules in action
Let's say we have a role that breaks almost all constraints: has no risk level defined, no approver, no owner, no identifier, no validity set. After trying to activate such role, the following would appear (currently only for preview changes due to implementation limitations):
The message Role test1234 (OID bbb0d3aa-0b2f-4710-80e0-11360c423c37) requires at least 1 assignees with the relation of 'owner' is intentionally different from the others. It is present just to show how default constraint messages look like, in comparison with custom ones.
Policy rules used
This is how it could be implemented.