SAP

Author

Dong Pan

Dong Pan

Dong Pan is Senior Director, SAP Analytics Cloud Customer First with SAP Canada. He is a passionate about creating seamless solution integration and connectivity technologies in the cloud landscape.

Keep in touch

Subscribe for the latest news, updates, tips and more delivered right to your inbox.

Subscribe to updates

Category

Learning

Connect with us

In this blog post, I would like to inform you of the critical impact of the upcoming Google Chrome 80 release on SAP Analytics Cloud (SAC) Direct Live Connections, and provide you with the solutions to resolve the problem. At the time of writing this blog post, Google Chrome 80 with this disruptive change is planned to release in the week of Feb 17, 2020 in a phased approach (SameSite Updates).

For a list of frequently-asked questions, refer to FAQ: SameSite Cookie and Direct Live Connections in SAP Analytics Cloud.

To help you fast forward to the section that most interests you, see the table of contents below.

The Impact of SameSite Cookies

Solutions

Alternative Solution by Changing Browser Setting

 

The Impact of SameSite Cookie

With SAC Direct live data connections, backend data source systems, including SAP HANA on-premises, HANA on SAP Cloud Platform (SAPCP) Cloud Foundry (CF), SAP Business Warehouse (BW), SAP S/4HANA, SAP Business Planning and Consolidation (BPC) and SAP BusinessObjects Business Intelligence Universe (BI Universe), issue browser cookies as part of an essential mechanism for user authentication and session management. As the Direct Live Connection traffic is channeled in CORS requests toward the backend system instead of the SAC site, the cookies issued by the backend systems are considered Third-Party Cookies. As a quick refresher, if you are not familiar with First-Party cookies and Third-Party Cookies: First-Party Cookies are the cookies that match the current site, i.e. the URL displayed in the web browser’s address bar; Third-Party Cookies are cookies issued by other sites that don’t match the current URL in the web browser’s address bar.

To address general security and privacy challenges around Third-Party Cookies, RFC6265bis introduced a SameSite attribute to cookies. Web application developers can use this attribute to state the intent of the cookie and provide end users with a more secure experience. There are three possible values (case-insensitive) for the SameSite attribute:

Strict: If a cookie’s SameSite attribute is set to Strict, the cookie will only be sent by the browser in a First-Party context. In other words, the cookie is only sent back to the web server if the cookie matches the site currently shown in the browser’s address bar. However, if the user opens the URL by following a link, such as a link from another site or an email, the cookie will not be sent back to the web server.

Lax: If a cookie’s SameSite attribute is set to Lax, the web browser’s behavior is the same as that of SameSite=Strict, except the cookie will be sent back to the web server if the user opens the URL by following a link.

None: If a cookie’s SameSite attribute is set to None, the web browser will send back the cookie to the web server in the Third-Party context.

To encourage wider adoption of the SameSite attribute, the IETF proposal, Incrementally Better Cookies, suggests the following two changes:

  • Cookies without the SameSite attribute is treated as SameSite=Lax
  • Cookies with the SameSite attribute set to None must also be set with the Secure attribute, which means the cookie will only be sent in the HTTPS context.

The upcoming Google Chrome 80 release will adopt the above IETF proposal as its default behavior. None of the above-mentioned SAP systems issues cookies with the SameSite attribute by default. As a result, user authentication with the Direct live connections will fail, and SAC stories based on Direct live connections will not be able to render.

Note that Chrome 80 released on Feb 4, 2020 does not include this change. The behavior change will start to rollout to Chrome 80 on Feb 17, 2020 in a phased approach (SameSite Updates).

 

Solutions

In order to solve the problem caused by the change of web browser behavior, the backend systems need to set the following two cookie attributes for all cookies:

  • SameSite=None
  • Secure

In addition, certain web browser versions are incompatible with the SameSite cookie attribute, i.e. those versions of web browser would reject cookies set with the SameSite attribute. As the end users may be using various versions of web browsers, we need to make sure that the SameSite cookie attribute is only set for compatible web browser versions.

To implement the solution, various steps must be carried out on different types of systems. Let me elaborate them respectively below. Note that the steps require a system restart, so plan ahead for a short system downtime window. Refer to SAP Note 2887651 for more details on the solutions for NetWeaver-based systems (BW, S4, BPC) and SAP HANA.

 

SAP NetWeaver-based systems (BW, S4, BPC) with CORS enabled by HTTP Whitelists

If CORS was enabled through HTTP Whitelists, or in other words, if CORS was configured within the UCONCOCKPIT transaction, you need to create an ICM rewrite rule file to append the SameSite=None and the Secure attributes to all the cookie issued by the NetWeaver system.

