Foreword

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

Live Connection

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.

Browser is the central components for all interactions. Queries are built by browser-based Javascript and run by data source query services in your back-end as follow:

Simple Flow

SAML2 flow 

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. 

MetaData flow

What is Metadata?

I often got question from our customer about metadata details.  SAP Analytics Cloud Metadata are processed by browser-based Javascript for dashboard rendering. Metadata are fully encrypted. It is composed of all necessary information to build dashboard and query:

Example  

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. 

Data flow

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.

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 : 

• Creating Certificate with Subject Alternative Name using PSE Management 
• Create certificates with subject Alternative Name using STRUST

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.

CORS access

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:

Request 

Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en;q=0.9,en-US;q=0.8,fr;q=0.7
Access-Control-Request-Headers: authorization
Access-Control-Request-Method: GET
Connection: keep-alive
Host: hxehost.hxe:4390
Origin: https://mytenant.eu1.sapbusinessobjects.cloud
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:

Response

access-control-allow-credentials: true
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
access-control-allow-origin: https://mytenant.eu1.sapbusinessobjects.cloud
access-control-max-age: 3600
content-length: 0
content-type: text/html
vary: Origin

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:

• 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.

Data Source authentification with Live Connection

For each live connection data source you can set the following authentication : 

Best Reading 

See overall SAP security, and this includes the overall application level security attacks.  This is covered by our Secure development lifecycle. 

https://www.sap.com/about/cloud-trust-center.html

Thanks for reading