Skip to end of metadata
Go to start of metadata

Introduction

Activation part of resource object type definition is located in Resource Schema Handling part of resource definition. The activation part defines how the resource object is activated, i.e. whether it should or should not exist, whether it should be enabled, disabled or archived, etc. This part can be used to fine-tune activation and de-activation policies. E.g. it can be used to specify whether account should be deleted or disabled when it is unassigned from the user.

The activation part of resource object definition has three parts: existence mapping, administrative status mapping and validity mappings.

Existence Mapping

Existence mapping determines whether the resource object should exist or not. If activation mapping returns true then the resource object will exist (will be kept as it is or created). If it returns false the resource object will not exist (will not be created or will be deleted).

The existence mapping usually uses the concept of legality. The legality is determined by evaluating assignments and the assignment enforcement mode. The result of such evaluation is provided as input to the existence mapping. Therefore simple asIs expression is all that is usually needed:

asIs existence mapping

The mapping above will return true if the resource object is legal. Therefore such object will exist. It returns false if the object is not legal (e.g. there is no assignment for in in FULL assignment enforcement mode). Therefore such object will be deleted. This is also the default mapping that will be assumed in case there is no explicit existence mapping specified.

Note that a similar variable is called assigned. It is true if and only if there is a valid assignment for this resource object.

In FULL assignment enforcement mode, assigned is alwas the same as input (legal). In other enforcement modes, they can be different. E.g. in RELATIVE mode, a resource object may be legal even if it is not assigned.

VariableTypeDescription
inputbooleanlegality: set to true if the object is legal (based on assignment evaluation and enforcement mode). See Assignment
assignedbooleanTrue if there is a valid assignment for this object.
focusExistsbooleanSpecifies whether the focal object (e.g. user) to which the resource object is linked exists. Set to true if the resource object is linked to an existing focal object.
focusFocusTypeContains the complete focal object (e.g. user)
shadowShadowTypeContains a shadow for which is the existence evaluated (may not be present if not yet created)

Although the existence mapping may technicaly have inbound part as well such part is never used.

Administrative Status Mapping

Administrative status mapping maps activation administrative status from the focal object (user) to the administrative status of resource object.

administrativeStatus mapping
VariableTypeDescription
inputActivationStatusType"Magic" computed status that is most suitable for the account. It is either an administrativeStatus if the resource supports validity time constraints (validFrom, validTo) or it is effectiveStatus if the resource does not. In the later case this effectively simulates the validity time constraints using just the activation status.
administrativeStatusActivationStatusType

$focus/activation/administrativeStatus

This may be used to avoid the "magic" computation in the input variable and compute the output in a custom way.

legalbooleanlegality: set to true if the object is legal (based on assignment evaluation). See Assignment
assignedbooleanTrue if there is a valid assignment for this object.
focusExistsbooleanSpecifies whether the focal object (e.g. user) to which the resource object is linked exists. Set to true if the resource object is linked to an existing focal object.
focusFocusTypeContains the complete focal object (e.g. user)

Validity Mappings

TODO

Examples

Delete on Unassign

This is the default configuration. It uses only asIs mappings.

Disable on Unassign

This configuration does not delete accounts when they are unassigned. It disables them instead. This is achieved by a combination of existence and administrative status mappings. In case of unsassigned account the existence mapping returns true which causes that the account is not going to be deleted even if it is not legal. The administrative status mapping takes care of disabling that account. It causes that all legal accounts will have the same activation administrative status as the user that they are linked to. On the other hand all the illegal or unassigned accounts will have DISABLED status.

The use of focusExists variable in the existence mapping causes that the account will be deleted when a linked user is deleted. It may be changed to a fixed true value if the account should stay there even after the user is deleted.

Mapping Time Constraints

The Mapping can optionally have a time constraints. The time constraints means that the mapping will only be evaluated if certain time constraints are satisfied. E.g. a mapping that is only evaluated 30 days after the account is disabled.

The time constraints are very useful especially in the activation part of schemaHandling definition. Mapping time constraints can be used to have midpoint do quite a lot of time-related tricks. E.g. following set of existence mappings will cause that accounts that are disabled for more than one month will be deleted.

Similar mapping time constraints can be used with a negative offset to make something happen before a specific date. E.g. the following mapping will pre-provision a disabled account 5 days before user's validFrom date.

 

See Also

  • No labels