Skip to Content
Author's profile photo Simon Kessler

SAP Analytics Cloud: Live Data Connection to SAP BW/4HANA Using CORS and SSO

This blog post will cover the usage of the direct live data connection in SAP Analytics Cloud to SAP BW/4HANA. It is a follow-up and enhancement of my previous blog post. To help you with your implementation you will learn about:

  • Architecture of live data without a reverse proxy but using CORS
  • SSO with SAML using the direct connectivity with Azure AD and SAP Cloud Platform Identity Authentication Service (IAS)

Architecture without a reverse proxy

As stated in my previous blog post we need a way to overcome the Same-Origin-Policy (SOP) which disallows a browser to make XMLHttpRequests to another domain (BW/4HANA). The workaround in my other blog post was to use a reverse proxy. This is working fine and was until recently the recommended setup. But with Wave 20 we got the support for Direct Live Data Connections to BW/4HANA. As the name suggests no middleman (reverse proxy) is required anymore. SAC can now talk directly to BW/4HANA.

But wait.. Didn’t we say it is not possible because of the SOP? Yes, but there is this great feature called Cross-Origin-Resource-Sharing (CORS):

“CORS (Cross-Origin Resource Sharing) is a system, consisting of transmitting HTTP headers, that determines whether to block or fulfill requests for restricted resources on a web page from another domain outside the domain from which the resource originated.

The same-origin security policy forbids “cross-domain” requests by default. CORS gives web servers cross-domain access controls, which enable secure cross-domain data transfers.“

(Source: Mozilla)

Now that sounds exactly like what we need! So CORS is adding some HTTP headers from the server’s (BW/4HANA) response that tell the browser “Hey, it is safe and okay to access my domain as long as you are from <domain-of-SAC>”. Among others the Access-Control-Allow-Origin header is sent. It must contain the SAC domain so the browser knows it is safe to access this server from the SAC domain. You could call this kind of a trust setup. Keep in mind that as with the reverse proxy setup the data flow is only happening between the browser and your BW/4HANA system. If both are in the corporate network your data never leaves your network.

Entering the credentials all the time is also not very convenient. Therefore we have to enable SSO as well. For that we will use SAML and two Identity Providers. Why would we use two IdP? Well, if possible you should always go with one IdP only. But some landscapes may require you to use one master IdP and another which acts as a proxy. SAP IAS allows you to be setup as a proxy. It will basically pass through all authentication requests to your corporate IdP (e.g. Azure AD). This setup is totally possible with SAC and BW/4HANA. In this blog post we assume that you want to setup trust between BW/4HANA and Azure Ad. SAC will have a trust relationship with IAS where IAS is acting as a proxy for Azure AD.

In the next chapters we are going to check out what is required to set this all up.

BW/4HANA setup

First of all you have to ensure that the information access (InA) service is activated and you are running SP4 at least. Then follow the excellent description of Firas: You must perform the steps mentioned under the section “Netweaver 7.4+”.

I will quote the relevant steps for easier reference here:

“On your BW system, create a file somewhere (ex: /usr/sap/<SID>/SYS/profile/cors_rewrite), then add it to icm/HTTP/mod_0 as the following:

icm/HTTP/mod_0 = PREFIX=/,FILE={path_to_cors_rewrite_file}

The file should hold the following content:

if %{HEADER:isSACOriginAllowed} = true
	setHeader isSACOriginAllowed false

