Differences

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

Link to this comparison view

Next revision 		Previous revision
devel:documentation:adm:uniform_password [2021/03/23 13:08]
svandav created 		devel:documentation:adm:uniform_password [2021/09/09 07:20] (current)
svandav
Line 1: Line 1:
 ====== Uniform password for new accounts ====== ====== Uniform password for new accounts ======
 {{tag>uniform password common account create}} {{tag>uniform password common account create}}
-The main goal of a uniform password for new accounts is to ensure that new identities will have the same password in newly created accounts.+(since IdM version **11.0.0**)
  
-This feature solves this scenario:+The main goal of a uniform password for new accounts is to ensure that new identities will have the same password in newly created accounts.
  
 +**This feature solves this scenario:**
    - Let's have the **synchronization of new identities**. This synchronization will create new **identity I**.    - Let's have the **synchronization of new identities**. This synchronization will create new **identity I**.
    - This synchronization is followed by the **synchronization of contracts**, which creates 2 **new contracts C1, C2** for identity **I**.    - This synchronization is followed by the **synchronization of contracts**, which creates 2 **new contracts C1, C2** for identity **I**.
Line 10: Line 11:
    - **An attribute automatic role** will be linked to contract **C2**, which will create an **A2 account** on the S2 system according to the contract's attribute.    - **An attribute automatic role** will be linked to contract **C2**, which will create an **A2 account** on the S2 system according to the contract's attribute.
  
 +**Without the use of the uniform password feature**, after the completion of the mentioned scenario, ie. After completing the synchronization of contracts (automatic role recalculation), two new accounts **A1** and **A2** are created, each of which will contain a **different password**. The user will receive **two notifications** of the creation of a new account for each account separately.
  
 +**If you use the uniform password feature**, two accounts will also be created, but both will have the **same password**. The user will recevie only **one notification** about the creation of an account on systems S1 and S2.
 +
 +===== How can be this feature enabled? =====
 +**To ensure the same password** for all new identity accounts created during synchronization, the systems on which we want to have the same password **must be defined in the uniform password agenda**.
 +
 +<note tip>**That means:** In the example above, we must ensure that systems **S1** and **S2** will be in the same active group of the uniform password.</note>
 +
 +This feature is active only during contract sync and for contracts where a identity state is changed:
 +
 +  * **from** state: **Created** or **No contract** or **Left**
 +
 +  * **to** state: **Valid** or **Future contract**.
 +
 +{{ :devel:documentation:adm:uniformpwd01.png?800 |}}
 +
 +{{ :devel:documentation:adm:uniformpwd02.png?800 |}}
 +
 +<note tip>**This feature can be disabled** by **disabling** the **IdentityInitUniformPasswordProcessor** initialization processor. This processor creates states of uniform password entities. Therefore, if you deactivate this processor, the entire uniform password feature will also be **deactivated**.</note>
 +
 +===== How to change password also in IdM? =====
 +
 +For use same uniform password on systems and **in the IdM**, you have to enable this feature by the checkbox **"Change password through IdM"** on the **uniform password detail**.
 +
 +{{ :devel:documentation:adm:uniformpwd03.png?800 |}}
 +
 +===== How this feature works? =====
 +
 +There is life cycle of this feature:
 +
 +   - **Contract synchronization is started** with a new transaction ID.
 +   - After the synchronization of contracts, the recalculation of **HR processes is started**.
 +   - Newly created contracts will cause a change of identity status (for example from **Created** to **Future contract**). This change will be caught in the **IdentityInitUniformPasswordProcessor** processor, which will create a new entity state with the code `IDENTITY_UNIFORM_PASSWORD` (**uniformPasswordManager.createEntityState(identity)**). This status will be followed by the generated uniform password, which will be stored in confidential storage.
 +   - After the recalculation of HR processes is completed, the recalculation of automatic roles will start. Automatic roles will be assigned to contracts and account management will begin, starting the account creation process.
 +   - As part of the account creation, it will be detected that there is an **entity state** for the given identity with the code `IDENTITY_UNIFORM_PASSWORD`. In this case, the account will **not generate a new password, but will use the password from the given entity state**.
 +   - Once the account is created, the `ProvisioningUniformPasswordNotificationProcessor` will ensure that the **system name** is added to the entity state. This system name will then be used in the final **notification**.
 +   - **After the end of the whole transaction** (the end of all connected events), the LRT will be notified, ensuring the synchronization of the end. The LRT begins the **uniform password end process** (**uniformPasswordManager.endUniformPasswordProcess(transactionId)**). Ie. that it sends a **notification** (to the topic `TOPIC_UNIFORM_PASSWORD_SET`) to all identities for which an entity state has been created within the given transaction, about the generation of new accounts on the given systems and a uniform password.
 +   - After all notification is sent will be **all entity states** with code `IDENTITY_UNIFORM_PASSWORD` and created in given transaction **deleted**.
  
 ===== Future improvements ===== ===== Future improvements =====
-<note tip >The manually created delegation definition should be deleted after deleting the last link to the task.</note> +<note tip >**Support the use of the same transaction ID in dependent LRTs**. This will allow HR and automatic recalculations to be used as dependent tasks.</note>
-<note tip >After reassigning the task, also send a notification to the delegator.</note>+
  
 ===== Limitations ===== ===== Limitations =====
  
-<note important>By default (in standard process for **change permissions**), the rule is that if the logged-in user is the implementer of the request (the one who submitted it) and at the same time is one of approvers, then this task is **skipped** (approval is assumed). However, **this rule does not apply in the case of delegation** (ie if the delegate is both the approver and the implementer, the task will be created and assigned).+<note important> 
 +**The uniform password feature works only under one transaction ID.** It means you have to use recalculation of HR processes and automatic roles directly on the contract sync (checkboxes). **Using depending tasks is not supported yet.**
 </note> </note>
- 
-<note important>If one approval task is delegated more than once, or for more approvers, then **only the last delegation's business card** is displayed in the task detail.</note> 
- 
-<note important>**Delegation works only on first level**. So if user **A** delegates to user **B**, and at same time user **B** delegates to user **C**, then it doesn't mean that all tasks from **A** are now delegated to user **C**!</note> 
  
 ===== Main guide ===== ===== Main guide =====
-  * [[..:delegation|]]+  * [[..:uniform_password|]]
  
  • by svandav