The central functionality of the Access Request Service is the possibility of creating access requests to extend existing access assignments or to request new roles and authorizations that are needed to fulfill specific tasks or jobs.
The usage of access requests ensures that users are able to request the roles they need quickly, easily, and efficiently. As a result, the Access Request Service will reduce the time spent on manual tasks.
The overall goal is the acceleration of the end-to-end provisioning in combination with a streamlined workflow to perform all the necessary tasks and actions to achieve a compliant access request processing.
The creation of an access request will be done using an access request submission form, which holds all of the relevant information a user would like to add.
In order to create access requests, you have to navigate to the following apps:
- Create Access Request
- Create Access Request for Others
The first app represents the intuitive self-service capability for access requests. Using this app means that you are only able to create access requests for yourself.
To do this, you have to perform the following steps:
- Open SAP Cloud Identity Access Governance Fiori Launchpad (FLP).
- Navigate to Access Request→Create Access Request.
- To request new roles and / or groups resp. accesses, select Request New Access.
- Search for your required access using the search field.
You can search for any attributes such as name, description, access type, business process, or sub-process.
To start the search, choose the Go button.
- In the Search Results list, choose your desired roles using the checkbox.
Note
You can search for further accesses and select them as well. - To filter your results by application type, business process, or access type you have to choose Show Filter Bar.
By clicking on the access name, you have the possibility to drill down on the access to see the transactions.
- Choose Create Request.
- On the next page, provide data in the Request Details section:
- Reason for Request = <Select any available reason code from the dropdown menu>
Note
The reason codes have been created previously as they are mandatory master data for access requests. - Priority = <Select any available priority from the dropdown menu>
Note
The priority codes have been created previously as they are mandatory master data for access requests. - Manager = <Select a manager from the selection list>
Note
The available listed persons are those, which are assigned to the IAS group IAG_WF_MANAGER to act as managers in the access request. - User Email = <If the email is not populated automatically based of the configured user source, typically Identity Authentication system, you have to maintain it manually. You have to insert the email of the user, for whom you request the access.
- Reason for Request = <Select any available reason code from the dropdown menu>
- Select necessary data in Access Requested section:Validity Period
= <Specify the validity period of all requested accesses (if applicable)>
- Include attachments in the Attachment section if needed.
In case you want to, you can include a supplemental document about the request for the approver to review.
Note
Allowed types are TXT, JPG, PNG, PPT, DOC, DOCX, PDF, XLS, XLSX with a maximum file size of 100MB - Choose Submit Request to complete the creation.
After submitting the request, the app assigns a request number and routes the access request to the respective approvers (depends on your workflow configuration). As a result, the Access Request Status app automatically opens after the request submission and displays the current status of all your requests.
The second app represents the access request creation capability, which can be done representatively for others. Using this app means that you are able to create access requests for any other person who is available in the SAP Cloud Identity Access Governance.
To do so you have to perform the following steps:
- Open SAP Cloud Identity Access Governance Fiori Launchpad (FLP).
- Navigate to Access Request - Others→Create Access Request for Others.
- Search for the relevant user, for whom you want to request access.
Use the search field to narrow down the user list.
Select the desired user.
- To request new roles and/or groups resp. accesses, select Request New Access.
- Search for your required access using the search field.
You can search for any attributes such as name, description, access type, business process, or sub-process
To start the search, choose the Go button.
- In the Search Results list, choose your desired roles using the checkbox.
Note
You can search for further accesses and select them as well.To filter your results by application type, business process, or access type you have to choose Show Filter Bar.
You have the possibility to drill down on the access to see its details.
- Choose Create Request.
- On the next page, provide data in the Request Details section:
- Reason for Request = <Select any available reason code from the dropdown menu>
Note
The reason codes have been created previously as they are mandatory master data for access requests. - Priority = <Select any available priority from the dropdown menu>
Note
The priority codes have been created previously as they are mandatory master data for access requests. - Manager = <Select a manager from the selection list>
Note
The available listed persons are those, which have the proper group assignment to act as managers in the access request. - User Email = <If the email is not populated automatically based of the configured user source, typically Identity Authentication system, you have to maintain it manually. You have to insert the email of the user, for whom you request the access.
- Reason for Request = <Select any available reason code from the dropdown menu>
- Select necessary data in Access Requested section: Validity Period = <Specify the validity period of all requested accesses (if applicable)>
- Include attachments in the Attachment section if needed: In case you want to, you can include a supplemental document about the request for the approver to review.
Note
Allowed types are TXT, JPG, PNG, PPT, DOC, DOCX, PDF, XLS, XLSX with a maximum file size of 100MB - To complete the creation, choose Submit Request.
After submitting the request, the app assigns a request number and routes the access request to the respective approvers (depends on your workflow configuration).
After the creation of access requests the workflow engine will route them to the respective approvers. To keep track of those requests and know their current condition and progress you can use several apps to get those information.
The following apps can be used to achieve a proper status tracking of currently processing access requests:
- Access Request Status
- Request Administration
The Access Request Status app can be used to get a running history of your own created access requests. Within this app you can only see your personally created access requests. You are not able to see any other requests in this app.
As a result of this restricted view, the app provides the possibility for canceling. If you decide to cancel any of your previously created requests before they are completed, you can do this using this app.
Note
In the following, you will learn how to use the app and check the status of your requests and also how you can cancel one of your ongoing requests.
The steps to perform are as follows:
- Open SAP Cloud Identity Access Governance Fiori Launchpad (FLP).
- Navigate to Access Request→Access Request Status.
- When you open the app, you will get a list of all your ongoing requests.
You see several information in the list view like overall status of the request, request number, reason code, created for (that is, the user that the request has been created for) and how many days have passed since it was created.
- Select one request to get their details.
You see several information about the request like requested accesses, its status, in which stage sequence the request is, who is the currently assigned approver and also other details - for example, attachments or notes, which have been provided during the creation or processing.
- Choose the specific Approver data to get the details, who are the current approvers where the request is pending.
- In case you want to cancel the request, you can do it by choosing the respective Cancel Request button.
As already described, you have to differentiate between the overall status of the request itself and the status of the to be processed line items / accesses.
The following explain the status labels for the access request and the accesses (single line items):
Statuses for Line Item (singular access):
- Pending = Decision is pending
- Canceled = The user canceled the request
- Rejected = Approver rejected the access
- Approved = Approver approved the access
Statuses for Access Requests:
- Pending = Request has been created, but no action has been taken
- In Process = Request has had some action taken on it. For example, one approver has approved it and it is waiting for the next one
- Approved = Request has been agreed to by the approvers
- Canceled = The user canceled the request
- Rejected = Approvers have rejected the request
- Completed = The request has been approved and is provisioned
- Failed = Provisioning failed for all line items
- Completed with Errors = The access request was partially provisioned. Some items were successfully assigned and some failed
On the other hand, for the use of administrators and not end-users, there exists the Request Administration app, which lists all ongoing access requests regardless of their creator. Within this app, you can see the full list of all requests, which are not processed finally. In case any of the approvers are on vacation or sick leave, you are capable of forwarding an access request to an individual colleague resp. another approver. As a result of that you can ensure that any access request can be processed in a timely manner and is not stuck in the overall process flow.
In the following, you will learn how to use the app and check the status of all requests and also how you can forward one of the ongoing requests to any other approver.
The steps to perform are as follows:
- Open SAP Cloud Identity Access Governance Fiori Launchpad (FLP).
- Navigate to Access Request→Request Administration.
- You get a list of all open requests on the IAG system, which are not fully processed yet.
You can use the filter option to narrow the result list and/or search for a specific request.
The list shows the most relevant information of the request like request number, reason code, current approver (here you have the possibility to get the detail of the approver by clicking on the entry), current stage and so on.
- You can select one request (select the respective entry) to move forward to the Approve Requests page, where you can see more information like requested accesses, existing assignments of the user, provided notes and attachments and the audit log. this is a simulation of how the work item looks in the approver's inbox.
Note
You are not able to approve or reject the request if you open the Approve Request page this way. You only see the above mentioned details. - You have the possibility to select one request using the checkbox and route it forward to another approver with the respective Forward button.
- The Forward to popup opens.
- Select an alternative approver through the selection menu.
- Provide a short reason.
- Choose the Forward button to confirm the action.
Note
When access requests have been created, the workflow engine will route the requests to the respective approvers. In case you are assigned as an approver or somehow involved as the person responsible to approve or reject access requests, you can do it by using the following app:Access Request Inbox
This app displays ongoing access requests, which has to be processed. By using this app, approvers can view open requests and choose which one to process.
The app allows you to drill down into the details of each access. You can approve or reject each line item. Approvers can also view any risks associated with an access and start remediation actions.
In the following, you will learn how to use the app and also how you can process the included line items (approve or reject requested accesses).
The steps to perform are as follows:
- Open SAP Cloud Identity Access Governance Fiori Launchpad (FLP).
- Navigate to Access Request→Access Request Inbox.
- The My Inbox opens and lists all access requests, which have to be approved. Every approver has to use this app in order to process the access requests.
The list provides some key information of the request like request number, reason code, current stage (task), and so on.
- Select the request you want to approve / reject (choose the respective entry). You will be forwarded to the Approve Requests page.
For more information, see SAP Help: https://help.sap.com/docs/SAP_CLOUD_IDENTITY_ACCESS_GOVERNANCE/83f383d3123c4f57b036d2707ec2e730/6882d8fbc5894fd98cf6bf967963dc18.html?locale=en-US
Continue with the following steps:
- The Approve Requests page opens and provides further details of the access request, you want to approve/reject.
- On this page you can see more information, which is separated in 6 sections:
(i)Request Details
This lists the request number, the person for whom the request is made and their user ID, the request priority, the date the request was last updated, and the department of the person for whom the request is made. It also displays metrics showing the total number of risks associated with the request, and how many risks are Segregation of Duty (SOD) and Critical Access risks. It also shows you how many risks have been mitigated.
(ii)Access Requested
This lists each access requested whether it is a new request, or it is an extension (in case of extension you will notice the following info: expires in # of days, or expired), its validity period and risks. If you want to you can adjust the Validity Period that has been requested. You can also drill down on each access to see its details. Approvers can approve or reject per line item. They can also remediate any risks by assigning mitigation controls.
(iii)Existing Assignments
This lists your existing access to various applications.
(iv)Attachments
This allows approvers to view supplemental documentation submitted by the requestor about the request.
(v)Notes
This allows the approver to enter comments about the request.
(vi)Audit
This displays a continuous history with timestamps of all the actions previously performed on this request.
- Use the appropriate radio buttons to either approve or reject the requested access.
Note
In the case where multiple accesses are requested, you have to handle every access individually and decide whether you want to approve or reject it. - Provide a note to comment your decisions (optional).
- After you made your choices, you can choose the Submit button to route the request to the next stage.
Note
By default, there are 3 approval stages in the following sequence: Manager, Role Owner, and Security.Note
You have to repeat those steps for every approval stage until the request is fully processed and ready for provisioning.
During the approval process, the responsible person is able to get some important metrics about the total number of risks associated with the request, and how many of them are Segregation of Duty (SOD) or Critical Access risks. The person responsible can also see how many risks have been mitigated so far. The information that has been provided in the "Request Details" section are a summary of the status-quo.
They reflect the newly to-be-assigned accesses as well. However, if you are interested in the dedicated risks caused by the requesting accesses, you can view them in the "Access Requested" section, which lists all requesting accesses. Here the approver can also view any risks associated directly with an access. Based on that, the approver is capable of starting any necessary remediation actions. This is an important task, because any organization wants to prevent unmitigated risks from being assigned to users. Based on executed remediation actions, the approver can then start a simulation to see how his actions and changes (for example, reject some accesses, assign mitigation controls to an access) affect the initially existing risks. Those functionalities in the access request process flow, resp. the approval steps, ensure to "stay clean".
In the following, you will learn how to start the remediation actions and simulations during the approval step of an access request.
To do this you have to perform the following tasks:
- Open SAP Cloud Identity Access Governance Fiori Launchpad (FLP).
- Navigate to Access Request→Access Request Inbox.
- The My Inbox opens and lists all access requests, which have to be approved. Every approver has to use this app in order to process the access requests.
The list provides some key information of the request like request number, reason code, current stage (task), and so on.
- Select the request you want to approve / reject (choose the respective entry). You will be forwarded to the Approve Requests page.
- Review the request and all requested accesses.In case there are any risks caused by the new assigned access, you should start the necessary remediation actions before approving and submitting the request in order to mitigate or eliminate potential risks.
- Analyze the risks involved for the request by clicking on the warning sign in the Risks column. Select the risks to see additional details.
- Decide if assigning a mitigation control would help you to achieve compliance. Alternatively, you can think about rejecting the access and using another risk-free access. If so, select Remediate Risks.
- To start the remediation actions, choose the Remediate Risks button.
You have started the remediation task. Now, you have several options to move forward:
- Select one of the following options:
- Option 1: Assign mitigation control using the Risks section:
- Choose Remediate Risks
- Scroll down to Risks section
- Select an appropriate mitigation control
- Select one of the available monitor groups
- Specify the control assignment validity period
- Option 2: Reject all risky accesses using the proper radio button and check effects on the risk status.
- Option 1: Assign mitigation control using the Risks section:
- When you finished your remediation tasks (mitigation, approvals and rejections), select the Simulate button to see how your actions affect the user's risks and Access Compliance score .
Note
The Access Compliance score is the percentage of the user's risks that have been mitigated. - You have the possibility to play around and adjust your actions over and over again until the risks are mitigated or eliminated.
If everything is correct and you are satisfied with the result, do the following:
- Choose the Confirm button to accept your actions.
- Choose the Approve radio button in the Approve or Reject Access column.
Note
The access request has not been processed resp. approved yet, you have executed remediation and simulations only. - Choose the Submit button to finally approve the access request and route it to the next stage.
The Access Request Service of the SAP Cloud Identity Access Governance provides also a functionality for the extension of assignments. In case you want to extend the validity period of an user assignment, you can use the following apps (which have been already presented in the previous paragraphs):
- Create Access Request
- Create Access Request for Others
In general, the extension of any validity period of an user assignment does not differ so much from requesting a new access. At the end, it is simply an access request, which has been processed by the several approval steps as well. In fact, the extension of an existing assignment constitutes a change of the already successful processed access, which means that it has to be reviewed and evaluated again. To do so, the requestor also has to create an access request. The only difference is that the requestor is not selecting a totally new access (role or group), but rather an existing assignment of the users accesses.
You will learn how to achieve resp. trigger a successful extension of an existing user assignment. Therefore, you have to perform the following steps:
- Open SAP Cloud Identity Access Governance Fiori Launchpad (FLP).
- Navigate to Access Request - Others→Create Access Request for Others.
- Search for the relevant user, for whom you want to extend an existing user assignment.
- To receive a list of all already assigned accesses, select Existing Assignments.
- In the Existing Assignments list, choose your desired access using the checkbox.
Note
You can select further accesses and select them as well.Note
All accesses, which will expire in the near future, are highlighted with its remaining validity time. - Choose Create Request.
- On the next page, provide the necessary data:
- On the next page, provide data in the Request Details section:
- Reason for Request = <Select any available reason code from the dropdown menu>
Note
The reason codes have been created previously as they are mandatory master data for access requests. - Priority = <Select any available priority from the dropdown menu>
Note
The priority codes have been created previously as they are mandatory master data for access requests. - Manager = <Select a manager from the selection list>
Note
The available listed persons are those, which are assigned to the IAS group IAG_WF_MANAGER to act as managers in the access request. - User Email = <If the email is not populated automatically based of the configured user source, typically Identity Authentication system, you have to maintain it manually. You have to insert the email of the user, for whom you request the access.
- Reason for Request = <Select any available reason code from the dropdown menu>
- Select necessary data in Access Requested section:
Note
There are 2 actions available: Extend and Remove. You can switch between them by selecting the respective button in the Action column.- Action Extend: can be used to extend the validity period of the selected access. Validity Period = <Specify the validity period of all requested accesses (if applicable)>
- Action Remove: can be used to remove the selected access.
- Include attachments in the Attachment section if needed: In case you want to, you can include a supplemental document about the request for the approver to review.
Note
The allowed types are TXT, JPG, PNG, PPT, DOC, DOCX, PDF, XLS, and XLSX. The maximum file size allowed is 100MB.- Choose Submit Request to complete the creation.
When the request is submitted, the app assigns a request number and routes to the access request and to the respective approvers (this depends on your workflow configuration).
Creating access requests can be done by using the respective apps of the Access Request Service in SAP Cloud Identity Access Governance. To create an access request, the requestor will open a specific request submission form to provide the relevant data and information, which are needed to raise a request. This form typically holds all the information a user would like to add or has to add to the request. In some cases, it is required to enhance this form with further fields to enrich the request with additional important information. This could be needed due to organizational requirements, specific guidelines or policies. In order to achieve this in SAP Cloud Identity Access Governance, you have the possibility to create and use the application type-specific custom fields in the access request as well (at least to some extent, because the functionality is limited).
Note
In the following section, you will learn how to create and use custom fields in access requests.
The setup of custom fields requires the following tasks:
- Create Custom Field Group.
- Create Custom Field and assign a Custom Field Group.
- Field Mapping.
Lets start with the first task of the setup, which is Create Custom Field Group.
The Custom Field Group defines when, where, and under what conditions to use the new custom field.
To create a custom field group, you have to perform the following steps :
- Open SAP Cloud Identity Access Governance Fiori Launchpad (FLP).
- Navigate to Administration→Custom Field Groups.
- Create a new entry using the + button.
- Provide the necessary data:
- Name = <Enter any name>
Note
Use up to 32 alphanumeric characters, no spaces or special characters allowed.] - Description = <Enter any description>
- Process = Access Request
- Entity Type = Application Type
- Entity Type Value = <Select one of the available application types from the selection menu>
Note
Here you define the conditions when this custom field is used - for example, when the application type = "SAP ERP" on an access request, the user must provide the custom field data. - Status = Active (checkbox selected)
- Name = <Enter any name>
- Choose Save.
For more information, see SAP Help: https://help.sap.com/docs/SAP_CLOUD_IDENTITY_ACCESS_GOVERNANCE/9621f10c676c497a8355b7e36053e837/65c1b941d63e4d3fa9f861f866189457.html?locale=en-US
The second task of the setup is to Create Custom Field and assign a Custom Field Group.
When the custom field group is created, you define a custom field. For the custom field itself you designate the specifics like its name, its length, whether it is mandatory, and so on.
To create a custom field and assign it to the custom field group, you have to perform the following steps:
- Open SAP Cloud Identity Access Governance Fiori Launchpad (FLP).
- Navigate to Administration→Custom Fields.
- Create a new entry using the + button
- Provide the necessary data:
- Name = <Enter any name>
Note
This is technical name, which is not displayed on the access request form. - Description = <Enter any description>
- Label = <Enter any label>
Note
This is the field label that will be displayed when using the custom field in an access request. - Input Type = Input Text
- Data Type = String
- Field Length = <Enter any length resp. define how long the field>
- Status = Active (checkbox selected)
- Assign custom field group using the + button
Select the required custom field group using the checkbox and choose the Select button.
Note
You can assign one or more custom field groups.
- Name = <Enter any name>
- Choose if the custom field should be mandatory to be filled during access request creation by switching on / off Required?
- Choose Save.
For more information, see SAP Help: https://help.sap.com/docs/SAP_CLOUD_IDENTITY_ACCESS_GOVERNANCE/9621f10c676c497a8355b7e36053e837/be58c4622f964a9487e552b7bb5bf6d6.html?locale=en-US
The last task of the setup is the Field Mapping.
You are using the field mapping to map the previously created custom fields from SAP Cloud Identity Access Governance to the respective external applications such as SAP S/4 HANA, SAP SuccessFactors and so on, for purposes of provisioning.
Note
To create a custom field mapping and assign it to the custom field group, you have to perform the following steps:
- Open SAP Cloud Identity Access Governance Fiori Launchpad (FLP).
- Navigate to Administration→Field Mapping.
- Select the application type that you want to maintain from the list of supported application types (here: SAP S/4HANA On-premise).
- Select the Edit button.
- To add a new entry, choose the + button.
- Choose the value selection icon and select a SAP IAG Custom Field from the list. This is the field from which you want to map.
- Choose the value selection icon for the target application type (here: SAP S/4HANA On-premise) and select the field that you want to map to.
- Choose Save.
Note
When a field is added to the field mapping list, it is ready to use in provisioning.
For more information, see SAP Help: https://help.sap.com/docs/SAP_CLOUD_IDENTITY_ACCESS_GOVERNANCE/9621f10c676c497a8355b7e36053e837/6781524d02e84e938c3ab4b762714ac8.html?locale=en-US
Information with regards to the available mapping fields can be found in SAP Note: 3084274 - Identity Access Governance Additional Functionality Access Request SAP On-Premise.
When you have setup and configured your custom field(s) and finished the field mapping activity, the custom field(s) can be utilized in the access request submission form and provides an opportunity to enrich the submitted request data with additional information, which are needed in the target applications.
Keep in mind that the custom fields are only working for new user creations. In case you submit an access request for an existing user in the target application, you are able to see the custom field on the form, but it has no effect in the provisioning process. It will not be considered and the user will not get updated with the information of the custom field.
The figure, Create and Use Custom Fields in Access Requests, presents you the example of custom field "LANGCODE" (Language Code), which was shown on the previous setup tasks of the custom field group "S4_ONPREM_CG", custom field "LANGCODE" and mapping "LANGCODE = LANGU".
Take note that the "Custom Field" named "LANGCODE" was assigned to a "Custom Field Group" named "S4_ONPREM_CG", which declares the usage specifically to the entity "Application" with entity type "SAP S/4HANA On-Premise".
That means, the custom field "LANGCODE" will be only visible and used if a requestor will request an access specific to an SAP S/4HANA on-premise application. As you can see above, this is the case and thus the custom field will be displayed. In case you have set the custom field "LANGCODE" as required (can be achieved by the respective button in the custom field definition "S4_ONPREM_CG"), the requestor are forced to provide any data (in this case with maximum length of 2).
On the other hand, if you are going to request an access non-specific to an SAP S/4HANA o-premise application, then the custom field "LANGCODE" will not be visible on the access request submission form.