Agenda of universal requestsuniversalrequest

The universal request agenda allows you to create a request for any (supported) object in the IdM. A advantage versus the previous agendas for dealing with requests is versatility when there is no need to create a separate agenda for each additional approved object (such as the agenda for automatic roles requests and the agenda of requests for change a permissions).

When the approval mode is turned on, it is not possible to edit the object over the standard REST interface (for example '/api/v1/roles'), but you must use the REST for universal requests (for example'/api/v1/requests/{request ID }/roles').

From a UI perspective, the situation is similar. If the approval mode is enabled, it is not possible to edit the object on a standard URL. This means that even if the user has the right to edit, the object will be read-only (details will be read only, edit buttons will not be available, bulk operations will not be available). An object can only be edited after you have moved to a specific request URL.

Example of a URL role and the same role edit role within the request:

• /role/{role ID}/detail
• /requests/{request ID}/role/{role ID}/detail

If you want to go to the above mentioned URLs, you will first need to create the request. This can be generated by calling the method on the REST request interface of the object. This is a POST method where a single entry is the object for which we want to create a request. This input object may not exist in the database (for a situation where we want to create a new object within the request).

Example creating a request for a new role:

curl 'http://localhost:8080/idm-backend/api/v1/requests/roles' -H 'content-type: application/hal+json;charset=UTF-8' --data-binary '{"name":"NewRole","code":"NewRole"}'

If we already have a request, we can start making individual changes. As described above, individual REST request calls are "redirected" to the REST request interface of that object type. Each partial change (called REST interface) creates a request item (IdmRequestItem). This item includes, in particular, ownership of the owner, that is, the link to the object being edited.

Additionally, the request entry contains a complete object in the form of how to get from the interface. This object is used to apply changes when applying for approval. The object is saved in JSON format. This format has been chosen with respect to backward compatibility. There is a lower probability of any problems with a change in the structure of the target object. JSON format allows us to perform additional transformations (to ensure compatibility) against binary serialization of the whole object.

Requesting mode can be enabled for every supported object by property in the application configuration:

idm.pub.core.request.<requestable object>.enabled=true

, where <requestable object> is the name of requestable object (DTO).

idm.pub.core.request.idm-role.enabled=true

The basic rule of how controlled permissions are when creating a reqeust is: To execute an operation in the request, the same permission is needed as if it were needed to execute the same operation in a situation where the request mode would be turned off.

This means that the user must have at least the same permissions to create a new role request as if he wanted to create a role outside of the request mode. The same applies to other operations, that is, for editing or deleting (roles within the request), the same rights are needed as when the request mode is turned off.

Example of permissions that are needed to create a new role by request:

• Requests (universal) (IdmRequest) - Gets rights to all requests created by the logged user.
  • Evaluator: RequestByCreatorEvaluator
  • Permissions: Create, Execute, Read, Delete, Update, Autocomplete, (Admin permissions allow you to execute request without approval!)
• Requests (universal) (IdmRequest) - Currently logged user can work with requests, when identity was involved to approving.
  • Evaluator: RequestByWfInvolvedIdentityEvaluator
  • Permissions: Create, Execute, Read, Delete, Update, Autocomplete, (Admin permissions allow you to execute request without approval!)
• Requests (universal) (IdmRequest) - Returns requests by rights on the request's owner (target object). Only supports IdmRole as owner now!
  • Evaluator: RequestByOwnerEvaluato
• Requests - items (universal) (IdmRequestItem) - Gets rights to universal request items by right on requests
  • Evaluator: RequestItemByRequestEvaluator
• Roles (IdmRole) - Gets rights to all roles. Grants only IdmRole object, for additional objects (business roles, permissions, systems) you have to add next permissions.
  • Evaluator: BasePermissionEvaluator
  • Permissions: Create, Execute, Read, Delete, Update, Autocomplete

All supported objects must implemented interface eu.bcvsolutions.idm.core.api.domain.Requestable.

• IdmRoleDto - Roles
• IdmRoleCompositionDto - Business roles
• IdmRoleGuaranteeDto - Guarantee defined by identity
• IdmRoleGuaranteeRoleDto - Guarantee defined by other role
• IdmAuthorizationPolicyDto - Premissions
• IdmRoleCatalogueRoleDto - Relations on the catalogue
• SysRoleSystemDto - Linking the system to a role
• SysRoleSystemAttributeDto - Overloaded system attribute (on the role)
• IdmFormValueDto - Extended attributes

Each requestable type of object may have its own approval process. The approval process can be defined in the application configuration:

idm.sec.core.request.{object type}.wf={code of WF process}

Example for IdmRole:

idm.sec.core.request.idm-role.wf=request-idm-role

The basic approval process where changes on the role are approved by the guarantors of the role in request. If there are no guarantors or a new role, then those who have the role defined in the variable 'core.wf.approval.role-change.role' are the approvers. If this variable does not have any role, 'superAdminRole' is returned.

core.wf.approval.role-change.role=superAdminRole

If the request contains a item with business role change (IdmRoloComposition), then a separate workflow process (request-idm-role-composition) is started for each item. This process aims to verify whether the guarantors of the target role agree with the change. This means that if we put B role to role A, guarantor of the role B must agree with this assignment. The same applies to the removal of the relation. If the target role has no guarantors, then the change is considered approved.