Configuring Access Control

In the following, the widely used HTTP protocol is covered as an example in more details. The figure shows the overall workflow to securely use the HTTP protocol.

To set up a mutual authentication between the Cloud Connector and any back-end system it connects to, you can import an X.509 client certificate into the Cloud Connector. The Cloud Connector then uses the so-called system certificate for all HTTPS requests to back ends that request or require a client certificate. The CA that signed the Cloud Connector’s client certificate must be trusted by all back-end systems to which the Cloud Connector is supposed to connect.

There are three options on how to provide the system certificate:

• Upload an existing X.509 certificate
• Upload the signed UI certificate
• Generate a self-signed system certificate (for example: for a demo scenario)

All options are offered in the Cloud Connector Administration UI at Configuration → ON PREMISE → System Certificate.

By default, the Cloud Connector does not trust any on-premise system when connecting to it via HTTPS. To enable secured communication, you must add trusted certificate authorities (CAs) to the allowlist. Any server certificate that has been issued by one of those CAs will be considered trusted.

To maintain the trust store, in the Cloud Connector Administration UI navigate to Configuration → ON PREMISE → Trust Store.

To allow your cloud applications to access a certain back end system on the intranet via HTTP, you must specify this system in the Cloud Connector.

To do so, start the wizard offered in the Cloud Connector Administration UI at Cloud To On-Premise → ACCESS CONTROL.

To expose an AS ABAP-Based on-premise SAP system, provide the following:

1. Back-end Type: ABAP System.
2. Protocol: HTTP or HTTPS.
3. Internal Host and Internal Port: the actual host and port under which the on-premise SAP system can be reached within your intranet.
4. Virtual Host and Virtual Port: enter the host name exactly as specified in the <URL> property of the HTTP destination configuration in SAP BTP. The virtual host can be a fake name and does not need to exist. The Virtual Port allows you to distinguish between different entry points of your back end system, for example, HTTP/80 and HTTPS/443, and to have different sets of access control settings for them.
5. Allow Principal Propagation: defines if any kind of principal propagation should be allowed over this mapping. If selected, also define what kind of Principal Type is sent to the on-premise SAP system within the HTTP request.
6. System Certificate for Logon: select if the Cloud Connector's system certificate should be used for authentication at the back end.
7. Host In Request Header lets you define which host is used in the host header that is sent to the target server. By choosing Use Internal Host, the actual host name is used. When choosing Use Virtual Host, the virtual host is used.
8. Description: optional description text
9. Check Internal Host: this allows you to make sure the Cloud Connector can indeed access the on-premise SAP system.

In addition to allowing access to a particular host and port, you also must specify which Resources (URL paths, also known as Internet Communication (ICF) Services) are allowed to be invoked on that host. The Cloud Connector uses strict allowlists for its access control. Only those ICF services for which you explicitly granted access are allowed. All other HTTP(S) requests are denied by the Cloud Connector.

In the simulation below you will configure access control.

Now, you’re able to expose an AS ABAP-based SAP system for HTTP(S) access.

Configure Access Control on the SAP Help Portal