The standard scenario of a permission change, after a user presses the button "Make a request", is as follows:

• 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.
• Ordinarily, this event is firstly captured by the processor "role-request-approval-processor", which starts the approval workflow (calls the method IdmRoleRequestService.startApprovalProcess). In the default state, the workflow with the definition "approve-identity-change-permissions" is started. The key of the definition which is to be started can be changed in the application configuration by adding the key "idm.sec.core.processor.role-request-approval-processor.wf", (the value will be the key of the requested definition).
• After a successful approval, the workflow process calls out the event "RoleRequestEventType.EXCECUTE" again (it continues with the event with which it has been started).
• 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 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).

There are two ways of how to make a change in permission without approval.

As mentioned above, after submitting a request, an event is called out which is captured by processor "role-request-approval-processor". If we disable this processor, all submitted requests will be realized immediately without any approval.

A request for permission change contains attribute "executeImmediately". If this attribute is set to "true", the request will be executed immediately after submitting it. A submission without approval can be executed only by users having permission "ROLEREQUEST_EXECUTEIMMEDIATELY". If an event marked in this way is executed by a user without this permission, an exception will be called out.

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.

For prevent this situation is concept's subprocess not cancelled, but disapproved ( on delete role or contract).

The creation of a request via a REST interface has the following steps:

1. Creation of the request
2. Creation of the role concepts (requested permission changes)
3. Execution of the request (submitting the request)

A request can be created via method POST on endpoint "/api/v1/role-requests/".

Example of a request:

{
  "applicant" : "846164b4-8272-46a7-ba69-0bfdad652aff",
  "requestedByType" : "MANUALLY",
  "conceptRoles" : [],
  "executeImmediately" : false,
  "description" : "Please check and approve the permission change"
}

A role concept can be created via method POST on endpoint "/api/v1/concept-role-requests/".

Example of a request (creation of a concept for assigning a new role):

{
 "roleRequest":"740d7dc3-d90b-40cd-80f9-80cf36180c80",
 "identityContract":"7fdf1128-ce2d-4d34-ba99-821a544ad753",
 "role":"6ac36596-4f68-4282-88de-685e654199d6",
 "identityRole":null,
 "roleTreeNode":null,
 "validFrom":null,
 "validTill":"2017-07-31",
 "operation":"ADD"
}

Execution of the request can be done via method PUT on endpoint "/api/v1/role-requests/{requestId}/start", where requestId is the UUID of the created request.

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.

• The approving task will be assigned to all users with role Helpdesk.
• The role can be changed in the application configuration "idm.sec.core.wf.approval.helpdesk.role", the default setting is Helpdesk.
• The approval round can be enabled or disabled in the application configuration under key "idm.sec.core.wf.approval.helpdesk.enabled".
  

  "Helpdesk" approval is disabled by default

  .

• 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 "idm.sec.core.wf.approval.manager.enabled".

.

• The approving task will be assigned to all users with role Usermanager.
• The role can be changed in the application configuration "idm.sec.core.wf.approval.usermanager.role", the default setting is Usermanager.
• The approval round can be enabled or disabled in the application configuration under key "idm.sec.core.wf.approval.usermanager.enabled".

.

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 "change-role-without-approve" is run. This process only generates the name (it is saved in the history of workflow processes) and changes the state of the role concept to "APPROVED".

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,1,2,3,4), where every priority can be assigned a different approval process.

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.

The default setting of priorities and approval processes is as follows:

• No priority (0): No approval takes place. The process "change-role-without-approve" is run (see above).
• Trivial priority (1): Approval by the manager of the applicant "approve-role-by-manager".

• Low priority (2): Approval by the guarantee of the role "approve-role-by-guarantee".

• High priority (3): Approval by the role guarantee and by the security department "approve-role-by-guarantee-security".

• The approving task will be assigned to all users with role Security.
• The role can be changed in the application configuration "idm.sec.core.wf.approval.security.role", the default setting is Security.
• The approval round can be enabled or disabled in the application configuration under key "idm.sec.core.wf.approval.security.enabled".

.

• 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".

.

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.

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 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.

• 'idm.sec.core.wf.notification.applicant.enabled' by default is false and it configure sending notifications to user, whose permissions will be modified. But if it is user, who requested change role to his own permissions, he is implementer too. So if this variable is false and the other is true, user is still implementer and will receive notification. But if both are true, user will get just 1 notification.
• 'idm.sec.core.wf.notification.implementer.enabled' by default is true and it configure sending notification to user, who made request on behalf another user. For example, when manager request role for employee in his department and wants to know the result.

Authorization policies are implemented fo role requests agenda. Concept role requests are secured by assigned role request internally. Only identity with authority ROLEREQUEST_ADMIN can read all concepts without filter by role request through the IdmConceptRoleRequestController.