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/02/13 10:18]
kotisovam first part moved to adming guide, and edit 		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}}
  
-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 tip>Introduction to the topic - [[../..:role_change|read here]].</note> 
 + 
 +===== 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 =====
 +This agenda contains all requests (wishes) for requested changes of authorized identities. The main idea is that all changes in identities' permission must go through this agenda. Therefore, it is not intended only for end users' requests but for automatic operations (synchronization, automatic roles, etc.) as well.
  
-The standard scenario of a permission change, after a user presses the button "**Make a request**", is as follows:+The standard scenario of a permission change is as follows:
  
 +  - The user request a change in his permission.
 +  - He presses the "**Change permission**" button in the "**Assigned roles**" tab.
 +  - A new request (in "**CONCEPT**" state) is created automatically. The detail of this new request is shown to the user.
 +  - All the assigned roles which the user has are displayed in the table of concepts "Currently assigned roles (including requested changes)". The user can make the changes over this table (see more in **Concept table**)
 +  - All the requested changes of permission are displayed in the table "**Requested permission changes**".
 +  - The user presses the button "**Make a request**".
   - If the request is not evaluated as duplicate, its execution is performed (the state is set to "**IN_PROGRESS**").   - If the request is not evaluated as duplicate, its execution is performed (the state is set to "**IN_PROGRESS**").
   - Subsequently, the event "**RoleRequestEventType.EXCECUTE**" is called out.   - Subsequently, the event "**RoleRequestEventType.EXCECUTE**" is called out.
Line 15: Line 28:
   - Ordinarily, the event is then captured by the processor "**role-request-realization-processor**", which provides the realization of the event itself. The processor calls the method **IdmRoleRequestService.executeRequest(requestId)**, which performs the application of all role concepts which are in the "**APPROVED**" or "**CONCEPT**" states (the concept state is realized due to the situation when the realization processor is called out immediately after making the request, i.e. approval is disabled).   - Ordinarily, the event is then captured by the processor "**role-request-realization-processor**", which provides the realization of the event itself. The processor calls the method **IdmRoleRequestService.executeRequest(requestId)**, which performs the application of all role concepts which are in the "**APPROVED**" or "**CONCEPT**" states (the concept state is realized due to the situation when the realization processor is called out immediately after making the request, i.e. approval is disabled).
   - ** The user is assigned roles according to the requested changes**.   - ** The user is assigned roles according to the requested changes**.
 +
 +<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>
  
 === Concept table === === Concept table ===
Line 24: Line 39:
   * All edits can be removed from the concept table (changes, cancellation of removal, removal of newly-added permissions).   * All edits can be removed from the concept table (changes, cancellation of removal, removal of newly-added permissions).
  
 +<note important>The request can be submitted only when the request is in the "**CONCEPT**", "**DUPLICATED**" or "**EXCEPTION**" states</note>
  
 ==== Changing permission without approval ==== ==== Changing permission without approval ====
Line 39: Line 55:
  
 <note tip>Systematically, it is possible to execute a submission of an event without approval even without having the required permission. Method "**IdmRoleRequestService.startRequestInternal**" serves this purpose. This method is not available through the REST interface.</note> <note tip>Systematically, it is possible to execute a submission of an event without approval even without having the required permission. Method "**IdmRoleRequestService.startRequestInternal**" serves this purpose. This method is not available through the REST interface.</note>
 +
 +==== 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).
 +The submission (execution) of the request is thus suspended.
 +
 +** A duplicate request is such a request with equivalent:**
 +   * applicants.
 +   * individual role concepts (identical role type, identical validity from/to, identical link IdentityRole).
 +   * a request note (the user can define their request only in this note).
 +
 +<note tip>A duplicate request can be submitted (executed) repeatedly. Due to this, duplicate requests are found again.</note>
 +
 +==== Request removal ====
 +A request can be removed completely only in "**CONCEPT**" state.
 +If it is in "**EXECUTED**" state, every attempt to remove it ends in exception "**ROLE_REQUEST_EXECUTED_CANNOT_DELETE**".
 +If it is in "**APPROVED, IN_PROGRESS, EXCEPTION, DUPLICATED**" states, the request is set to "**CANCELED**" state. If a process is tied to the request, the process is terminated (subsequently a record about this is made in the request log).
 +
 +
 +==== Request agenda for administrators ====
 +A situation when the end user creates a request for permission change from their profile has been described above.
 +For administrators, it is convenient to use the "**Role requests**" agenda, which provides an overview of all requests in the system. All requests in all states are displayed in this agenda (including those already executed).
 +
 +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.
 +
 +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.).
  
 ==== Integrity on remove contract or role ==== ==== Integrity on remove contract or role ====
 When role or contract (using in the some concept) is deleted and workflow process for that concept is not ended, the must be that process terminated. We cannot use standard  'cancel' of subprocess, because this operation does not triggered the main process. When role or contract (using in the some concept) is deleted and workflow process for that concept is not ended, the must be that process terminated. We cannot use standard  'cancel' of subprocess, because this operation does not triggered the main process.
  
-<note important>This cause the main process will be **frozen**, because from his view cancelled subprocess never ended.</note>+<note important>This cause the main process will be **frozen**, because from his view canceled subprocess never ended.</note>
  
-For prevent this situation is concept's subprocess not cancelled, but **disapproved** ( on delete role or contract). +For prevent this situation is concept's subprocess not canceled, but **disapproved** ( on delete role or contract). 
  
 <note important>It means if current process task has decision with ID '**disapprove**', then is used. When disapprove decision is not found, the standard cancel of process is called.</note> <note important>It means if current process task has decision with ID '**disapprove**', then is used. When disapprove decision is not found, the standard cancel of process is called.</note>
Line 97: Line 140:
  
 If the request-permission-change-without-approval mode is not used, process "approve-identity-change-permissions" will be started. If the request-permission-change-without-approval mode is not used, process "approve-identity-change-permissions" will be started.
-This process is described [[ | here]] in the admin guide. +This process ensures the approval of the request as a whole and its base implementation is composed of these parts: 
 + 
 +  - **Process name generating** (the applicant's name will also be stated in the name) 
 +  - **Approval by the helpdesk department**. 
 +  - **Approval by the manager of the applicant**. 
 +  - **Approval by the user administration department**. 
 +  - **Execution of subprocesses for each requested role**. 
 +  - **Approval of role incompatibilities** 
 +  - **Approval by the security department**. 
 +  - **Sending the notification**. 
 +  - **Realization of the request** - the realization itself is not carried out by the process, but by the service for managing requests for permission change.
  
 <note tip>The input of the proces is the event which started the approval process. This event contains the request itself (IdmRoleRequestDto). At the end of the process the event is called out again (performs the realization).</note> <note tip>The input of the proces is the event which started the approval process. This event contains the request itself (IdmRoleRequestDto). At the end of the process the event is called out again (performs the realization).</note>
Line 158: 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)**:
  • by kotisovam