Making On-Premise Systems available to the Cloud (HTTPS)

Protocol: This field allows you to decide whether the Cloud Connector should use HTTP or HTTPS for the connection to the backend system. Note that this is completely independent from the setting on cloud side. Therefore, even if the HTTP destination on cloud side specifies "http://" in its URL, you can select HTTPS. This way, you are ensured that the entire connection from the cloud application to the actual backend system (provided through the SSL tunnel) is SSL-encrypted. The only prerequisite is that the backend system supports HTTPS on that port. For more information, see Initial Configuration (HTTP).

If you specify HTTPS and there is a "system certificate" imported in the Cloud Connector, the latter attempts to use that certificate for performing a client-certificate-based logon to the backend system.

If there is no system certificate imported, the Cloud Connector opens an HTTPS connection without client certificate.

The Internal Host and Internal Port specify the actual host and port under which the target system can be reached within the intranet. It needs to be an existing network address that can be resolved on the intranet and has network visibility for the Cloud Connector without any proxy. Cloud Connector will try to forward the request to the network address specified by the internal host and port, so this address needs to be real.

Virtual Host identifies the hostname 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 backend system - for example, HTTP/80 and HTTPS/443, and to have different sets of access control settings for them. For example, some non-critical resources may be accessed by HTTP, while some other critical resources are to be called using HTTPS only. The fields are pre-populated with the values of the Internal Host and Internal Port. If you do not modify them, you must provide your internal host and port also in the cloud-side destination configuration or in the URL used for your favorite HTTP client.

Principal Type: You can use two different variants of an X.509 certificate to define the principal type that is sent to the backend within the HTTP request: X.509 Certificate (General Usage) or X.509 Certificate (Strict Usage). The latter was introduced with Cloud Connector 2.11.

If a principal is sent from the cloud side, it is injected in both cases as an HTTP header (SSL_CLIENT_CERT) and forwarded to the backend. If the backend is configured correctly for principal propagation, this certificate can be used for authentication.

However, if the cloud side does not send a principal, the variants behave differently:

• General Usage (as well as <Principal Type> = None) allows to alternatively use the system certificate for the TLS handshake (actually used for trust) also for authentication.
• Strict Usage does not allow this. In this case, another authentication type (specified in an additional header) is used instead, for example, basic authentication.
• This setting also applies to HTTP authentication types other than principal propagation.
• To prevent the use of principal propagation to the target system, choose None as <Principal Type>. In this case, no principal is injected.

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 hostname is used. When you choose Use Virtual Host, the virtual host is used. In the first case, the virtual host is still sent using the X-Forwarded-Host header.

You can enter an optional description at this stage. The respective description will be shown when pressing the Info button of the access control entry (the Mapping Virtual to Internal System table).

The summary shows information about the system to be stored and when saving the host mapping, you can trigger a ping from the Cloud Connector to the internal host, using the Check availability of internal host checkbox. This allows you to make sure the Cloud Connector can indeed access the internal system, and allows you to catch basic things, such as spelling mistakes or firewall problems between the Cloud Connector and the internal host.

If the ping to the internal host is successful (that is, the host is reachable using TLS), the state Reachable is shown. If it fails, a warning pops up. You can view issue details by choosing the Details button or check them in the log files.

This check also tries to perform client authentication, if possible, regardless of the host's availability. Find additional information and hints by choosing the Details button. You can check, for example, if the system certificate acting as a client certificate is configured correctly, and if the ABAP backend trusts it.

You can later edit such a system mapping (using Edit) to make the Cloud Connector route the requests for sales-system.cloud:443 to a different backend system. This can be useful if the system is currently down and there is a back-up system that can serve these requests in the meantime. However, you cannot edit the virtual name of this system mapping. If you want to use a different fictional host name in your cloud application, you must delete the mapping and create a new one.