The Access Request Service of SAP Cloud Identity Access Governance provides several functionalities to manage all the steps included in the process flow of requesting accesses to various target applications.
The management of access requests covers aspects like the creation of access requests, their processing in terms of approval steps, the remediation of potential occurring risks, simulations based on executed adjustments and, of course, the automatic provisioning of the requested access to the specific user within the relevant target application. The Access Request Service itself is a cloud-based service, which offers the possibility for requesting access either for on-premise systems as well as cloud-related applications and systems. The service is capable of linking the various access requests with different workflows and achieves an automation in the overall process flow.
The Access Request Service already provides predefined and out-of-the-box delivered standard workflows, which can be used as it is, or you can easily adapt them or build your complete customized workflows (in case you have special requirements or policies you have to implement).
The figure, Process Flow for Requesting Access, represents the typical high level process flow of requesting an access. As you can see, there are 5 steps and different responsibilities involved.
Each step and responsibility is crucial in the overall process and ensures a proper handling and processing of the requested access.
The first step is the creation of the access request. This can be done by the user itself using the self-service capability or by any other third person. Sometimes there exists a central authorization team, which is responsible for such tasks. In this case, the self-service would be deactivated and you have to request a specific access using such teams. Either way, the proper access request has to be created and submitted. After that the request will be forwarded to the fist approver stage. The approver reviews the request and has to decide whether to approve or reject the requested accesses.
Usually, during the approval process, the approvers are expected to research and identify any potential conflicts of interest between roles that the requester currently has and any new roles including permissions being requested. In such cases the approver has the opportunity to remediate such risks by assigning a mitigation control or simply rejecting the conflicting access. Based on this, the approver would be definitely interested in the output of those actions and therefore the simulation functionality can be triggered. The approver can approve the (remaining) accesses and forward the request to the next stage.
Frequently, the workflows contain multiple approval stages, to ensure that different responsibilities review and check the requested accesses. Every stage and workflow activity which has been processed is logged and tracked, meaning every decision and action performed on the access request can be reviewed and used for auditing purposes. If the access requests have been finally processed by all involved responsibilities, the approved access requests can be handed over for the provisioning into the respective target applications.
As described previously, there are different responsibilities involved in the process flow. Those can vary from organization to organization. Therefore, we want to give you a short example, who can be included in the several groups:
- Administrator: SAP Cloud Identity Access Governance admin, general basis admins, IT Security
- End users / Requestor: Employees (internal and external), Central authorization team, IT Security
- Approvers: Role Owners, Owner of related accesses, Manager, IT Security, Compliance Team, Administrators
- Compliance Team: IT Compliance; Organizational Compliance, Revision, Auditors
You can see, the Access Request Service provides tools, mechanisms, and functionalities to address the end to end access request management. In the following, you will find a short summary of the possibilities offered:
- Automated user access request for user on-boarding to enterprise applications
- Intuitive self-service access request
- Auditable access request workflow
- Complete integrated identity access governance platform
- Review and approval of access requests
- Remediation of Segregation of Duties (SOD) and critical access risks
- Auto provisioning of user access
For more information see SAP Help: https://help.sap.com/docs/SAP_CLOUD_IDENTITY_ACCESS_GOVERNANCE/83f383d3123c4f57b036d2707ec2e730/2845da1846144cc5a484d5ba7c7d3f81.html?locale=en-US
The target system has to be already connected to SAP Cloud Identity Access Governance.
Further information on how to setup the integration between SAP Cloud Identity Access Governance and various target systems (for example, S/4HANA on-premise) can be found in unit Integration Scenarios.
Supported SAP NetWeaver versions (it is important to use only supported SAP NW version because the SAP Cloud Identity Access Governance Services Data Extractor API has to be included there):
SAP NetWeaver Version - Support Pack
- NW 700 - SP34
- NW 701 - SP19
- NW 702 - SP19
- NW 710 - SP21
- NW 711 - SP16
- NW 730 - SP16
- NW 731 - SP19
- NW 740 - SP16
- NW 750 - SP04
- NW 751 - SP02
For more information about the supported versions, see SAP Support Note2628749 - IAG Provisioning Services for SAP ERP and S/4HANA on-premise Systems
Responsibilities are defined and have been assigned the proper authorizations. To use the Access Request service, you need the IAG_USER group, which should be mapped to the proper Role Collections for creating access requests in the BTP cockpit (the name "IAG_USER" could also be different). Furthermore, it is crucial that the approvers have access to the respective inboxes for selecting to be approved requests.
For more information about user management and available user groups, see SAP Help: https://help.sap.com/docs/SAP_CLOUD_IDENTITY_ACCESS_GOVERNANCE/e12d8683adfa4471ac4edd40809b9038/d62c01ecdf314eaa8aa73a46ecb9d74f.html?locale=en-US
The Subject Name Identifier of the respective SAP Cloud Identity Access Governance application has to be set to basic attribute User ID in the Identity Authentication Service (IAS), otherwise problems for several workflow operations might occur. Find more information in the following SAP Note: 2929135 - IAG - Access Request is not visible in approver's inbox
For the creation of access requests you always have to provide a priority code, which represents the urgency and importance of the requesting access. Typically, there are 4 delivered priority codes maintained: Low, Medium, High, and Critical.
If you want to define your own priority codes, you can do it using the respective app.
More information can be found on SAP Help: https://help.sap.com/docs/SAP_CLOUD_IDENTITY_ACCESS_GOVERNANCE/83f383d3123c4f57b036d2707ec2e730/a004fe6dc6b24e4a8cf1ea6b16ae821e.html?locale=en-US
For the creation of access requests, you always have to provide a reason code, which specifies the background of requesting missing access. The access request reason code supports the approvers by understanding why the access is needed.
There are not any delivered out-of-the-box reason codes, hence you have to maintain your own. Some typical examples are "Incident Handling" or "Problem Handling".
More information can be found on SAP Help: https://help.sap.com/docs/SAP_CLOUD_IDENTITY_ACCESS_GOVERNANCE/83f383d3123c4f57b036d2707ec2e730/472c41769e25482996f2440c054ec6a1.html?locale=en-US
General information on setting up the master data (including the dependencies) for the Access Request Service can be found on SAP Help: https://help.sap.com/docs/SAP_CLOUD_IDENTITY_ACCESS_GOVERNANCE/e12d8683adfa4471ac4edd40809b9038/b8d0abecaade40f6bceede19524fb8f2.html?locale=en-US
The processing of access requests require a workflow instance, which specifies how many stages (in this case, also named approvals) have been passed through before the request is approved and accepted. This workflow ensures that such requests has be reviewed and approved by the relevant responsibilities.
The workflow has to be set up and implemented beforehand, otherwise the access requests cannot be processed.
By default, the workflow templates and their respective paths are delivered out-of-the-box, but it is also possible to deploy custom workflows and change the default paths.
In general, the chosen path and workflow is based on the access request type and defined within a so-called decision table in the Business Rules editor of the SAP Cloud Identity Access Governance.
The figure, Identify the Default Workflow for Requesting Access 1/1, shows you how the default mapping is defined (out-of-the-box delivery). You have to ensure that this minimum setup is in place, at least you need a mapping entry for request type "CHANGE". That is the mandatory entry for all created access requests (for all non-PAMID related requests). The default workflow of all access requests includes 3 approval stages, which are (1) "Manager" approval, (2) "Role Owner" approval, and (3) "Security" approval.
Accessing the workflow templates and business rules can be done as follows:
- Open SAP Cloud Identity Access Governance Fiori Launchpad (FLP).
- To access the workflow templates, navigate to Administration→Maintain Workflow Template .
- To access business rules, navigate to Administration→Configuration.
- Go to Business Rule and choose Launch. The Business Rule editor opens.
Note
More information about workflow templates, business rules, and possibilities of workflow management can be found on SAP Help: https://help.sap.com/docs/SAP_CLOUD_IDENTITY_ACCESS_GOVERNANCE/e12d8683adfa4471ac4edd40809b9038/27449edc553640f683565cf662c92351.html?locale=en-US
The workflow configuration also allows you to define mandatory actions for each stage sequence. Beforehand, we have described the process flow of access requests and the additional functionalities, which can be performed by the approvers in the respective stages such as starting a remediation and / or simulation task. Per default those tasks are optional and the approvers are not forced to do that. In case you want to ensure that those tasks are performed and if you want to implement such a strict policy, you can do it by proactively activate it in the workflow configuration templates.
There are 2 options that you can set as mandatory tasks:
- Remediation Mandatory
- Risk Analysis Mandatory
Generally, it is always a best practice to execute remediation and risk analysis tasks during the approval process of an access request. Nonetheless, it depends on your organizational policies and guidelines if you have to ensure that those actions are mandatory or not.
In case you want to achieve this behavior, you can configure the options in the Maintain Workflow Template app. For more information, please refer to Unit: Initial Setup for SAP Cloud Identity Access Governance→Lesson: Setting Up Workflow and Business Rules.
The figure above, Identify the Default Workflow for Requesting Access 2/2, depicts an example for a to be approved request in the inbox. You can see that there are 2 warnings / messages, which state that the remediation and risk analysis actions are mandatory and have to be performed. Without executing those tasks the approver will not be able to confirm the request.
More information can be found on SAP Help: https://help.sap.com/docs/SAP_CLOUD_IDENTITY_ACCESS_GOVERNANCE/83f383d3123c4f57b036d2707ec2e730/0cf1e44e6f74485fab8348fe911a40e7.html?q=Parameter&locale=en-US