Google Chrome will start to roll out a disruptive change related to Third-Party Cookie in the week of Feb 17, 2020, which will cause all Direct live connections in SAP Analytics Cloud to fail. I have written a blog post Direct Live Connections in SAP Analytics Cloud and SameSite Cookies to explain the problem and our solutions in detail, and I would like to take this opportunity to cover some of the most frequently asked questions.
Q1: What are the impacted scenarios?
A：All Direct live connections, 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). Live connections to SCP Neo HANA and S/4HANA Cloud Edition are not impacted. The deprecated PATH-based live data connections are not impacted.
Q2: I have Google Chrome 80, but it seems that I am not impacted. Why?
A: Chrome 80 was released on Feb 4, 2020, without this disruptive behavior turned on. Google will start to roll out the new behavior to Chrome 80 in the week of Feb 17, 2020 in a phased approach, i.e. not all Chrome 80 users will get this disruptive “feature” turned on by default right away.
Q2: Does the solution require a system downtime?
A: Yes. The configuration changes on the systems require a system restart to take effect, so plan the system downtime accordingly. In case of SAP HANA, as the only component that needs restart is the built-in Web Dispatcher instead of the entire HANA system, usually it takes less than a couple of minutes to restart, which might make the downtime planning a little easier. Be careful with configuring the parameters when copy & pasting, which could sometimes add unwanted whitespaces, line breaks, etc, as wrong parameters could potentially cause startup failure of the backend systems.
If there is not enough time to plan the system downtime prior to Feb 17, 2020, you could temporarily turn off this new browser behavior. See the details in the Alternative Solution section in the blog post. Note that this setting can be turned off per site, so there shouldn’t be any security concern if it is turned off only for the SAP backend systems. See Q6 for more details.
Q4: What about other web browsers?
A: Microsoft Edge has a plan to adopt this cookie feature at a later time, but the exact date has not been published yet. The solution has already taken multiple browsers and their versions into consideration.
Q5: We have a Web Dispatcher in front of the backend systems for the Internet scenario / Load balancing scenario, and CORS was turned on in the Web Dispatcher instead of on the backend system. Should we follow the same steps?
A: We have always advised against enabling CORS on the Web Dispatcher, i.e. CORS should be turned on in the backend system directly according to our best practices. For this particular issue, the additional rewrite rules can be added either in the backend system or in the Web Dispatcher, but we do recommend putting the rewrite rules on the backend systems directly if possible.
Q6: With the solution, we are setting the SameSite cookie attribute to None. Does this reduce the level of security?
A: No. The SameSite=Lax default does not increase the security of SAP applications because they have already implemented protection against cross-site request forgery (CSRF) attacks. The only thing the rewrite rule does is to restore the previous default of SameSite=None. It does not cause any additional or new security risks. See more details in Note 2887651.
Q7: There are certain browser versions that are incompatible with the SameSite cookie attribute. Will the solution cause problems to those users?
A: The solution for SAP HANA on-premises and NetWeaver-based systems (BW, S4, BPC) has already taken browser compatibility into consideration, and will not issue the SameSite cookie attribute to incompatible browser versions.
Q8: Is it necessary for end users to clear browser cookies manually for the solution to take effect?
A: No. The cookies used in Direct live connections are session cookies instead of persistent cookies, so they are not stored to the end user’s disk. The solution is a 100% server-side solution.
Q9: Does the issue affect the SAML 2 Identity Providers used in initial SAC authentication and Single Sign-On in Direct live connections in any way?
A: No. In the context of 1) initial SAC user authentication and 2) SSO to Direct live connections, the SAML 2 Identity Provider is not considered a Third-Party site, therefore they are not impacted.
Q10: For direct live connections to HANA on-premise, BW, S4, BPC, we are adding a Secure attribute to all cookies as part of the solution to resolve this issue. Cookies with the Secure attribute will not be sent back to the issuing server. Would the solution impact other web applications on HANA and NetWeaver systems when accessed with plain HTTP instead of HTTPS?
A: The ICM rewrite rule detects whether the web browser is accessing the service with HTTP. If that is the case, the Secure attribute will not be added to the cookies. This makes sure that the HTTP scenario is not impacted.
I hope the above FAQ has been helpful in clarifying any confusion with this critical issue.
Stay tuned.
Okumaya devam et...
Q1: What are the impacted scenarios?
A：All Direct live connections, 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). Live connections to SCP Neo HANA and S/4HANA Cloud Edition are not impacted. The deprecated PATH-based live data connections are not impacted.
Q2: I have Google Chrome 80, but it seems that I am not impacted. Why?
A: Chrome 80 was released on Feb 4, 2020, without this disruptive behavior turned on. Google will start to roll out the new behavior to Chrome 80 in the week of Feb 17, 2020 in a phased approach, i.e. not all Chrome 80 users will get this disruptive “feature” turned on by default right away.
Q2: Does the solution require a system downtime?
A: Yes. The configuration changes on the systems require a system restart to take effect, so plan the system downtime accordingly. In case of SAP HANA, as the only component that needs restart is the built-in Web Dispatcher instead of the entire HANA system, usually it takes less than a couple of minutes to restart, which might make the downtime planning a little easier. Be careful with configuring the parameters when copy & pasting, which could sometimes add unwanted whitespaces, line breaks, etc, as wrong parameters could potentially cause startup failure of the backend systems.
If there is not enough time to plan the system downtime prior to Feb 17, 2020, you could temporarily turn off this new browser behavior. See the details in the Alternative Solution section in the blog post. Note that this setting can be turned off per site, so there shouldn’t be any security concern if it is turned off only for the SAP backend systems. See Q6 for more details.
Q4: What about other web browsers?
A: Microsoft Edge has a plan to adopt this cookie feature at a later time, but the exact date has not been published yet. The solution has already taken multiple browsers and their versions into consideration.
Q5: We have a Web Dispatcher in front of the backend systems for the Internet scenario / Load balancing scenario, and CORS was turned on in the Web Dispatcher instead of on the backend system. Should we follow the same steps?
A: We have always advised against enabling CORS on the Web Dispatcher, i.e. CORS should be turned on in the backend system directly according to our best practices. For this particular issue, the additional rewrite rules can be added either in the backend system or in the Web Dispatcher, but we do recommend putting the rewrite rules on the backend systems directly if possible.
Q6: With the solution, we are setting the SameSite cookie attribute to None. Does this reduce the level of security?
A: No. The SameSite=Lax default does not increase the security of SAP applications because they have already implemented protection against cross-site request forgery (CSRF) attacks. The only thing the rewrite rule does is to restore the previous default of SameSite=None. It does not cause any additional or new security risks. See more details in Note 2887651.
Q7: There are certain browser versions that are incompatible with the SameSite cookie attribute. Will the solution cause problems to those users?
A: The solution for SAP HANA on-premises and NetWeaver-based systems (BW, S4, BPC) has already taken browser compatibility into consideration, and will not issue the SameSite cookie attribute to incompatible browser versions.
Q8: Is it necessary for end users to clear browser cookies manually for the solution to take effect?
A: No. The cookies used in Direct live connections are session cookies instead of persistent cookies, so they are not stored to the end user’s disk. The solution is a 100% server-side solution.
Q9: Does the issue affect the SAML 2 Identity Providers used in initial SAC authentication and Single Sign-On in Direct live connections in any way?
A: No. In the context of 1) initial SAC user authentication and 2) SSO to Direct live connections, the SAML 2 Identity Provider is not considered a Third-Party site, therefore they are not impacted.
Q10: For direct live connections to HANA on-premise, BW, S4, BPC, we are adding a Secure attribute to all cookies as part of the solution to resolve this issue. Cookies with the Secure attribute will not be sent back to the issuing server. Would the solution impact other web applications on HANA and NetWeaver systems when accessed with plain HTTP instead of HTTPS?
A: The ICM rewrite rule detects whether the web browser is accessing the service with HTTP. If that is the case, the Secure attribute will not be added to the cookies. This makes sure that the HTTP scenario is not impacted.
I hope the above FAQ has been helpful in clarifying any confusion with this critical issue.
Stay tuned.
Okumaya devam et...