if %{HEADER:ORIGIN} regimatch ^(http(s)?:\/\/)?{SAC_HOSTNAME} [AND]
if %{PATH} regimatch (\/sap(\(.*\))*\/bw\/ina\/*) [AND]
setHeader isSACOriginAllowed true
if %{HEADER:isSACOriginAllowed} = true
  setResponseHeader Access-Control-Allow-Origin %{HEADER:ORIGIN}
  setResponseHeader Access-Control-Allow-Methods GET,POST
  setResponseHeader Access-Control-Allow-Headers x-csrf-token,x-sap-cid,authorization,mysapsso2,x-request-with,sap-rewriteurl,sap-url-session-id,content-type,accept-language
  setResponseHeader Access-Control-Max-Age 600
  setResponseHeader Access-Control-Expose-Headers x-csrf-token,sap-rewriteurl,sap-url-session-id,sap-perf-fesrec,sap-system
  setResponseHeader Access-Control-Allow-Credentials true
if %{HEADER:isSACOriginAllowed} = true [AND]
  regRewriteUrl ^/(.*) /sap/public/ping
  removeResponseHeader Set-Cookie
  removeResponseHeader Expires

kindly replace {SAC_HOSTNAME} with your SAC host name(s) (including port if none standard), you may also adapt the pattern to meet your requirement (http or https or both ..).

Make sure you have enabled the /sap/public/ping service as this is used to handle the OPTIONS HTTP request.

Finally you have to restart your ABAP system.”

Now BW/4HANA will send CORS headers when the request is coming from the SAC domain. If you are using a Web Dispatcher in front of BW/4HANA then please perform the aforementioned step on the Web Dispatcher instead of on the BW/4HANA server. Always the last node (which is “nearest” to SAC) must be configured to send the CORS headers.

This is technically everything we need to use the direct live data connection. But as we also want to use SAML SSO some more steps need to be performed.

First ensure that the InA package (/sap/bw/ina/service/v2) or a higher-level package is configured for SAML authentication with your chosen IdP.

To enable SAML SSO from SAC to BW/4HANA we must provide some dummy HTML file which is used to authenticate the user and follow the SAML HTTP redirects. The setup is straight forward and documented in detail in the SAC manual:

  • Enter transaction code in BW/4HANA: SICF.
  • Enter Service Path/sap/bw/ina, and then press Enter.
  • Under default_host > sap > bw, right click ina, then choose New Sub-Element.
  • In Service Name, enter auth.
  • Add a description.
  • Open the Handler List tab, and enter ZCL_DUMMYAUTH_SERVICE
  • Save and return to the main menu.
  • Enter transaction code: SE24.
  • Enter Object TypeZCL_DUMMYAUTH_SERVICE, select Create, and then select Save.
  • Go to the Interfaces tab, and add IF_HTTP_EXTENSION, plus a description.
  • Go to the Methods tab, and add the following information:
    • LevelInstance Method
    • VisibilityPublic
    • Description: Add a description
  • Double click on IF_HTTP_EXTENSION~HANDLE_REQUEST and add the following code:
          html_content TYPE string.

    html_content = '<html><script type="text/javascript">open(location, '_self').close();</script></html>'.
    server->response->set_cdata( data = html_content ).
  • Select Save.
  • (Optional) Check if the auth package is installed.
    Open the following URL in your browser: https://<Your_ABAP_System>/sap/bw/ina/GetServerInfo?sap-client=<Your_Client_ID>. Make sure you are redirected to your IdP login page, and that you do not get 404 page after login. Replace <Your_ABAP_System> with your ABAP system host, and <Your_Client_ID> with your SAP BW client ID.

As you can see the HTML file does nothing except closing the window. This is required as SAC will trigger this URL (/sap/bw/ina/auth). As this URL is SAML protected the browser will be redirected to the IdP. The IdP will then recognize that you are already authenticated (when logging in to SAC) and have a session. So your browser follows the redirects by the IdP and finally the HTML content is delivered which closes the pop up.

Browser setup

Your browser (Chrome) must allow 3rd party cookies and pop ups from the SAC domain. This can be easily configured in the Chrome settings menu:


SAC setup

Ensure that you have setup trust between your IdP (in this case IAS) and SAC. This can be configured in the SAC admin panel: Enabling SAML Single Sign-On (SSO).

In case your IdP delivers the User ID in mixed case (e.g. KesslerSimon) then you cannot use the user id as the user attribute. In SAC all user ids are uppercase and the comparison is case sensitive. If this is the case for you then choose Custom SAML User Mapping which allows you to enter case sensitive attributes (here: the user id). In SAML you have a NameID attribute which identifies a user in the system. This attribute is compared against SAC and if it matches the user is allowed to access. That’s why we use custom SAML user mapping which enables SAC to compare this NameID attribute (coming from your IdP) against a custom attribute in your SAC user list. When using this configuration the user id in SAC (first column in the Users menu) is not relevant anymore for the IdP and can contain any string.

Now we can proceed to setup the connection to BW/4HANA:

  1. Create connection “Live”
  2. Specify the BW/4HANA domain
  3. Specify the client
  4. Select SAML
  5. Press OK


Now a pop up window should appear and immediately close. That’s it! Now you can create models from your direct live data connection to BW/4HANA.


Currently the live data connection from SAC to SAP BW is supported for the following BW versions:

  • SAP BW 7.4 SP17+
  • SAP BW 7.5 SP7+
  • SAP BW on any DB / on HANA

The information access (InA) service and SAML must be activated on the BW/4HANA system.


When you experience any issues please first try to clear your browser cache or perform the steps in a Chrome incognito window to rule out any old sessions getting in your way.


You have learned an alternative and recommended setup to use the live connection to BW/4HANA without a reverse proxy by using CORS. Additionally we have set up SAML SSO for convenient query consumption.


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Sebastian Ostermann
      Sebastian Ostermann

      Does this also apply to SAP BW (7.4) on HANA?

      Thanks in advance.

      Author's profile photo Sebastian Ostermann
      Sebastian Ostermann

      Forget my question. I read over the section requirements.

      Author's profile photo Simon Kessler
      Simon Kessler
      Blog Post Author

      As you have already noticed this setup works for any BW system which uses NetWeaver 7.4+ (as this is the requirement to inject the CORS headers in the response).

      Author's profile photo Sebastian Ostermann
      Sebastian Ostermann


      What about two-tier/three-tier landscapes in regards to productive and development environments? How is this working in this scenario?

      Author's profile photo Simon Kessler
      Simon Kessler
      Blog Post Author

      In this scenario you would need multiple SAC tenants. You might get away with a single SAC tenant if your user base is not too large. For large scale rollouts multiple SAC tenants are recommended. Then you could connect each tenant to each BW system, depending on your requirements.

      It might be best to set up a workshop to clarify such architectural questions as this is highly dependent on your use case.

      Author's profile photo Sebastian Ostermann
      Sebastian Ostermann

      So in a two-tier landscape I have to pay two SAC-tenants per user, one for dev and one for prod?

      Author's profile photo Simon Kessler
      Simon Kessler
      Blog Post Author

      There are different pricing options available for multi tenant setups. For pricing related questions please get in touch with SAP Sales. They will help you with the pricing models.

      Author's profile photo Gregor Schumann
      Gregor Schumann

      Are there any obstacles to use two different IdP's: One for SSO against SAC and one for SSO against backend? Of course I have to maintain user redundantly

      Author's profile photo Simon Kessler
      Simon Kessler
      Blog Post Author

      I did not test this setup but I am wondering what the purpose of such an architecture should be? With SSO you normally want one IdP only.

      Author's profile photo Sebastian Ostermann
      Sebastian Ostermann

      Regarding landscape options you mentioned in your previous article the option Single-Tenant-Multiple-Proxy. Is this also applicable when using CORS or do I need a second (test) SAC tenant?

      Author's profile photo Simon Kessler
      Simon Kessler
      Blog Post Author

      With CORS this is not possible and a second test tenant is recommended. You could also decide to live with the downtime as described in the post.

      Author's profile photo Francisco Almeida
      Francisco Almeida

      Hi, great article.

      Could you please clarify why you decided to use IAS IdP to pass through credentials to Azure IdP? Why not integrate SAC directly to Azure and keep a single IdP?


      Author's profile photo Simon Kessler
      Simon Kessler
      Blog Post Author

      Customers often want to have a single IdP for all SAP cloud services which IAS can be.

      Additionally SAP is providing IAS as the central IdP to offer SSO for all cloud services without additional setup. So using IAS is simplifying and future proofing the setup.

      Author's profile photo sandeep karnati
      sandeep karnati

      Hello Simon,

      Do i need to configure SSO between AD and BW4HANA(Netweaver) inorder to define live connection to BW4HANA system using SSO?



      Author's profile photo Simon Kessler
      Simon Kessler
      Blog Post Author


      Yes you would configure SSO between BW/4HANA and AD.

      Author's profile photo sandeep karnati
      sandeep karnati

      thank you!!!

      And while configuring sso between netweaver and AD,if there more than one app server in BW/4HANA,do i need to export the matadata file from all app servers,and import them on to AD?

      Author's profile photo Selvarasan Subramanian
      Selvarasan Subramanian

      Dear Simon Kessler ,

      I have query regarding SSO. For SSO to SAC We wil be using IAS which pass through all authentication to azure AD. For backend SSO we plan to have ADFS since bw4hana and adfs is on-premise. Is this setup possible , please advise ? As SAP guide states that both SSO to be with same idp

      Apart from SAC we have other cloud apps as well.


      Please advise !