Change roles request

A user or an authorized administrator can change users’ roles via so-called Change roles request. The request can be accessed via detail of the user for whom the change is requested. In the tab Role, there is a form displaying:

• Assigned roles – roles which are currently assigned to the user
• Concepts of requests for authorization change – If the request is not finished (sent), the request is saved as concept there.
• Requests for authorization change - currently processed requests
• Roles pending approval - list of roles awaiting approval via all requests

Then, there is the button Manage authorizations which is used to run the process Change roles request. After clicking on the button, the empty request is open.

There, new roles are inserted using the button Add.

The following boxes can be filled in a new role selection window:

• Role - New roles for the current query are selected here using fulltext searching.
• Contracted position – Selection of a user's contracted position, to which the new role will be assigned
• Valid from - Roles with future starting date of validity will become valid on the given day, i.e. if roles assigned an account in LDAP, the account is created on the starting day of validity set in this attribute.
• Valid to - Roles with expired validity are processed in the following way
  • The user loses all the permissions resulting from the role on the expiry day, i.e. if a role assigned an account on an managed LDAP system, the account will be deleted there on the expiry day set in this attribute. The role itself is not removed from the user's contracted position, it is set invalid instead.
  • At the closest running of a scheduled task which removes roles after validity expiry date, the role is physically taken from the user (or rather from the user’s contracted position) in CzechIdM.

The role selection is confirmed by clicking the button Set. Roles can be added to one request in the described way repeatedly, if different jobs or validities need to be set for different roles, for example.

Assigning of a role can be edited by clicking on the orange square with the pencil symbol (the same form as for adding, see below). Automatic roles cannot be removed or their validity configured, they are assigned/removed automatically. Roles from the selection are removed by clicking on the red cross in the line with the role.

After the form has been filled in, it is necessary to click the button Submit a request, which sends the form to be realized in the process Change role request. If the form is closed using the button Back (next to the button Submit a request), the form is saved as a concept.

When the request has been created, the current list of roles which the user requests and their approval status can be seen in the user’s detail → Role.

The notification about the request status is sent when the request is resolved. The recipient is the user for whom the roles are to be changed.

There are two possible recipients at the moment

• the user for whom it is the change requested
• the user that really created the request

In Settings→Configuration the recipient can be changed.

By clicking on green button Add we add variable 'idm.sec.core.wf.notification.applicant.enabled' as a key and true/false as a value. Same we can do with variable 'idm.sec.core.wf.notification.requester.enabled'.

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