Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision | Next revision Both sides next revision | ||
devel:documentation:identities [2020/02/25 21:29] tomiskar [Identity state] |
devel:documentation:identities [2020/03/22 20:36] poulm grammar |
||
---|---|---|---|
Line 1: | Line 1: | ||
<- .:start | Documentation ^ .:start | Documentation ^ .:roles | Roles -> | <- .:start | Documentation ^ .:start | Documentation ^ .:roles | Roles -> | ||
====== Identities (users) ====== | ====== Identities (users) ====== | ||
- | In identity management | + | In identity management, identity is a set of information |
{{ : | {{ : | ||
- | 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 | + | The representation of a user in the 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. Identity |
{{ : | {{ : | ||
Line 16: | Line 16: | ||
* **contract/ | * **contract/ | ||
* etc. | * etc. | ||
- | A user can have multiple contracts. A contract is in relation | + | A user can have multiple contracts. A contract is in relation |
* **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 have one automatically prepared contract called **Default**. (This can be disabled but is enabled by 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> | + | <note important> |
===== Identity state ===== | ===== Identity state ===== | ||
- | Identity | + | The identity |
Identity states: | Identity states: | ||
- | * **created** - identity is enabled. | + | * **created** - identity is enabled. |
- | * **no contract** - identity is disabled. Identity doesn' | + | * **no contract** - identity is disabled. Identity doesn' |
- | * **future contract** - identity is disabled. Identity has valid contract in the future, but not now. | + | * **future contract** - identity is disabled. Identity has a valid contract in the future, but not now. |
* **valid** - identity is enabled. Identity has a valid contract. | * **valid** - identity is enabled. Identity has a valid contract. | ||
* **left** - identity is disabled. Identity has invalid contracts only. | * **left** - identity is disabled. Identity has invalid contracts only. | ||
- | * **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. | + | * **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 again only manually (assigned roles are not removed, when identity is disabled manually). | + | * **disabled manually** - identity is disabled manually, e.g. by administrator/ |
- | 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: | + | When 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 the new password is [[.architecture: |
===== Identity profile ===== | ===== Identity profile ===== | ||
- | Identity profile can be shown from top menu - click on identity username, then select user setting. | + | Identity profile can be shown from the top menu - click on identity username, then select user setting. |
Identity profile contains configurable properties: | Identity profile contains configurable properties: | ||
* **Profile image** - user picture. | * **Profile image** - user picture. | ||
- | * **Prefered language** - localization will be choosed | + | * **Prefered language** - localization will be chosen |
- | * **Default page size** - tables will show given count of records by default. | + | * **Default page size** - tables will show a given count of records by default. |
* **Collapse side menu** - side menu will be collapsed, icons will be shown only. | * **Collapse side menu** - side menu will be collapsed, icons will be shown only. | ||
- | * **Show system information** - show internal entity identifiers, | + | * **Show system information** - show internal entity identifiers, |
{{ : | {{ : | ||
Line 55: | Line 55: | ||
===== Password ===== | ===== Password ===== | ||
- | In CzechIdM, user password is stored in Bcrypt hash function. User can change password only when he or she has permission '' | + | In CzechIdM, |
Line 61: | Line 61: | ||
{{tag> | {{tag> | ||
- | 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 slices, an agenda of contract' | + | 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 slices, an agenda of 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). | **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> | + | <note important> |
**More information** about contract time slices can be found in the developer guide [[..: | **More information** about contract time slices can be found in the developer guide [[..: | ||
Line 72: | Line 72: | ||
{{tag> | {{tag> | ||
- | 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. | + | 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**, | + | However, in some situations (projects), it is required to use the **protection period** for which the contract will **not be terminated**, |
**More information** about this protection can be found in the developer guide [[..: | **More information** about this protection can be found in the developer guide [[..: |