You are viewing the documentation for an outdated or unreleased devel version.
This page is also available in versions: 7.4, 7.5, 7.6, 7.7, 7.8, 8.0, 8.1, 9.0, 9.1, 9.2, 9.3, 9.4, 9.5 (current), devel

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
devel:adm:identity_processes [2017/12/11 15:43]
poulm added events in 7.6 version 		devel:adm:identity_processes [2017/12/11 15:53] (current)
poulm moved to documentation
Line 1: Line 1:
 <- .:​scheduled_tasks | Long running tasks ^ .:start | Administrator'​s guide ^ .:audit | Audit -> <- .:​scheduled_tasks | Long running tasks ^ .:start | Administrator'​s guide ^ .:audit | Audit ->
  
-====== Identity lifecycle processes ====== +<note important>​Moved to [[devel:documentation:hr_processes|]]</note>
- +
- +
-Process of identity lifecycle (ILP) in other words HR process manages the user identity in CzechIdM during its existence watching the changes on its contracted positions. For example there is a process "End of contract"​ that watches the beginning and end of the user contracted position. If the contracted position ends, the process removes all user roles from it. +
- +
-===== Standard ILPs ===== +
- +
-Following text describes the core set of HR processes solved by CzechIdM. All processes are managed based on the contracted position attributes. There are following attributes that the processes watches for a change: +
- +
-  * Valid from +
-  * Valid to +
-  * Enabled +
-  * Position +
- +
-Valid from and valid to attributes defines contracted position **validity**,​ i.e. The contracted position **is valid** if and only if current date is between or equal **valid from** and **valid to**. We use the term contracted position **validity** in following text. +
- +
-If you want to use ILPs, you must synchronize contracted positions from source system with attributes mentioned above or manage them manually. +
- +
-<note important>​Since 7.6 version has been released, following processes are managed by events. i.e immediately after the Watched attribute is changed, Effect take place. e.g. when administrator change the employee'​s last Contract end date to past, roles are removed and identity is blocked. There is no need to wait for Scheduled task run. Scheduled task are still available though to be to upgrade from older versions. </​note>​ +
- +
-==== Enabled contract ==== +
- +
-  * **Watched entity**: contracted position, +
-  * **Watched attributes**:​ valid from, valid to, enabled, +
-  * **Process trigger**: The identity'​s contracted position becomes valid and enabled, +
-  * **Effect**: identity that belong to the changed contracted position is enabled. +
- +
-The process is a stateful task, therefore the contracted position is processed only once until it is set not valid again. +
- +
-==== End of contract ==== +
- +
-  * **Watched entity**: contracted position, +
-  * **Watched attributes**:​ valid from, valid to, +
-  * **Process trigger**: The identity'​s contracted position becomes not valid, +
-  * **Effect**: All manually added roles are removed from ended contract. Additionally if the ended contract was the last valid contract of the identity, the identity itself is disabled. +
- +
-The process is a stateful task, therefore the contracted position is processed only once until it is set valid again. +
- +
-==== Contract exclusion ==== +
- +
-  * **Watched entity**: contracted position, +
-  * **Watched attributes**:​ valid from, valid to, enabled +
-  * **Process trigger**: The identity'​s contracted position becomes valid and not enabled +
-  * **Effect**: If the processed contract was the last valid contracted position of the identity, the whole identity is disabled. No roles are removed by the process. +
- +
-The process is a stateful task, therefore the contract is processed only once until it is enabled again. End of contracted position exclusion is managed by **Enabled contract** process. +
- +
-==== Work position assignment/​change/​removal ==== +
-In fact this is not full-blooded identity lifecycle process, because it is not managed by any special long running task, workflow or by other means. It just uses standard CzechIdM feature - [[devel:adm:roles#​automatic_roles|automatic roles]]. But since those processes are often looked on HR process from the business point of view, we describe them here. +
- +
-  * **Watched entity**: contracted position, +
-  * **Watched attributes**:​ position +
-  * **Process trigger**: The identity'​s contracted position is placed into/removed from organization structure (Tree structure). +
-  * **Effect**: Automatic roles defined on the Tree structure are assigned in case of placing the contracted position there or removed in case of removing the contracted position from the structure. Automatic roles are not passed for role a assignment approval, they are assigned immediately. +
- +
-If the contract is not valid yet, all automatic roles are assigned anyway, but each role's assignment validity date (do not mistaken with role validity) is tied to the contracts validity. In other words the effect of the role e.g. the account creation on managed system is done the same day the contracted position begins not sooner.+