1) Log on to the NetWeaver system from SAPGUI with a system administrator user account. Go to transaction RZ10 and edit the NetWeaver system’s DEFAULT profile. Enable HTTP rewriting and point to the rewrite file by adding the below profile parameter. In the below example, the rewrite file is the rewrite.txt in the system profiles’ folder.

icm/HTTP/mod_0 = PREFIX=/,FILE=$(DIR_PROFILE)/rewrite.txt

2) In the rewrite.txt file, add the following rewrite script to append the cookie attributes to compatible web browsers, and save it.

SetHeader sap-ua-protocol ""

if %{HEADER:clientprotocol} stricmp http [OR]

if %{HEADER:x-forwarded-proto} stricmp http [OR]

if %{HEADER:forwarded} regimatch proto=http

begin

    SetHeader sap-ua-protocol "http"

end

if %{HEADER:clientprotocol} stricmp https [OR]

if %{HEADER:x-forwarded-proto} stricmp https [OR]

if %{HEADER:forwarded} regimatch proto=https

begin

    SetHeader sap-ua-protocol "https"

end

if %{HEADER:sap-ua-protocol} strcmp "" [AND]

if %{SERVER_PROTOCOL} stricmp https

begin

    SetHeader sap-ua-protocol "https"

end

if %{RESPONSE_HEADER:set-cookie} !strcmp "" [AND]

if %{HEADER:sap-ua-protocol} stricmp https [AND]

if %{HEADER:user-agent} regmatch "^Mozilla" [AND]

if %{HEADER:user-agent} !regmatch "(Chrome|Chromium)/[1-6]?[0-9]\." [AND]

if %{HEADER:user-agent} !regmatch "(UCBrowser)/([0-9]|10|11|12)\." [AND]

if %{HEADER:user-agent} !regmatch "\(iP.+; CPU .*OS 12_.*\) AppleWebKit\/" [AND]

if %{HEADER:user-agent} !regmatch "\(Macintosh;.*Mac OS X 10_14.*(Version\/.* Safari.*|AppleWebKit\/[0-9\.]+.*\(KHTML, like Gecko\))$"

begin

    RegIRewriteResponseHeader set-cookie "^([^=]+)(=.*)" "$1$2; SameSite=None; Secure"

    RegIRewriteResponseHeader set-cookie "^([^=]+)(=.*; *SameSite=[a-zA-Z]+.*); SameSite=None; Secure" $1$2

    RegIRewriteResponseHeader set-cookie "^([^=]+)(=.*; *Secure.*); Secure" $1$2

end

3) Restart the NetWeaver system.

 

SAP NetWeaver-based systems (BW, S4, BPC) with CORS enabled by ICM rewrite script

If CORS was enabled with an ICM rewrite script, the NetWeaver system already has an existing ICM rewrite file. To append the SameSite and Secure cookie attributes to the cookies, follow the steps below:

1) Find the ICM rewrite file’s path by inspecting the profile parameter icm/HTTP/mod_0 in the system’s DEFAULT profile.

2) Log on to the operating system with the <SID>adm user.

3) Edit the ICM rewrite file. At the end of the file, append the following script:

SetHeader sap-ua-protocol ""

if %{HEADER:clientprotocol} stricmp http [OR]

if %{HEADER:x-forwarded-proto} stricmp http [OR]

if %{HEADER:forwarded} regimatch proto=http

begin

    SetHeader sap-ua-protocol "http"

end

if %{HEADER:clientprotocol} stricmp https [OR]

if %{HEADER:x-forwarded-proto} stricmp https [OR]

if %{HEADER:forwarded} regimatch proto=https

begin

    SetHeader sap-ua-protocol "https"

end

if %{HEADER:sap-ua-protocol} strcmp "" [AND]

if %{SERVER_PROTOCOL} stricmp https

begin

    SetHeader sap-ua-protocol "https"

end

if %{RESPONSE_HEADER:set-cookie} !strcmp "" [AND]

if %{HEADER:sap-ua-protocol} stricmp https [AND]

if %{HEADER:user-agent} regmatch "^Mozilla" [AND]

if %{HEADER:user-agent} !regmatch "(Chrome|Chromium)/[1-6]?[0-9]\." [AND]

if %{HEADER:user-agent} !regmatch "(UCBrowser)/([0-9]|10|11|12)\." [AND]

if %{HEADER:user-agent} !regmatch "\(iP.+; CPU .*OS 12_.*\) AppleWebKit\/" [AND]

if %{HEADER:user-agent} !regmatch "\(Macintosh;.*Mac OS X 10_14.*(Version\/.* Safari.*|AppleWebKit\/[0-9\.]+.*\(KHTML, like Gecko\))$"

