Skip to end of metadata
Go to start of metadata

This is a sample scenario, as covered by TestPolicyDrivenRoleLifecycle class.

Imagine we have the constraints for a role to be met:

IdConstraint
C1Each role must have a risk level.
C2Each role with risk level of high must have a description.
C3Each role must have an approver. High-risk roles must have at least 2 approvers.
C4Each role must have an owner.
C5Each role must have an identifier.

Then there are the following rules:

IdRule
R1No role that does not meet C1-C4 might be activated i.e. switched to lifecycleState of active.
R2Activation of a role must be approved by its owner.
R3Activation of a role without identifier is subject to an approval by Security Administrators
R4Active role without identifier must be recertified regularly by Security Administrator.
R5Validity of an active role without identifier must be limited to 180 days at most.

Reports requested:

IdRequirement
RE1See all draft roles that do not meet constraints C1-C4.
RE2See 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.

Policy rules implementing the scenario

Localization properties:

 

 

 

 

  • No labels