As mentioned in my wiki SAP Analytics Cloud Connectivity Guideline, SAP Analytics Cloud provides Live Connectivity for local and remote data sources such as HANA, BW, S4/HANA and BusinessObjects Universe. Customers often question about security mechanisms and recommendations enabling secured live connection. This document intents to provide necessary information about security with Live Connection settings.
For general information about SAP Cloud Security, please read first the following web site : https://www.sap.com/about/cloud-trust-center.html
With Live Connection, data securely remain in your back-end and query are performed in your data source server. Result of query is sent back to your browser which renders your Dashboard. Browser interacts directly or thru proxy with SAP Analytics Cloud, identity provider and all connected data sources. Then browser manages three types of communication tunnel:
- Get/Post requests from Browser to SAP Analytics Cloud are dedicated to metadata.
- Get/Post requests from Browser to Identity Provider are dedicated to SAML 2 Assertions.
- Get/Post/Options requests from Browser to Back-end data sources are dedicated to Data.
In examples above, identity provider is SAP Cloud Identity, a Software as a Service application provided by default with any SAP Analytics Cloud tenant. It is a public service available over public internet. For security reason, you could choose your own Identity Provider located in your own network domain to get a more secured configuration.Your identity provider must support SAML2 identity federation protocol. Obviously, the use of HTTPS with valid SSL certificate is mandatory.
What is Metadata?
Connection definition: Browser use these information’s to establish live connection to data sources (HANA, BW, S4/HANA, Universe)
Connection name, description, data source server and port, preferred language
No User and Password are stored in SAC live connection description. It is the reason we recommend implementing SAML2 SSO with data sources to avoid User and Password credentials when you run story with live connection.
Model definition: Based on connection definition, model defines query on your data source based on data source metadata.
Linked data source query (BEX query name, calculation views name, BOE universe name)
No data or dimension value from data sources are stored in SAC for live connection, except values of filters and input controls used in query if any.
Story definition: Based on models, story defines dashboard.
Linked models, story description, layout, labels, styling, page names, RSS feed definition, embedded HTML, Images, conditional formatting rules, linked analysis, navigation, chart types, chart positions in story, specific chart parameters (color and styling, comment, variance definition, reference line definition, top N parameter, sorting parameter, all parameters depending on type of chart), filter values, formulas, linked column relationships for filtering (Live connection), story defined variables, etc.
No data or dimension value from data sources are stored in SAC for live connection, except value of filter if any.
Let's take the following example, given the following data:
The column names (but not data in those columns) would be stored in SAP analytics Cloud;
MetaData are :
“ID”, “Name”, “Phone Number”, “Salary”
Data are :
1, Alex Bean, 555-324-2342, $80,000
2, Corey Foo, 777-234-2318, $100,000
If you build a dashboard/story with a filter such as employees with salary >= $100,000
This filter itself would be saved in SAP Analytics Cloud, so ‘select * where salary is >= $100,000’, but not the results of the filter.
Because our cloud application never directly access customer data source in back-end (HANA, BW, Universe and S4/HANA), this ensures a no-compromise.
Everything goes through the user’s browser, and the user’s browser interacts with the data source system, sending queries & receiving results directly.
These never go to SAP Analytics Cloud.
As previously mentioned, data are not sent to, or stored in SAP Analytics Cloud tenant. Data stay in your back-end. Data are not replicated into SAP Analytics Cloud.
Live Connection is a browser-based communication. As soon as browser runs in customer domain, and explicitly in the same data source domain, there is no need to whitelist and expose data source end-points outside customer domain.
If customer wants to use live connection with browser outside secured customer domain, standard security mechanisms are supported (VPN, firewall, load balancer, proxies, etc.)
Then, with SAP Analytics Cloud, Customer can use their own existing security rules, VPN, proxies or firewall. Security can be enforced with multiple mechanisms already in place such as firewalls, proxies or load balancers.
We have already experienced many customer configurations. Feel free to get advices from SAP expertise’s.
Please find below some customer examples with Business User browser accessing data source in customer back-end from public domain:
Example of customer configuration with CORS and two DMZ
Communications must use HTTPS protocol with valid SSL certificates.
SSL/TLS aims primarily to provide privacy and data integrity between Browser, SAP Analytics Cloud, Identity Providers and Data Sources. The connection is private because symmetric cryptography is used to encrypt the data transmitted. The keys for this symmetric encryption are generated uniquely for each connection and are based on a shared secret negotiated at the start of the session.
By using HTTP SSL/TLS protocol, you prevent compromising on data, metadata or SAML assertions by creating a secured tunnel.
SAP Analytics Cloud
Mandatory https (valid SSL certificate provided by SAP)
Mandatory https (valid SSL certificate provided by customer)
Mandatory https (valid SSL certificate provided by customer or SAP if you use SAP Cloud Identity)
What is a valid SSL Certificate ?
Certificate has to follow some strict rules to be valid:
- Validity period : Current date has to be between NotBefore and NotAfter attributes
- Hostname : Often, Hostname (FQDN) has to be aligned with CN or/and SubjectAlternateName.
- DNS resolution issue: Hostname has to be resolved by any DNS server or hosts file.
CA Root Certificate missing or invalid: Mac or Windows comes with pre-installed Windows Trusted Root Authority certificates or Mac KeyChain utilities. These certificates are used across Mac, Windows and browsers to verify the identity of trusted websites. You can add your own Trusted CA Root certificate in your computer Trusted Root Authority .
Weak Hashing Algorithm: Certificate is hashed with sha-1 which is deprecated.
Common Name and Subject Alternate Name : You must generate a CSR from your webserver software. During the creation of the CSR, the following fields must be entered: Organization (O), Organizational Unit (OU), Country (C), State (S), Locality (L), and Common Name (CN). The Common Name field has to be filled correctly. The Common Name is typically composed of Host + Domain Name and will look like "www.myCompany.com” or “myCompany.com”. SSL Certificates are specific to the Common Name that they have been issued to at the Host level. The Common Name must match as the Web address you will be accessing when connecting to a secure site. HostName (FQDN) has to be solved in your DNS configuration.
What you have to know about Chrome Browser
Google Chrome is the supported browser to work with SAP Analytics Cloud. Chrome implements latest RFCs and requires some specific settings as explained below.
Subject Alternate Name
Since April 2017 (Chrome 58), Google Chrome gives error if its security certificate does not specify Subject Alternative Names (SAN).
RFC 2818 describes two methods to match a domain name against a certificate - using the available names within the subjectAlternativeName extension, or in the absence of a SAN extension, falling back to the commonName. The fallback to the commonName was deprecated in RFC 2818 but support still remains in some more permissive browser (ie. Internet Explorer).
What is the role of Subject Alternative Name?
- To secure host names on different domains with one certificate: The use of wildcard certificate can protect multiple host names, domains, or subdomains. Let’s take the following example with *.mycompany.com. You could protect any host name followed by domain name mycompany.com. However, a wildcard certificate cannot protect both www.mycompany.com and www.mycompany.net.
- Virtual host multiple SSL sites on a single IP address: Hosting multiple SSL-enabled sites on a single server typically requires a unique IP address, but a multi-domain certificate with Subject Alternative Names can solve this problem. For example, Apache is able to manage virtual host using multi-domain certificates. In HANA multi-tenant, WebDispatcher service, Virtual Host Name is used to address specific Database Tenant with a unique IP address.
- Greatly simplify your server's SSL configuration: Using a multi-domain certificate saves you the difficulty and time involved in configuring multiple IP addresses on your server, binding each IP address to a different certificate, and trying to piece it all together.
For more information :
SHA-1 is now deprecated
Since January 2017, Google has deprecated SHA-1 hash algorithm for SSL certificates.
The SHA-1 cryptographic hash algorithm first showed signs of weakness over 10 years ago and recent research points to the imminent possibility of attacks that could directly impact the integrity of the Web Public Key Infrastructure. To protect users from such attacks, Chrome stopped trusting certificates that use the SHA-1 algorithm, and visiting a site using such a certificate will result in a warning.
So, it is now recommended to use SHA-256 hash algorithm for your certificate.
Local browser persistence with Live Connection
All connectivity between SAC and browser is TLS 1.2. With https in general, data will not be cached in browser, but we do also explicitly use a no-cache, no-store directive in all our generated responses to add a (redundant) instruction to browser to never store the data.
Security Implication of Live Connection with CORS
A reminder of my wiki: SAP Analytics Cloud Connectivity Guideline.
The same-origin policy is an important concept in the web application security model. Under the policy, a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin. It is a critical security mechanism for isolating potentially malicious documents.
In Live Connection, browser accesses both SAP Analytics Cloud for metadata and back-end data sources (HANA, BW, S4/HANA or Universe).
So, SAP Analytics Cloud supports CORS to enable Cross Sharing Resources accessed by the same web page in browser.
CORS: Cross-origin resource sharing is a mechanism that allows restricted resources on a web page to be requested from another domain outside the domain from which the first resource was served. A web page may freely embed cross-origin web page, images, stylesheets, scripts, iframes, and videos.
If you want to implement CORS securely, in your data source back-end (HANA, BW, BOE universe) you need to associate a list of valid Origin with Access-Control-Allow-Origin that identifies which specific URI (such as SAP Analytics Cloud Tenant) can access resources. Then, your data source back-end can approve against this list.
Do not use * wildcard to define URI.
Furthermore, SAP Analytics Cloud first sends a preflight request to ask authorization from the back-end for GET method as follow:
Accept-Encoding: gzip, deflate, br
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.162 Safari/537.36
If back-end finds Origin URI from its list of authorized domains, response will be:
access-control-allow-headers: accept, authorization, content-type, x-csrf-token, x-request-with, x-sap-cid
access-control-allow-methods: GET, HEAD, OPTIONS, POST
In this example, I am authorized to request for GET, HEAD, OPTIONS and POST method from my valid Origin in the coming 3600 seconds.
The Access-Control-Max-Age indicates that preflight response is valid for 3600 seconds after which a new preflight request has to be issued. access-control-max-age parameter can be changed in your back-end settings.
The Access-Control-Allow-Headers Indicates which headers are supported by the response’s url for the purposes of the CORS protocol.
You can notice that data source returns x-csrf-token parameter. That means, data sources prevent to CSRF (Cross-site request Forgery), a type of attack, when attacker sends malicious requests from a website that user visits to another site where the victim is authenticated. Prevention from this attack is based on keeping additional random security token during user's session (with cookie) and providing it with every modify operation (PUT, POST, DELETE). If the provided token is not correct, Data Source responds with HTTP 403 ("Forbidden") return code.
CORS Origin settings
To enable CORS in HANA, BW, S4/HANA and Universe back-ends, please refer to documentation below:
In all settings above, you will have to set the Access-Control-Allow-Origin parameter with SAP Analytics Cloud Tenant URI. Please be strict in setting urI as follow :
your origin shoud be https://<customer-prefix>.<data-center>.sapbusinessobjects.cloud or https://<customer-prefix>.<data-center>.sapanalytics.cloud . Please check your tenant URI first.
- Common error : Do not add / at the end of URI. Browser sends only URI not path.
- Common error : Do not add * wildcard at the end of URI.
- Does not use * wildcard to define URI. It works but in such case you authorize all origins to access your back-end.
- Common error when customer switch configuration from Reverse Proxy to CORS : With CORS, you do not need to access SAP Analytics Cloud thru Reverse Proxy. Hence, if you have formerly used Reverse Proxy to access SAP Analytics, you do not need anymore and please do not use Reverse Proxy access, in such case URI Origin will be based on reverse proxy and you will get an error message.
Some Recommendations to implement CORS
- HTTPS communication is mandatory with valid and verifiable certificate. SAP Analytics Cloud does not accept HTTP for CORS.
- Do not use wildcard when you define list of valid Origin in your back-end
- Avoid multiple domains
- Be strict in setting Access-Control-Allow-Headers and Access-Control-Expose-Headers
- If you want to access data sources outside your secured domain, use VPN or any other security mechanisms
Security Implications on Data Sources
As mentioned in my wiki, SAP Analytics Cloud uses SAP Information Access Service (InA) as protocol to exchange with data sources. InA is a REST http-based protocol used to query in real time your data sources.
InA Protocol REST API Protocol mainly uses two types of request as follow:
This component is part of all supported back-end as follow:
SAP HANA 1.0 SPS10/11/12 – revision 102.2 or higher with SAP HANA Info Access Service (InA), version 4.10.0 or higher is required
SAP HANA 2.0 SP01 or newer on-premise, with the SAP HANA EPMMDS plugin installed on your SAP HANA 2.0 system. SAP Note 2456225 and SAP Note 2444261 provide additional setup information
SAP Cloud Platform (SAPCP): latest version
SAP BW/4HANA SP4+
SAP BW 7.4 SP17+
SAP BW 7.5 SP8+
SAP BusinessObjects BI 4.2 SP4 system installed. The .war file of the SAP BOE Live Data Connect component deployed on your application server
SAP NW release 7.51 SP2
- As mentioned above, we recommend using https as protocol to avoid any compromising activity.
- User can access InA only if they have privileges.
- All InA sessions start with authentication on back-end data source (User/Password, SAML2 SSO, SAP Logon Ticket).
- Settings of INA protocol requires necessary admin privileges on back-end side. Please be very cautious and accurate in allowing such privileges to avoid any compromising activity.
Data Source privileges to set INA service
To avoid any activity that may compromise the security and integrity of communications, it is also essential to have a strict control of the rights accessible by the users in charge of the commissioning of the connection.
XS admin privileges : sap.hana.xs.admin.roles::RuntimeConfAdministrator
Activation privilege on INA Package
for SAML2 SSO you need SAML2 privileges
BW / S4/HANA
RZ11, SICF, SE24 and NUCONCOCKPIT transaction access privileges
If you are using SAP NetWeaver version lower than 7.52, you will need to access rewriting rules file in Server folders (<SID>adm user access required).
Developer privilege is required to set Handler on auth services.
for SAML2 SSOyou need SAML2 transaction
Tomcat admin privilege
Data Source authentification with Live Connection
For each live connection data source you can set the following authentication :
|Data Source||Authentication methods||Comments|
User / Password
User/Password are never stored in SAP analytics Cloud metadata. SAC requests user authentication each time a Story requests a Live Connection.
SAML 2 SSO
Requires an Identity Provider (SAML2 support). Users are automatically mapped between, SAC, Identity Provider and Data Source.
|Enables other authentication such as SAP Logon Ticket|
|BW / S4/HANA|
User / Password
User Password are never stored in SAP analytics Cloud metadata . SAC requests user authentication each time a Story requests a Live Connection.
SAML 2 SSO
Requires an Identity Provider (SAML2 support). Users are automatically mapped between, SAC, Identity Provider and Data Source.
Enables other authentication such as SAP Logon Ticket
User / Password
User Password are never stored in SAP analytics Cloud metadata. SAC requests user authentication each time a Story requests a Live Connection.
|SAML 2 SSO||Requires an Identity Provider (SAML2 support). Users are automatically mapped between, SAC, Identity Provider and Data Source.|
SAML 2 SSO
|OAuth 2 SAML Bearer Assertion||Requires an Identity Provider (oAuth 2 support).|
See overall SAP security, and this includes the overall application level security attacks. This is covered by our Secure development lifecycle.
Thanks for reading