Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
devel:documentation:security:dev:change-user-permissions [2018/06/05 09:20] svandav Update tags using tagsections in range |
devel:documentation:security:dev:change-user-permissions [2019/05/07 08:29] svandav [Duplicate request] |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Changing user permissions ====== | ||
+ | |||
+ | {{tag> | ||
+ | |||
+ | <note tip> | ||
+ | |||
+ | ===== Basic life cycle of the request for change a permissions ===== | ||
+ | |||
+ | {{: | ||
+ | |||
+ | <note important> | ||
+ | |||
+ | ===== Role request agenda ===== | ||
+ | This agenda contains all requests (wishes) for requested changes of authorized identities. The main idea is that all changes in identities' | ||
+ | |||
+ | The standard scenario of a permission change is as follows: | ||
+ | |||
+ | - The user request a change in his permission. | ||
+ | - He presses the " | ||
+ | - A new request (in " | ||
+ | - All the assigned roles which the user has are displayed in the table of concepts " | ||
+ | - All the requested changes of permission are displayed in the table " | ||
+ | - The user presses the button " | ||
+ | - If the request is not evaluated as duplicate, its execution is performed (the state is set to " | ||
+ | - Subsequently, | ||
+ | - Ordinarily, this event is firstly captured by the processor " | ||
+ | - After a successful approval, the workflow process calls out the event " | ||
+ | - Ordinarily, the event is then captured by the processor " | ||
+ | - ** 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 table === | ||
+ | The goal is to provide the user with a comfortable way of creating the requested permission changes (they can see all the change in one location, projected into their currently assigned roles). | ||
+ | * The input parameter of the concept table is a list of all currently assigned roles of the user (they are not coloured). | ||
+ | * If the user adds new permission (role + date of validity), it will be displayed in the table a new lines (in green colour). | ||
+ | * If the user removes permission, it will not disappear from the table, its state will only change (in red colour) | ||
+ | * If the user edits permission (currently, only the date of validity can be changed), the permission will be displayed in orange colour. The tooltip over the edited cell will display the original value. | ||
+ | * All edits can be removed from the concept table (changes, cancellation of removal, removal of newly-added permissions). | ||
+ | |||
+ | <note important> | ||
+ | |||
+ | ==== Changing permission without approval ==== | ||
+ | |||
+ | There are two ways of how to make a change in permission without approval. | ||
+ | |||
+ | === Disabling the approval processor === | ||
+ | As mentioned above, after submitting a request, an event is called out which is captured by processor " | ||
+ | |||
+ | <note important> | ||
+ | |||
+ | === Request attribute " | ||
+ | |||
+ | A request for permission change contains attribute " | ||
+ | |||
+ | <note tip> | ||
+ | |||
+ | ==== Duplicate request ==== | ||
+ | <note warning> | ||
+ | |||
+ | During the process of submitting a request, it is verified if there is another duplicate request of the new request (in state " | ||
+ | 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.</ | ||
+ | |||
+ | ==== Request removal ==== | ||
+ | A request can be removed completely only in " | ||
+ | If it is in " | ||
+ | If it is in " | ||
+ | |||
+ | |||
+ | ==== 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, | ||
+ | |||
+ | 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 ==== | ||
+ | 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 | ||
+ | |||
+ | <note important> | ||
+ | |||
+ | For prevent this situation is concept' | ||
+ | |||
+ | <note important> | ||
+ | |||
+ | ===== REST interface ===== | ||
+ | The creation of a request via a REST interface has the following steps: | ||
+ | - **Creation of the request** | ||
+ | - **Creation of the role concepts** (requested permission changes) | ||
+ | - **Execution of the request** (submitting the request) | ||
+ | |||
+ | ==== Creation of the request ==== | ||
+ | |||
+ | A request can be created via method **POST** on endpoint " | ||
+ | |||
+ | **Example of a request**: | ||
+ | <code json> | ||
+ | { | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | ==== Creation of the role concepts ==== | ||
+ | |||
+ | A role concept can be created via method **POST** on endpoint " | ||
+ | |||
+ | **Example of a request** (creation of a concept for assigning a new role): | ||
+ | <code json> | ||
+ | { | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | ==== Execution of the request ==== | ||
+ | |||
+ | Execution of the request can be done via method **PUT** on endpoint " | ||
+ | |||
+ | <note tip> | ||
+ | |||
+ | ====== The approval process ====== | ||
+ | |||
+ | If the request-permission-change-without-approval mode is not used, process " | ||
+ | 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' | ||
+ | - **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).</ | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | |||
+ | ====Approval by the helpdesk department==== | ||
+ | |||
+ | * The approving task will be assigned to all users with role **Helpdesk**. | ||
+ | * The role can be changed in the application configuration " | ||
+ | * The approval round can be enabled or disabled in the application configuration under key " | ||
+ | | ||
+ | <note important>" | ||
+ | |||
+ | ====Approval by the manager==== | ||
+ | |||
+ | * The approving task will be assigned to all users evaluated as the managers of the applicant. The manager is defined based on the industrial relations of the applicant. | ||
+ | * The approval round can be enabled or disabled in the application configuration under key " | ||
+ | |||
+ | <note important> | ||
+ | |||
+ | ====Approval by the user administration department==== | ||
+ | |||
+ | * The approving task will be assigned to all users with role **Usermanager**. | ||
+ | * The role can be changed in the application configuration " | ||
+ | * The approval round can be enabled or disabled in the application configuration under key " | ||
+ | |||
+ | <note important> | ||
+ | |||
+ | ====Execution of approving subprocesses==== | ||
+ | |||
+ | Every constituent role being requested (change or assignment) can be approved separately. Due to that, a separate subprocess is always run for every role. | ||
+ | |||
+ | If the role is evaluated as not requiring approval, default process " | ||
+ | |||
+ | {{: | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ===Setting of the approval process to a role=== | ||
+ | The approval process (for assigning or changing an ssigned role) is set to the role by setting the relevant priority. The role's priority can have values (0, | ||
+ | |||
+ | The specific priority assignment and the type of approval process is defined in the application configuration: | ||
+ | |||
+ | |||
+ | < | ||
+ | idm.sec.core.wf.role.approval.{priority}={wf} | ||
+ | </ | ||
+ | |||
+ | ,where {priority} is the **priority number** and {wf} is the key of the process workflow. | ||
+ | |||
+ | |||
+ | <note important> | ||
+ | |||
+ | <note tip>To make removing of a role approved, it is necessary that the role item " | ||
+ | |||
+ | **The default setting of priorities and approval processes is as follows**: | ||
+ | |||
+ | * **No priority (0)**: | ||
+ | No approval takes place. The process " | ||
+ | |||
+ | * **Trivial priority (1)**: | ||
+ | Approval by the manager of the applicant " | ||
+ | |||
+ | |||
+ | {{: | ||
+ | |||
+ | * **Low priority (2)**: | ||
+ | Approval by the guarantee of the role " | ||
+ | |||
+ | <note tip>This process supports approving for change automatic role.</ | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | |||
+ | * **High priority (3)**: | ||
+ | Approval by the role guarantee and by the security department " | ||
+ | |||
+ | <note tip>This process supports approving for change automatic role.</ | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | |||
+ | |||
+ | ====Approval by the security department==== | ||
+ | |||
+ | * The approving task will be assigned to all users with role **Security**. | ||
+ | * The role can be changed in the application configuration " | ||
+ | * The approval round can be enabled or disabled in the application configuration under key " | ||
+ | |||
+ | <note important> | ||
+ | |||
+ | ====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 " | ||
+ | * The approval round can be enabled or disabled in the application configuration under key " | ||
+ | |||
+ | <note important> | ||
+ | ====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. | ||
+ | |||
+ | ==== Approve, disprove task by task detail ==== | ||
+ | To task detail is possible to get from url in notification (email and etd.), after click to url in notofication you will be redirected to task detail. After aprove, disaprove or go back you will be redirected to all your tasks. When is reopend already denied or approved task, user recive information about nonexisting or solved task. | ||
+ | |||
+ | **Beware** if url with task is copy by ctrl+c and paste directly to web browesr by ctrl+v, user will be redirected to the page on which he was (for example google.com, blank page, etc.) | ||
+ | |||
+ | |||
+ | ==== Sending notifications ==== | ||
+ | Sending notifications is by default enabled just to notify user just about his change of permissions. Sending notifications can be modified with two global boolean variables, which specify sending notifications. | ||
+ | |||
+ | * ' | ||
+ | * ' | ||
+ | |||
+ | |||
+ | ===== Security ===== | ||
+ | Authorization [[authorization# | ||