This blog post discusses two integration scenarios when connecting to live data sources with SAP Analytics Cloud.
These scenarios are cross-origin resource sharing (CORS) and reverse proxies. We’ll describe the prerequisites for each connection type and walk you through important configuration steps.
This primary scenario is often called a direct connection or a CORS connection. CORS is the technology that enables the connection. SAP clearly recommends using CORS if a live connection is desired. In addition, CORS is the only supported live connection scenario.
In general, browsers follow a same-origin policy. This policy forbids web pages or scripts from sending requests to other websites or servers that aren’t trusted in the background (due to security concerns). In the past, hackers often modified popular websites and placed their own malicious code into them. Users accessed these web pages and didn’t realize that, in the background, their computer was connecting to a malicious server. With a same-origin policy, modern browsers stop this behavior and thus protect users.
However, this safeguard is a major issue for live connections. In this scenario, the browser asks SAP Analytics Cloud to directly connect to a data source and retrieve data from that data source. Normally, a browser would forbid this request since the request redirects the user to a completely different data source.
CORS is a mechanism that allows this behavior to respect same-origin policies by meeting specific requirements. Therefore, SAP Analytics Cloud and the data source will both be configured and made aware of each other’s existence. (SAP Analytics Cloud gets to know the data source, and the data source gets to know SAP Analytics Cloud.) In this case, the browser will allow the user to be redirected to the data source directly.
Note that CORS doesn’t require any physical connection between SAP Analytics Cloud and the data source. The trust is built in by configuring the URL of SAP Analytics Cloud with the data source. Afterward, the data source will accept all data requests coming from this specific SAP Analytics Cloud instance.
In the following sections, we’ll show you how to create direct, live connections to both on-premise and cloud systems.
When using the direct connection, no additional server needs to be deployed in your local company network. The figure below shows a setup in which the data source can’t and shouldn’t be reached from the public internet. The user must be logged on to the company network either being connected to it physically or using, for example, a virtual private network (VPN) tunnel.
This setup requires additional configuration based on the data source. These configuration steps are documented for each data source in the product help and are always up to date to meet the latest version. You’ll also find additional requirements and SAP Notes that you may need to implement first. A list of all live connections and their setup requirements can be found in SAP Help Portal at http://s-prs.co/v502606.
In general, the following steps are necessary to establish a live connection:
While the setup shown above only works within a company network, the setup shown below also works for the public internet, where the user is not connected to the company network.
In this option, the user accesses the data source via a live connection from the public internet. However, in this scenario, the user must be able to reach the data source directly. To get this scenario working, you can, for example, define firewall exceptions for specific devices or users. Another option is to set up the firewall to accept only specific requests from the public internet and pass them through to the data source. Independent of the technology used, SAP Analytics Cloud always requires you to provide an IP or URL that can be used to access the data source.
Both options show simplified configurations in which no identity provider is in place. An identity provider is required to use SSO. Thus, without SSO, the data source will always ask a user to provide logon credentials in order to access data via a live connection.
To make this authorization more comfortable for users, SAP Analytics Cloud offers the ability to use your own identity provider, which must be compliant with the SAML 2.0 standard. An example of such a setup is shown in this figure.
The identity provider is usually run centrally within your company and has the single purpose of identifying and authenticating users. In many companies, this verification is usually performed by a user once during system startup or when logging on to a company portal. Then, a certificate is issued that can be used to automatically authenticate, in the background, to other services like SAP Analytics Cloud or a data source.
However, the following prerequisites must be met:
After its configuration, the identity provider adds an additional security layer. From this point on, all logon requests are passed over to the identity provider, which can be also configured to be reachable only from within the company network. Doing so, however, would make accessing SAP Analytics Cloud from the public internet impossible.
Of course, other scenarios are possible when using your own identity provider. We won’t provide diagrams of the various other options here for the sake of brevity. But for a user on the public internet, for example, if the identity provider and data source are both located within the company network, then the user must be able to reach the identity provider somehow.
Furthermore, you can also place an identity provider on the public internet while the data source still resides within your company network. As long as the user is still able to reach all parties (SAP Analytics Cloud, identity provider, and data source), this setup will work fine.
For live connections to cloud-based systems, the setup is quite easy. If, for example, you use SAP S/4HANA Cloud or SAP BTP as a live data source, the browser will again directly connect to the services to retrieve the data required.
In this scenario, a user can be either within your company network, as shown in the first figure below, or on the public internet, as shown in the second figure. Again, you simply must ensure that the user can always reach all parties directly.
Direct Connection: When using the direct connection via CORS, no additional server is required. The browser is directly connected to SAP Analytics Cloud and to the data source. Between the data source and SAP Analytics Cloud, no connection needs to be established. Another option is to configure your own identity provider.
Connections via CORS are not only fast and secure but also require little configuration effort. However, CORS always requires that the user have direct access to the data source, which is not always possible. Especially when connecting via the internet, many companies face challenges in exposing data sources outside of its firewall, which can pose serious threats. Thus, SAP offers tunnel connections for a selected list of data sources.
The following data sources can be connected to via tunnels:
Connections using tunnels are rather similar to CORS, but the main difference is that a middleman, called the cloud connector of the SAP Connectivity service, handles the connection. The cloud connector is installed on the edge of your company network on a server and opens a secure connection between internal servers and the internet. Thus, browsers running SAP Analytics Cloud can connect to a data source without having direct access to that data source.
A tunnel connection is especially relevant for the following use cases:
A tunnel connection is shown in the next figure. Similar to a CORS connection, the browser is situated in the public internet and directly accesses SAP Analytics Cloud. However, to access data, the browser doesn’t reach out to the source system anymore but instead contact the cloud connector, which communicates itself again with the data source.
As with CORS connections, a tunnel connection requires various configuration steps before it can be used productively. These steps are described in detail in the product help for each data source. You’ll also find all the prerequisites or SAP Notes that may need to be implemented before establishing a connection (see http://s-prs.co/v218508).
The following steps describe the basic setup steps that must be performed for each data source:
A tunnel connection also supports the usage of an identity provider to enable SSO.
The architecture for this scenario is shown below. Note that the identity provider is connected to the cloud connector and not to the browser itself. Both the data source and SAP Analytics Cloud must use the same identity provider.
Tunnel connections are only available for the supported data sources in an on-premise scenario. For other scenarios, you must configure a CORS connection.
As an alternative to CORS, SAP offered connections via reverse proxies (called PATH). The crucial element of this scenario was a proxy residing in your company network that handled all requests.
Reverse Proxy No Longer Recommended: Although reverse proxies are still available for customers who used it in the past, officially, they are no longer recommended. New customers won’t be able to use this setup. For them, SAP explicitly recommends using the CORS connection.
The idea of the reverse proxy is based on the same-origin policy. The same-origin policy prevents applications or scripts from connecting to other, untrusted servers in the background. Therefore, the reverse proxy was designed as a go-between to capture all communication.
A reverse proxy is deployed on a server in your company network. Technically, the reverse proxy is installed on an Apache Tomcat server or SAP Web Dispatcher. The server will be configured to forward requests to either SAP Analytics Cloud or the on-premise data source. During this process, the proxy always pretends to be the data and application source facing the browser, as shown in this figure.
Instead of accessing SAP Analytics Cloud via its own URL, the browser opens the URL of the reverse proxy. The proxy then redirects the request to SAP Analytics Cloud and retrieves the application components, which are passed back to the browser. Once the user wants to connect a data source, the reverse proxy forwards that request to the data source and sends the results back to the browser.
The reverse proxy also can be placed outside of the company network, which makes SAP Analytics Cloud and the live connection also work via the public internet. However, the reverse proxy still must be able to reach the data source directly. This direct connection can be achieved either via VPN or by setting up firewall rules. An example scenario is shown here.
In terms of feature limitations, no difference exists between a CORS connection and a reverse proxy setup. The reverse proxy setup also allows the usage of SSO. However, SSO may only work with Apache Tomcat for some data sources.
Live Connections: A live connection can be established either via CORS, tunnel connection, or via a PATH connection through a reverse proxy. Because CORS doesn’t require an additional server and acts directly, this approach is officially recommended by SAP. The reverse proxy setup is still available for customers who used it in the past, but new customers going forward cannot create reverse proxies for this case. The reason for this limitation is the need for an additional server and higher complexity due to additional configurations.
Editor’s note: This post has been adapted from a section of the book SAP Analytics Cloud by Abassin Sidiq.