begin

    RegIRewriteResponseHeader set-cookie "^([^=]+)(=.*)" "$1$2; SameSite=None; Secure"

    RegIRewriteResponseHeader set-cookie "^([^=]+)(=.*; *SameSite=[a-zA-Z]+.*); SameSite=None; Secure" $1$2

    RegIRewriteResponseHeader set-cookie "^([^=]+)(=.*; *Secure.*); Secure" $1$2

end

4) Restart the NetWeaver system.

 

SAP HANA On-Premises

HANA comes with a built-in Web Dispatcher where an ICM rewrite rule can be executed similarly to NetWeaver ABAP systems. To do that, follow the below steps:

1) Log on to the HANA system’s operating system with the <SID>adm user.

2) Go to /hana/shared/<SID>/profile, and create the rewrite.txt file with a text editor. Insert the following script into the file, and save it.

SetHeader sap-ua-protocol ""

if %{HEADER:clientprotocol} stricmp http [OR]

if %{HEADER:x-forwarded-proto} stricmp http [OR]

if %{HEADER:forwarded} regimatch proto=http

begin

    SetHeader sap-ua-protocol "http"

end

if %{HEADER:clientprotocol} stricmp https [OR]

if %{HEADER:x-forwarded-proto} stricmp https [OR]

if %{HEADER:forwarded} regimatch proto=https

begin

    SetHeader sap-ua-protocol "https"

end

if %{HEADER:sap-ua-protocol} strcmp "" [AND]

if %{SERVER_PROTOCOL} stricmp https

begin

    SetHeader sap-ua-protocol "https"

end

if %{RESPONSE_HEADER:set-cookie} !strcmp "" [AND]

if %{HEADER:sap-ua-protocol} stricmp https [AND]

if %{HEADER:user-agent} regmatch "^Mozilla" [AND]

if %{HEADER:user-agent} !regmatch "(Chrome|Chromium)/[1-6]?[0-9]\." [AND]

if %{HEADER:user-agent} !regmatch "(UCBrowser)/([0-9]|10|11|12)\." [AND]

if %{HEADER:user-agent} !regmatch "\(iP.+; CPU .*OS 12_.*\) AppleWebKit\/" [AND]

if %{HEADER:user-agent} !regmatch "\(Macintosh;.*Mac OS X 10_14.*(Version\/.* Safari.*|AppleWebKit\/[0-9\.]+.*\(KHTML, like Gecko\))$"

begin

    RegIRewriteResponseHeader set-cookie "^([^=]+)(=.*)" "$1$2; SameSite=None; Secure"

    RegIRewriteResponseHeader set-cookie "^([^=]+)(=.*; *SameSite=[a-zA-Z]+.*); SameSite=None; Secure" $1$2

    RegIRewriteResponseHeader set-cookie "^([^=]+)(=.*; *Secure.*); Secure" $1$2

end

3) Start SAP HANA Studio.

4) Select the HANA System connection. Note: if HANA system is multi-tenanted, use the SYSTEMDB connection.

5) Right-click the HANA system. On the context menu, click on Configuration and Monitoring -> Open Administration.

6) Click on the Configuration tab, and expand webdispatcher.ini -> profile.

7) Right-click on profile, and select Add Parameter.

8) Add a new parameter named "icm/HTTP/mod_0" and value "PREFIX=/, FILE=/hana/shared/<SID>/profile/rewrite.txt". Replace <SID> with your HANA system’s system ID.

9) Switch to the Landscape tab. Right-click on webdispatcher, and click Kill…. HANA’s Web Dispatcher will shutdown and restart automatically. Alternatively, you may restart the entire HANA system for the new parameter to take effect.

 

HANA on SAPCP Cloud Foundry (CF)

For HANA on SAPCP CF, we will take a slightly different approach to solve the issue. All cookies from the HANA on SAPCP CF system already carry the Secure attribute. We will rebuild the AppRouter application so that it issues cookies with the proper SameSite attribute.

As the steps could become a little lengthy, I will be referring to the end-to-end guided playlist SAP HANA HDI in SAP Cloud Platform Cloud Foundry (live) to help you locate where the steps fit into the overall configuration flow.

1) On your local machine where the AppRouter application was originally built, go to directory <HAA_ROOT>, where <HAA_ROOT> is the Multi-Target Application that was built initially.

2) This step corresponds to Step 3 in the above-mentioned guided playlist. Open mta.yaml with a text editor. Look for the application section where type is set to node.js, and this is the AppRouter application that we need to modify. It may have different names such as xsahaa-rt or haa. Note down the application path. In the below example, the application path is approuter.

 - name: xsahaa-rt

  type: nodejs

  path: approuter

For the rest of the configuration steps, the application path will be referred to as <approuter_path>.

