Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
devel:documentation:identities [2019/02/01 11:44] kotisovam admin guide |
devel:documentation:identities [2020/03/26 09:50] (current) tomiskar [Admin guide] |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | <- .:start | Documentation ^ .:start | Documentation ^ .:roles | Roles -> | + | <- .:start | Documentation ^ .:start | Documentation ^ .:contracts |
====== 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 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 |
{{ : | {{ : | ||
- | ===== Contracts | + | ===== Password |
- | The relation of identities in CzechIdM | + | In CzechIdM, the user password |
- | * **job contract** | + | |
- | | + | |
- | * **contract/ | + | |
- | * etc. | + | |
- | A user can have many contracts. A contract is in relation with other objects in CzechIdM: | + | |
- | * **Identity** – described above | + | |
- | * **Tree structure** – a contract | + | |
- | * **Roles** – roles in CzechIdM are assigned to contracts, i.e. a user gets roles through | + | |
- | <note important> | ||
- | |||
- | ===== 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 states: | ||
- | * **created** - identity is enabled. State is assigned to newly created identity. | ||
- | * **no contract** - identity is disabled. Identity doesn' | ||
- | * **future contract** - identity is disabled. Identity has valid contract in the future, but not now. | ||
- | * **valid** - identity is enabled. Identity has valid contract. | ||
- | * **left** - identity is disabled. Identity has invalid contracts only. | ||
- | * **disabled** - identity is disabled. Identity contracts are excluded. | ||
- | * **disabled manually** - identity is disabled manually, e.g. by administrator / synchronization. Manually disabled identity can be enabled manually only again. | ||
- | |||
- | 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: | ||
- | |||
- | ====== Time slices of contracts ====== | ||
- | {{tag> | ||
- | |||
- | 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' | ||
- | |||
- | **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). | ||
- | |||
- | <note important> | ||
- | |||
- | **More information** about contract time slices you can find in the develop guide [[..: | ||
- | |||
- | ==== Protection of the contract validity ==== | ||
- | {{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 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. | ||
- | |||
- | 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 you can find in the develop guide [[..: | ||
====== Read more ====== | ====== Read more ====== | ||
Line 62: | Line 18: | ||
* [[tutorial: | * [[tutorial: | ||
* [[tutorial: | * [[tutorial: | ||
- | * [[tutorial: | ||
- | * [[tutorial: | ||
===== Admin guide ===== | ===== Admin guide ===== | ||
- | * [[.identities: | + | * [[.identities: |
+ | * [[.identities: | ||
+ | * [[.identities: | ||
+ | * [[.identities: | ||
+ | * [[.identities: | ||
- | ===== Devel guide ===== | ||
- | * [[..: | ||
- | * [[..: |