Pre-validity and post-validity
If RoPE calculates a CRA and the current time is outside the validity period of the CRA, that is, before the validity period starts or after the validity period ends, the CRA is normally disregarded, so that it is not included in the calculation result.
However, RoPE has a concept of Pre-validity and Post-validity. RoPE includes a CRA in the calculation result a number of days before it becomes valid and a number of days after it stops being valid, but it is marked as disabled.
This allows for provisioning account assignments before a user's start date, and mitigation of incorrect HR termination triggers. It also ensures that accounts are not deleted on the last working day of an identity.
If it is the identity itself that is either pre-valid or post-valid, RoPE will extend the validity period of Calculated Permission Resource Assignments (CPRA). In the extended period before and after the validity period, the identity is not marked as disabled. This is to prevent the permission assignments from being deprovisioned and to allow that permissions can get provisioned during the pre-validity period. This is safe to do since the accounts for which the permissions are granted will always be disabled.
The pre-validity period is by default three (3) days for all CRAs of all types. It can be configured in the customer settings, as shown below (path: Setup > Administration > More > Customer settings).
The post-validity is by default zero (0) days. It can be configured per resource type in the Edit Resource Type dialog, as shown below. If you do not enter any value in the field, it is interpreted as zero.
Pre-validity and post-validity scenarios
The pre- and post-validity functionality makes it possible to extend the validity periods for account assignments (CARAs) and permission assignments (CPRAs). Account assignments can be provisioned in a disabled state outside the validity period of the identity, and permission assignments can remain provisioned beyond the validity period of the identity.
This means that accounts can be provisioned for a given identity a set number of days before the identity is enabled, and that permissions are not deprovisioned for a set number of days after the identity is disabled or locked.
The timeline below illustrates an example of the pre-validity and post-validity periods.
Pre-validity
Pre-validity allows the AD Account assignment to be created before the date on which the identity and account become active. During this pre-validity period, the assignment is disabled and becomes active on the valid from date. At the same time, the calculated permission assignment for the AD Group can only be provisioned after the identity is enabled.
Post-validity
In the case of post-validity, the AD Account assignment is disabled at the same moment the identity is disabled or locked, unless another assignment reason with post-validity keeps the account provisioned. However, the CPRA for the AD Groups is not disabled, and this permission assignment is deprovisioned at the end of the post-validity period.
Account assignments (CARAs) do not independently respect the account type post-validity setting.
A CARA will remain provisioned beyond the identity's validity period only if there is another assignment reason (such as a permission, role, or policy) that depends on the account and has post-validity configured.
When that permission or other assignment reason exits its post-validity window, both the CPRA and the CARA are then deprovisioned.