
The web is heavily based on a technology called cookies. In a nutshell, cookies are a small set of information stored in your browser for later use by a website you visited. Cookies are for instance used to temporarily persist your session after you have logged in to a website or service using your browser – usually until you close your browser window. Cookies are also used when ticking the small check-box whenever a login page offered you to "Keep me signed in" or "Remember me", just settings its validity to a defined timeframe. On the other hand, the web is leveraging cookies also for tracking purposes. We speak of third-party cookies whenever a website, let's say example.com, is integrating some form of content (scripts, images, iFrames, etc.) that is running under a different domain (for example sap.com) and this content or domain is using cookies.
Some time back, all major browser vendors or their underlying browser engines did announce to heavily restrict the usage of third-party cookies with different rollout strategies and timelines (see WebKit, Google/Chrome, Mozilla). This brings us basically to the point, that web applications will only function correctly by default in the future (and partially already today), if they do not rely on third-party cookie scenarios.
SAP Mobile Start is a native mobile application serving as the native mobile entry point for the Intelligent Enterprise (read more). Besides bringing relevant business data to the app by leveraging native features like Widgets, Complications, Push Notifications and more, relevant business transactions and processes for mobile scenarios can be executed using the exposed & configured apps. These can be other native apps (like SAP SuccessFactors on iOS and Android) or mobile-optimized web apps – for example SAP Fiori apps exposed from SAP S/4HANA. From a content perspective, SAP Mobile Start is based on SAP Build Work Zone, standard edition (alternatively you can also use SAP Start). SAP Start is the central entry point for the browser into (selected) SAP Cloud Solutions. It allows users to search for applications, see all their tasks in one place via SAP Task Center and get recommended interest cards that are relevant to their role. SAP Build Work Zone, standard edition is an application-centric central entry point which supports more systems than just selected SAP Cloud Solutions and provides you more configuration flexibility.
A typical (and recommended) integration approach for web apps, especially for SAP Fiori apps, is to launch these embedded into the central shell. This approach is often also referred to as the "in-place" mode. On a technical level this means, that the actual app is running inside an iFrame within the surrounding shell of SAP Build Work Zone, standard edition. This holds true for both launching embedded / in-place apps in SAP Build Work Zone, standard edition on your regular desktop browser as well as when launching these via SAP Mobile Start. The latter is instantiating an in-app browser window provided by the mobile operating system where the web app is launched using its unique target URL. The following figure shows the same business app (in our case "Manage Purchase Orders") both started on the left with a laptop device using SAP Build Work Zone, standard edition and on the right side using the native mobile app SAP Mobile Start.
SAP Fiori App launched in SAP Build Work Zone, standard edition and SAP Mobile Start
Let's look at an imaginary landscape configuration where third-party cookie restrictions may be causing issues. Such an example will help us to illustrate potential issues during your system landscape setup and segue to the next section where we will focus on how to overcome these issues. In the following scenario we have provisioned the following resources:
When your purchaser employee is now launching the "Manage Purchase Order" application exposed from the SAP S/4HANA system via SAP Mobile Start, the following technical steps happen during the launch:
The iFrame connected to example.accounts.cloud.sap can neither access cookies of the same SAP Cloud Identity Services – Identity Authentication tenant set in the context of example.accounts.ondemand.com nor use any cookies, since the main window is operated under ondemand.com and an iFrame running under cloud.sap is considered a third-party cookie scenario. The second aspect holds true if the browser is restricting the usage of third-party cookies. As an example, this holds true already for SAP Mobile Start on iOS, since the browser is based on WebKit.
Schematic illustration of issues with the third-party cookie restrictions
As a conclusion, the observed issues are caused by the fact that multiple cloud solution are operated under different super domains. When integrating these technically using an iFrame, which is the case for SAP Build Work Zone, standard edition with the "in-place" mode, browsers will run – depending on their (default) settings – into third-party cookie restrictions. In the worst scenario, this makes the integrated business application unusable for some or all users.
To avoid any of such cross-domain scenarios leading to possible third-party cookie restrictions, it is key that all integrated cloud solutions – especially those running in an iFrame – are operated under the same root domain. This fact is often referred to as "having a Common Super Domain". Since SAP Build Work Zone, standard edition as a product is supporting the Common Super Domain of SAP, it is recommend to operate it in this case under cloud.sap – matching the root domain of the integrated SAP S/4HANA content.
In our example case this means, we should consume our SAP Build Work Zone, standard edition Site, where the content is exposed to via the URL example.eu10.workzone.cloud.sap instead of the other one mentioned above. This holds true as well for the onboarding configuration of SAP Mobile Start, which can be done either via the QR Code shown in the User Settings when opened with the desired URL or with a Managed App Configuration, where Administrators can push this config using an MDM system to enrolled mobile devices. Please note: In case you were already using SAP Build Work Zone, standard edition with the URL based on ondemand.com, you need to inform your users to use the desired URL going forward. Same applies for previously onboarded users to SAP Mobile Start.
In addition, adjust the SAP Cloud Identity Services – Identity Authentication tenant used by SAP Build Work Zone, standard edition to use the accounts.cloud.sap domain. This will allow that the Identity Provider session (and generally cookies) being established for the main page of SAP Build Work Zone, standard edition can be reused by the app iFrame.
Pro tip: We strongly recommend to leverage the "Identity Authentication" feature of SAP Build Work Zone, standard edition. This procedure will establish a direct trust using Open ID Connect to SAP Build Work Zone, standard edition and it will result in an own "Application" entry within your SAP Cloud Identity Services – Identity Authentication tenant. This also enables you to maintain dedicated configuration settings, separately from your general trust to the SAP BTP. At the time of writing this blog post, this feature is optional. It is very likely that it will get much more relevance in the future – hence our strong recommendation already today.
Schematic illustration of a configuration to avoid third-party cookie scenarios
Thanks to @florian_buech for co-authoring this article.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
12 | |
7 | |
7 | |
7 | |
7 | |
7 | |
6 | |
5 | |
5 | |
5 |