You are viewing the documentation for an outdated or unreleased devel version.
This page is also available in versions: 7.6, 7.7, 7.8, 8.0, 8.1, 9.0, 9.1, 9.2, 9.3, 9.4, 9.5, 9.7 (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:documentation:identities [2019/06/25 08:48]
tomiskar [Identity state]
devel:documentation:identities [2019/08/14 12:20] (current)
doischert
Line 5: Line 5:
 {{ :​devel:​documentation:​identity.png?​400 | Identity in identity management}} {{ :​devel:​documentation:​identity.png?​400 | Identity in identity management}}
  
-The representation of a user in CzechIdM system is an entity called **identity**. Put simply, an identity can be described as a user registered in CzechIdM with all his attributes e.g. first name, surname, phone number, etc. The identity representation is rather complex discipline. To be able to handle automatic identity lifecycle processes CzechIdM ​presents ​other entities with attributes that have a relation to an identity. Those are **[[.:​identities#​contracts|Contracts]],​ [[.:​roles|Roles]]** ​ and **Tree nodes** forming **[[.:​tree_structures| Tree strucures]]**.+The representation of a user in CzechIdM system is an entity called **identity**. Put simply, an identity can be described as a user registered in CzechIdM with all his or her attributes e.g. first name, surname, phone number, etc. The identity representation is rather complex discipline. To be able to handle automatic identity lifecycle processesCzechIdM ​uses other entities with attributes that have a relation to an identity. Those are **[[.:​identities#​contracts|Contracts]],​ [[.:​roles|Roles]]** ​ and **Tree nodes** forming **[[.:​tree_structures| Tree strucures]]**.
  
 {{ :​devel:​adm:​idm_entities.png?​800 | Entities relations}} {{ :​devel:​adm:​idm_entities.png?​800 | Entities relations}}
Line 11: Line 11:
 ===== Contracts ===== ===== Contracts =====
  
-The relation of identities in CzechIdM ​with a company or organization is represented by an entity called **contract**. A contract can be imagined as:+The relation of identities in CzechIdM ​to a company or organization is represented by an entity called **contract**. A contract can represent for example:
   * **job contract** for work – employees   * **job contract** for work – employees
   * **study** – pupils/​students   * **study** – pupils/​students
   * **contract/​arrangement** – external co-workers   * **contract/​arrangement** – external co-workers
   * etc.   * etc.
-A user can have many contracts. A contract is in relation with other objects in CzechIdM:+A user can have multiple ​contracts. A contract is in relation with other objects in CzechIdM:
   * **Identity** – described above   * **Identity** – described above
   * **Tree structure** – a contract can be added to a tree (organizational) structure, which effectively allows integrating the user into a hierarchical division in an organization.   * **Tree structure** – a contract can be added to a tree (organizational) structure, which effectively allows integrating the user into a hierarchical division in an organization.
-  * **Roles** – roles in CzechIdM are assigned to contracts, i.e. a user gets roles through their contracts. Due to this, all manually created identities can (application option) ​have one automatically prepared contract called **Default**.+  * **Roles** – roles in CzechIdM are assigned to contracts, i.e. a user gets roles through their contracts. Due to this, all manually created identities can have one automatically prepared contract called **Default**. ​(This can be disabled but is enabled by default.)
  
 <note important>​Every active user should have their contract. Via contracts Roles are assigned to users and users are placed into Tree structure (working position)</​note>​ <note important>​Every active user should have their contract. Via contracts Roles are assigned to users and users are placed into Tree structure (working position)</​note>​
Line 25: Line 25:
 ===== Identity state ===== ===== Identity state =====
  
-Identity life cycle is controlled by state. State is changed automatically by system - when identity is created, contract to identity is added or removed etc.+Identity life cycle is controlled by identity'​s ​state. State is changed automatically by system - when an identity is created, ​a default ​contract to the identity is added.
  
 Identity states: Identity states:
-  * **created** - identity is enabled. State is assigned to newly created identity.+  * **created** - identity is enabled. State is assigned to newly created identity.
   * **no contract** - identity is disabled. Identity doesn'​t have a contract. All contract were deleted. ​   * **no contract** - identity is disabled. Identity doesn'​t have a contract. All contract were deleted. ​
   * **future contract** - identity is disabled. Identity has valid contract in the future, but not now.   * **future contract** - identity is disabled. Identity has valid contract in the future, but not now.
-  * **valid** - identity is enabled. Identity has valid contract.+  * **valid** - identity is enabled. Identity has valid contract.
   * **left** - identity is disabled. Identity has invalid contracts only.   * **left** - identity is disabled. Identity has invalid contracts only.
-  * **excluded** (~disabled) - identity is exclued ​(disabled). Identity contracts are excluded (assigned roles are not removed, when identity is excluded).  +  * **excluded** (~disabled) - identity is excluded ​(disabled). Identity contracts are excluded (assigned roles are not removed, when identity is excluded). This is usually used when the user has parental leave
-  * **disabled manually** - identity is disabled manually, e.g. by administrator / synchronization. Manually disabled identity can be enabled ​manually only again (assigned roles are not removed, when identity is disabled manually). ​+  * **disabled manually** - identity is disabled manually, e.g. by administrator / synchronization. Manually disabled identity can be enabled again only manually ​(assigned roles are not removed, when identity is disabled manually). ​
  
-When identity ​starts to be valid (some of their contract starts to be valid) and identity has account at least on one target system, then new password is [[.architecture:​dev:​events#​identitysetpasswordprocessor|generated]] and changed on all identity'​s accounts => identity will have the same password in all accounts. Notification (see ''​acc:​newPasswordAllSystems''​ template) is send to identity about new password on which accounts were changed.+When an identity ​becomes ​valid (i. e., at least one of their contracts becomes ​valid) and the identity has an account ​on at least one target system, then new password is [[.architecture:​dev:​events#​identitysetpasswordprocessor|generated]] and changed on all identity'​s accounts => identity will have the same password in all accounts. Notification (see ''​acc:​newPasswordAllSystems''​ template) is sent to identity about which of their accounts were changed.
  
 ===== Password ===== ===== Password =====
  
-In CzechIdM ​is user password stored in Bcrypt hash function. User can change password only when own permission ''​IDENTITY\_PASSWORDCHANGE''​ for the given identity. Password contains also another ​metadata like valid till, valid from, unsuccessful attempts, block login date, last successful login and etc. For password ​is also possible set flag **Password never expires**. This flag disable ​filling valid till. Password never expires and another ​attributes ​for password like valid till, is possible ​set via agenda information about password that is accessible ​via identity detail ​and password agenda. ​For update these attributes you will need permission ''​PASSWORD\_UPDATE''​ and ''​PASSWORD\_READ''​+In CzechIdMuser password ​is stored in Bcrypt hash function. User can change password only when he or she has permission ''​IDENTITY\_PASSWORDCHANGE''​ for the given identity. Password contains also other metadata like valid till, valid from, unsuccessful attempts, block login date, last successful login etc. It is also possible ​to set flag **Password never expires**. This flag disables ​filling ​'valid till''Password never expires' ​and other attributes ​related to password like 'valid till' can be set via agenda information about password that is accessible ​through ​identity detail ​or password agenda. ​To update these attributes you will need permission ''​PASSWORD\_UPDATE''​ and ''​PASSWORD\_READ''​.
  
  
Line 46: Line 46:
 {{tag>​contract slice}} {{tag>​contract slice}}
  
-On many projects, we encounter a source of data about users, employees or org. structures that work with so-called time slices. ​For better works with this time slots, agenda of contract'​s time slices was created.+On many projects, we encounter a source of data about users, employees or org. structures that use so-called time slices. ​Slice is essentially a snapshot of a contract in a given period of time. To simplify working ​with time slicesan agenda of contract'​s time slices was created.
  
-**The basic idea** is that time slices are stored in a self-contained agenda. This agenda only contains time slices for identity contracts. If a given slice is currently valid, its values will be **copied into the linked identity contract**. **Every day** a scheduled task is performed, which calculates ​whether another ​slice is valid. Such a slice becomes currently used as a contract (its values are copied into the contract).+**The basic idea** is that time slices are stored in a self-contained agenda. This agenda only contains time slices for identity contracts. If a given slice is currently valid, its values will be **copied into the linked identity contract**. **Every day**a scheduled task is performed, which calculates ​which slice is valid. Such a slice becomes currently used as a contract (its values are copied into the contract).
  
-<note important>​In one day can exists ​only **one slice** for one contract. Every slice must contains all data of the contract. Slice is **snapshot** of the contract! </​note>​+<note important>​In one dayonly **one slice** ​can exist for one contract. Every slice must contains all data of the contract. Slice is **snapshot** of the contract! </​note>​
  
-**More information** about contract time slices ​you can find in the develop ​guide [[..:​documentation:​identities:​dev:​contractual-relationship-slice|here]] .+**More information** about contract time slices can be found in the developer ​guide [[..:​documentation:​identities:​dev:​contractual-relationship-slice|here]] .
  
-==== Protection of the contract ​validity ====+==== Protection of the validity ​of the contract ​====
 {{tag>​contract slice protection}} {{tag>​contract slice protection}}
  
-Sometimes there may be a situation where one of the time slices **ends** the contract, and at the same time there is a next time slice that **restarts** this contract. If there is no gap between termination and restart, then the contract will not terminate ​(no accounts will be deleted). If the dates do not follow, then (by default) will be **contract ​terminated** and all connected **accounts will be removed** from the target systems.+Sometimes there may be a situation where one of the time slices **ends** the contract, and at the same time there is a next time slice that **restarts** this contract. If there is no gap between termination and restart, then the contract will not be terminated ​(no accounts will be deleted). If the dates do not follow, then (by default) ​the contract ​will be **terminated** and all connected **accounts will be removed** from the target systems.
  
-However, in some situations (projects), it is required to use the **protection period** for which the contract will **not be terminated**,​ provided that there is a next slice in the contract, which restarts the contract. Furthermore must be ensured that the gap between the termination and the beginning of the contract is less than or equal to the protection interval.+However, in some situations (projects), it is required to use the **protection period** for which the contract will **not be terminated**,​ provided that there is a next slice in the contract, which restarts the contract. Furthermore, it must be ensured that the gap between the termination and the beginning of the contract is shorter ​than or equal to the protection interval.
  
-**More information** about this protection ​you can find in the develop ​guide [[..:​documentation:​identities:​dev:​contractual-relationship-slice#​protection_of_the_contract_validity|here]] .+**More information** about this protection can be found in the developer ​guide [[..:​documentation:​identities:​dev:​contractual-relationship-slice#​protection_of_the_contract_validity|here]] .
 ====== Read more ====== ====== Read more ======