Introduction

Recenly, I worked on a demo that required integrating an Oracle Process Automation (OPA) Cloud task form page into Fusion Application (FA) Cloud pages. In the demo, the OPA Cloud instance and the FA Cloud instance are in a hybrid deployment. In a hybrid FA deployment, the PaaS Cloud services (such as OPA and Oracle Digital Assistant, ODA) are deployed on the same IDCS (Identity Cloud Service) instance as the FA instance. They share a sigle user store. All necessary SSO configurations between FA and PaaS applications are completed automatically out of the box.

Based on the understanding of a hybrid FA environment, I expected SSO should work with the integrated OPA page regardless of the integration approaches taken, either via Structure or Page Integration tools in FA. What I actually observed from my testing was SSO worked for the OPA page linked via Structure in both Firefox and Chrome, as expected. However, the SSO did not work for the OPA page embedded via Page Integration in Chrome but Firefox worked. This blog tries to explain what causes this difference in behavior.

Integrating OPA Task Form Page into FA via a New Page Entry in Structure Tool

The simplest way to integrate an external page in FA pages is by creating a new page entry in the Structure tool in a Sandbox. This will add a new link in the dropdown menu if FA. Once clicked, the link will take you to the external page in a new browser tab. The image below shows my OPA task form page opened by clicking the new page entry I created in FA.

Because my OPA and FA are in a hybrid environment, SSO from FA to OPA works out of the box. The image below shows the browser and server communication when the page entry is clicked. The red underlined URL is the page entry URL. I can see that a few cookies are sent back to the OPA server. These cookies are received after I sign in to FA pages. One cookie named "OCI_SPLAT_DOMAIN_OIDC_REFRESH" is used to get a refresh authentication token from IDCS. The value of this particular cookie indicates to IDCS this is a previously authenticated session. If its value does not expire, SSO takes place for the OPA page.

One important observation from the image above is the SameSite setting for various cookies. The SameSite value tells the browser when and where to send the cookies along with a request. As we will notice in the following section, Chrome iFrame and Firefox iFrame implement a slight different behavior when the SameSite setting is blank.

Integrating OPA Task Form Page into FA via Page Integration Tool

The second method for integrating an external page in FA is by using the Page Integration Tool in a Sandbox. This creates a link in the dropdown menu very much like the link created in the Structure tool. The following image shows a Firefox browser displaying the same OPA page accessed via a link created by Page Integration. As shown, the OPA page is now displayed in a FA page via an iFrame. SSO also works as in the previous case.

A peek under the hood (image below) shows the same cookie named "OCI_SPLAT_DOMAIN_OIDC_REFRESH" is sent back along with the iFrame request for the OPA page. Hence, SSO works as expected.

Why It is not working in Chrome?

The following image shows the same OPA page accessed via the link created by Page Integration, in Chrome. As we can see, we are getting an error. Through the development tool, we can further tell we are getting a 401 authentication error.

By examine the cookies sent by the iFrame in Chrome (image below), we can see the "OCI_SPLAT_DOMAIN_OIDC_REFRESH" cookies is not sent along the request. Hence, SSO fails. 

Also note, the iFrame in Chrome only sends the cookies with the SameSite values of None. 

Conclusion

After testing SSO in FA page integration with an external application page in a hybrid environment, I observed SSO worked in iFrame based page integration in Firefox but failed in Chrome. This blog shows the failutr in Chrome is caused by Chrome's iFrame excludes cookies with a blank SameSite value from the cookies sent back to the server. In my test case, the behavior of Chrome's iFrame prevented a security refresh cookie from reaching back to the server. Thus, SSO fails in Chrome iFrame.