3) Add a COOKIES sub-section underneath properties, right above the CORS sub-section. In the COOKIES sub-section, add the SameSite attribute and set it to None. Leave the rest of the properties section unchanged. The configuration should look like the following.

properties:

COOKIES: >

     { "SameSite": "None" }

CORS: >

[

{

"uriPattern": "^/sap/bc/ina/(.*)$",

"allowedOrigin": [

{"host":" <sac-tenant-host>", "protocol":"https", "port" : ""}

],

"allowedMethods": ["GET", "POST", "HEAD", "OPTIONS", "PUT", "DELETE"],

"allowedHeaders": ["Origin", "Accept", "X-Requested-With", "Content-Type", "Access-Control-Request-Method", "Access-Control-Request-Headers", "Authorization", "X-Sap-Cid", "X-Csrf-Token"],

"exposeHeaders": ["Accept", "Authorization", "X-Requested-With", "X-Sap-Cid", "Access-Control-Allow-Origin", "Access-Control-Allow-Credentials", "X-Csrf-Token", "Content-Type"]

}

]

TENANT_HOST_PATTERN: '^(.*)-<space>-xsahaa-rt.cfapps.(.*).hana.ondemand.com'

Save the file.

4) Go to folder <HAA_ROOT>/<approuter_path>, and open package.json with a text editor. Change the dependency to 6.7.2. The dependencies section should look like below.

"dependencies": {

"@sap/approuter": "^6.7.2"

},

Save the file.

5) In a Command Prompt window, go to <HAA_ROOT> directory and run the following commands. It will automatically build a new version (i.e. version 6.7.2) of the AppRouter application, generate a file named <HAA_ROOT>.mtar, and deploy the Multi-Target Application to CF. Refer to Step 4 of the above-mentioned guided playlist to retrieve the actual value of <api-endpoint>.

java -jar mta.jar --build-target=CF build

cf api <api-endpoint>

cf login

cf deploy <HAA_ROOT>.mtar
6) Verify the new version of the AppRouter application. Go to CF account cockpit, and then check the AppRouter application’s User Provided Variables. Make sure that the COOKIES variable is set to {“SameSite: “None”}.

 

SAP BI Universe

The SAP BusinessObjects Live Data Connect component, together with the Tomcat server that it runs on, already issues cookies with the Secure attribute. We just need to configure the Live Data Connect component to issue cookies with the SameSite attribute set to None.

1) Check the version of the Tomcat server where the Live Data Connect component runs. If the Tomcat version is lower than 8.5.50 or 9.0.30, upgrade or migrate it to at least 8.5.50 or 9.0.30, respectively. See the migration guides at http://tomcat.apache.org/migration.html.

2) If you upgraded or migrated your Tomcat server, make sure to migrate the Live Data Connect component as well. This can be done by copying the “sap#boc#ina.war” file and the “sap#boc#ina” directory under <original_tomcat_root>/webapps to the new Tomcat server. Make sure all the Live Data Connect settings are preserved, and HTTPS is properly configured. For more details, refer to Configuring SAP BusinessObjects Live Data Connect and Setting up SAML authentication.

3) Go to <Tomcat_root>/webapps/sap#boc#ina/METADATA-INF directory.

4) Open the context.xml file in a text editor, and insert the CookieProcessor segment to set the SameSite attribute to None. It should look like below:

<Context docBase="" path="/sap/boc/ina" reloadable="false" useHttpOnly="true">

<CookieProcessor className="org.apache.tomcat.util.http.LegacyCookieProcessor" sameSiteCookies="none" />

</Context>

Save the file.

5) Restart the Tomcat server.

For more details, refer to SAP Note 2889975.

 

Alternative Solution by Changing Browser Setting

Alternatively, in case you are unable to schedule a downtime window for the SAP backend systems in time, you may apply a group policy on your users’ Chrome browser to turn off this new browser behavior temporarily. It is recommended that the setting be rolled out on a corporate level via an automated group policy, instead of asking each individual end user to manually change their Windows registry settings or Mac/Linux preferences.

Note that this new browser behavior can be turned off on a per-site basis, so it is recommended that for maximum security, you configure this setting for the affected backend system hosts only. More details of the policy can be found here: https://www.chromium.org/administrators/policy-list-3/cookie-legacy-samesite-policies.

At the time of writing this blog post, it is unclear how long the above Chrome policies will be maintained. According to the update on Feb 10, 2020 at SameSite Updates, those policies “will be available for at least 12 months after the release of Chrome 80 stable”. It is therefore important to choose the server-side solutions described in this blog post as your long-term, stable solution.

SAP Analytics Cloud earns a top ranking from BARC

See how SAP Analytics Cloud performed in the world’s largest survey of Business Intelligence software users.