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
devel:documentation:security:dev:change-user-permissions [2019/01/30 09:24]
svandav [The approval process] 		devel:documentation:security:dev:change-user-permissions [2019/05/07 08:29] (current)
svandav [Duplicate request]
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 57: Line 57:
  
 ==== Duplicate request ==== ==== Duplicate request ====
 +<note warning>Since version 9.6.0, the check for duplicate requests has been removed for performance!</note>
 +
 During the process of submitting a request, it is verified if there is another duplicate request of the new request (in state "**IN_PROGRESS**", "**APPROVED**"). If a duplicate request is found, the executed request is labelled as duplicated (state "**DUPLICATED**") and its attribute "**duplicatedToRequest**" is filled with the identifier of the duplicate request (a record is made in the request log). During the process of submitting a request, it is verified if there is another duplicate request of the new request (in state "**IN_PROGRESS**", "**APPROVED**"). If a duplicate request is found, the executed request is labelled as duplicated (state "**DUPLICATED**") and its attribute "**duplicatedToRequest**" is filled with the identifier of the duplicate request (a record is made in the request log).
 The submission (execution) of the request is thus suspended. The submission (execution) of the request is thus suspended.
Line 78: Line 80:
  
 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 213: Line 211:
  
   * **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 245: Line 243:
  
 <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