Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
Last revision Both sides next revision
devel:documentation:security:dev:change-user-permissions [2019/01/30 09:21]
svandav [The approval process] 		devel:documentation:security:dev:change-user-permissions [2019/04/05 10:18]
tomiskar
Line 1: Line 1:
 ====== Changing user permissions ====== ====== Changing user permissions ======
  
-{{tag>identity permission role security workflow}}+{{tag>identity permission role request security workflow}}
  
 <note tip>Introduction to the topic - [[../..:role_change|read here]].</note> <note tip>Introduction to the topic - [[../..:role_change|read here]].</note>
-A manual change (via REST api) of permission, i.e. adding/editing/removing a link between an identity and a role is not possible. All permission changes must be made via the role request agenda (RoleRequest).+ 
 +===== Basic life cycle of the request for change a permissions ===== 
 + 
 +{{:devel:documentation:security:dev:role-request.png|}} 
 + 
 +<note important>A manual change (via REST api) of permission, i.e. adding/editing/removing a link between an identity and a role is not possible. All permission changes must be made via the role request agenda (RoleRequest).</note>
  
 ===== Role request agenda ===== ===== Role request agenda =====
Line 25: Line 30:
  
 <note tip>If the user creates a new request but does not submit it, it will be displayed as "**Concept**" in the table "**Unfinished requests for permission change**" in the assigned roles tab. Thus they can return to an unfinished concept.</note> <note tip>If the user creates a new request but does not submit it, it will be displayed as "**Concept**" in the table "**Unfinished requests for permission change**" in the assigned roles tab. Thus they can return to an unfinished concept.</note>
- 
-{{:navrh:selection_060.png|}} 
- 
  
 === Concept table === === Concept table ===
Line 38: Line 40:
  
 <note important>The request can be submitted only when the request is in the "**CONCEPT**", "**DUPLICATED**" or "**EXCEPTION**" states</note> <note important>The request can be submitted only when the request is in the "**CONCEPT**", "**DUPLICATED**" or "**EXCEPTION**" states</note>
- 
-{{:navrh:selection_059.png|}} 
  
 ==== Changing permission without approval ==== ==== Changing permission without approval ====
Line 78: Line 78:
  
 The agenda allows a direct request submission from a list of requests. The agenda also allows **creating a new request**, where the administrator must first choose the user who the request is being created for. The agenda allows a direct request submission from a list of requests. The agenda also allows **creating a new request**, where the administrator must first choose the user who the request is being created for.
- 
-{{:navrh:selection_061.png|}} 
  
 In addition, the request detail in this agenda contains (compared to the end user request detail) a possibility of ticking that the request is not to be approved. The request detail also contains a **log**. This log contains all crucial information which occur during the life cycle of the request (errors, duplicates, request cancellation due to integrity, executed operations, etc.). In addition, the request detail in this agenda contains (compared to the end user request detail) a possibility of ticking that the request is not to be approved. The request detail also contains a **log**. This log contains all crucial information which occur during the life cycle of the request (errors, duplicates, request cancellation due to integrity, executed operations, etc.).
- 
-{{:navrh:selection_067.png|}} 
  
 ==== Integrity on remove contract or role ==== ==== Integrity on remove contract or role ====
Line 149: Line 145:
   - **Approval by the user administration department**.   - **Approval by the user administration department**.
   - **Execution of subprocesses for each requested role**.   - **Execution of subprocesses for each requested role**.
 +  - **Approval of role incompatibilities**
   - **Approval by the security department**.   - **Approval by the security department**.
   - **Sending the notification**.   - **Sending the notification**.
Line 212: Line 209:
  
   * **No priority (0)**:   * **No priority (0)**:
-No approval takes place. The process "**change-role-without-approve**" is run (see above).+No approval takes place. The process "**change-role-without-approve**" is run (see above). This process is used, even if no workflow is configured (~is empty) for a priority.
  
   * **Trivial priority (1)**:   * **Trivial priority (1)**:
Line 244: Line 241:
  
 <note important>Approval by the security department is disabled by default</note>. <note important>Approval by the security department is disabled by default</note>.
 +
 +====Approval of role incompatibilities====
 +  * First is checking, if exists in the current request some incompatibilities of roles. Incompatibilities are searche only for new added roles (not disapproved) in the request. If none incompatibilites are found, then is this user task skiped.
 +  * The approving task will be assigned to all users with role **Incompatibility**.
 +  * The role can be changed in the application configuration "**idm.sec.core.wf.approval.incompatibility.role**", the default setting is **Incompatibility**.
 +  * The approval round can be enabled or disabled in the application configuration under key "**idm.sec.core.wf.approval.incompatibility.enabled**".
 +
 +<note important>Approval of role incompatibilities is enabled by default</note>.
 ====Automatic skipping of approval processes==== ====Automatic skipping of approval processes====
 Automatic skipping of approval processes is performed if the request **realizator** (the one who really submitted it) is the same user as the **currently logged-in** user and, at the same time, is among the **candidates** who can approve this task. In that case, the task is skipped with the same result as if it was approved manually. Automatic skipping of approval processes is performed if the request **realizator** (the one who really submitted it) is the same user as the **currently logged-in** user and, at the same time, is among the **candidates** who can approve this task. In that case, the task is skipped with the same result as if it was approved manually.
  • by svandav