Standard role request process with approval.
Access Request Process
| This page is a work in progress. |
Technically, the Access request process is self-service process of assignment management - their creation, removal and modification. The assignments are defined on assigning roles, so it may be mentioned also as Role request process.
Access request process is designed to be managed, documented and measurable from beginning to end - from role request, through approval, till all provisioning steps are performed. Manual steps are part of the role request monitoring. Role request is finished when all automatic and all manual components are done successfully.
To have the process effective and manageable, it is designed with the access modelling concepts in mind.
1. The process
The process is designed as clear as possible. Exceptions are to be managed by IGA administrator. Reports are providing easy means to identify these exceptions.
Each access request is represented by the request object that contains all information about the request, its approval and implementation.
Self-service troubleshooting
The user interface is designed to support self-service not only at start, but also during the process. End user can monitor the whole path of his access request. He can see who didn’t approve the request for a few days or which operation team is not processing manual ticket from his request.
End user manage his expectations and even, in some organization, actively solve the issues in the process by active communication with relevant people processing his request. This attitude can significantly lower the load of IDM operation teams and speeds up the provisioning processes. Which leads to direct increase in workforce productivity and efficiency of the organization.
The chapters below describes the process in high level. Details of the access request process are here.
1.1. Create new request
From end user perspective the basic process of obtaining new access is clear and easy. User just search for relevant application or business role and request the access.
Once created, the request goes through the approval and then implementation steps. After implementation, the user is assigned access (assignment is created). The user is notified of the creation of the access.
The request may get complicated. The user may need to specify additional parameters to the request (e.g. time constrains). Or he can request the access for other team members. The user also may request update of the access (e.g. the time constrains mentioned above) or access removal.
To keep the requests simple and manageable by end users, each request relates to assigning of only one role.
Types of operation
User can perform different types of requests. The table below lists types of operation that may appear and how to handle them. We are combining who is requesting, for whom is request done and what operation is being performed.
| Who | To whom | Operation | Approval / Notification | Note |
|---|---|---|---|---|
End user |
-self- |
Role assignment |
Yes/Yes |
|
End user |
-self- |
Role removal |
No/Yes |
No approval for removal. |
End user |
-self- |
Change of assignment parameters |
Yes/Yes |
Examples: |
End user |
Other user |
Role assignment |
Yes/Yes |
Standard approval. |
End user |
Other user |
Role removal |
No/Yes |
No approval for removal. |
End user |
Other user |
Change of assignment parameters |
Yes/Yes |
Standard approval. |
Request new access
The access request is simple. End user selects the role he needs. He can change its parameters (e.g. validity period) or choose other user that the access should be assigned to. At the end the user sends the request for approval.
The submitted request will appear in the list of user’s requests, where he can monitor its processing.
Request access removal
The user selects a role from the list of assigned roles and request to remove it. Request for the role removal is created and will appear in the list of user’s requests.
Due to the reduction in the amount of approval, we recommend skip approving the withdrawal of the role.
Request access modification
The most typical modification of a request may be to extend the validity period. In this case, end user selects an assignment from the assignment list, opens it and change its parameters (validity date). After saving, an access request is automatically generated in the form of modification of the assignment parameters.
1.2. Approval
Approval can have several steps depending on the approval policy. The request is in the approval phase unless it is approved by all approvers.
Each request relates to the assignment of one role to one user. This significantly simplifies the processing of the request, but on the other hand generates a large number of approval activities. To minimize the burden on approvers, the user interface allows a clear display of requests (requester, request type, role, description) and the aggregation of approval of several requests together.
While the request is in approval, the requester or requestee can see whose turn it is to approve or process the request and can contact him if necessary. This can significantly increase processing speed (see Self-service troubleshooting above).
1.3. Implementation
During the implementation phase, provisioning, deprovisioning or adjustment of the parameters of the current assignment can take place.
All steps in the implementation phase take place in parallel, automatic performed by IDM on the relevant resources, or manual in the form of tasks performed by (mainly) IT operation teams.
In most organizations, operation teams actually use task management tools (ITSM). IDM does not replace these tools, but integrates into them. IDM creates tickets for operation teams directly in the ITSM system. The IDM system records them all in the request and monitors their processing until closing.
Implementation is complete when all automated tasks and all ITSM tickets generated by the request are successfully closed. Then the IDM informs the requestor about the creation (or modification/removal) of the access and the request is turned to the Done-Success state.
In case some tasks failed during the implementation, the request is turned to the Failed state, and it is up to the IGA administrator to solve the problem and close the request. IDM leaves freedom here, because each problem needs to be solved individually.
2. Process Monitoring and Optimization
Even when the process support self-service, active monitoring by IGA administrators is necessary. The monitoring and follow-up activities speed up approval and manual processing, which directly increases the productivity of the organization.
It is important not only to see actual values of process metrics, but also observe their development over time.
It should be noted here that statistics as an average request processing time does not comply with user experience. Average request processing time is very optimistic. People don’t see that majority is running fine, they see problems in particular. For example, if one hundred requests are processed within 2 days and 20 in 14 days, then the average is 4 days. But the user perceives that he normally (in 20% of cases) waits for processing 14 days.
On the other hand, 100% success cannot be expected. There will always be some issues that are not easy to solve. Therefore, also maximum request processing time is not appropriate as well - it would be unnecessarily pessimistic.
The expected processing time for the majority of requests metrics appears to be optimal metric for the Access request process management. What is expected and what is the majority depends on business decision of the organization (role manager in this case) - it may e.g. be 80%, 90% or 95% of processed (approved and implemented) requests within 1 week or 2 weeks. This metrics defines the process speed.
Using this metrics, the IGA administrator can manage expectations of users' or organization management and provide proof how IDM helps in increasing operation efficiency. Of course - if the targets are fulfilled (what is not always easy).
Reports
Individual metrics give an overall number that describes the whole process. Request details provide a detail view of the processing of an individual request. But for many situations some overall view "in between" is needed.
Reports providing suitable information for this level of view. And the report listed in this example can be most suitable for management of access request process.
This report shows basic information about all requests created in a defined period and provides basic high level information about the time of approval and implementation. It also identifies requests in which a problem has occurred and the administrator’s intervention is required.
Optimization
The process gives a very good feedback - it informs about which roles, or which teams, are having issues during the implementation resulting in non-functional access. At the same time, the process makes it possible to identify approvers who approve much longer than the average, implementation teams with slow processing time or even incorrect design of roles.
IDM administrator shall find solutions to identified problems. Here, however, not only in the IDM system itself (if the problem is not the wrong role configuration), but also elsewhere in cooperation with role owners, application engineers, approvers or implementation teams.
The goal of the IDM administrator is to support modifications of configurations, working procedures, but also the behavior of individual approvers so that the process is constantly accelerated and the number of problems is minimized.
Was this page helpful?
YES
NO
Thanks for your feedback