Build Work Zone Single logout (SLO) for a multitenant application does not work

[FranciscoGarcia]

Hi everyone,

We have a multitenant application, with a launchpad-module, deployed on a provider subaccount. When subscribing from a consumer’s subaccount, launchpad-module is returned as a dependency, so the consumer can access the launchpad. Also, for the consumer subaccount we have an IAS using OpenID Connect protocol, through which we can access the launchpad.

Due to a necessity of having UI5 and React applications together, we have created an SAP Build WorkZone launchpad, on consumer’s subaccount. In this new launchpad, we have added UI5 applications from multitenant application (Wee see our multitenant application as Content-Provider in Content Channels tab) and a React application.

The React application calls API “/users-api” to get the current user data. This call is made through multitenant router.

So, when we login the Build WorkZone launchpad, it looks like Single-Sign-On (SSO) is working fine, because we are getting access not only to the launchpad, but to the multitenant UI5 app and its data too, meaning that SSO is propagating to multitenant router.

The problem arrives while doing logout. Build WorkZone launchpad throws Single Logout (SLO) from IAS, but it looks like logout is not propagated to multitenant router, so, when we login again (With a different user) and call the “/users-api” we are getting the data from the previous user.

Is our approach wrong? There is a way to extend or override Build Work Zone standard logout process?

Thanks in advance.

[Dinu · Accepted solution]

I don't think SLO works out of the box as you expect from Work Zone. Perhaps you can consult the SAP KB article mentioned in Work Zone documentation for this: 3000126 - Single logout is not working in Cloud Foundry. 

My reading is that the issue is not with approuter logout configuration or with xs-app.json configurations. These are for customizing logout url (default is do/logout) and triggering logout in connected backends respectively. It is simply that Work Zone does not know of how to trigger logout; there is no configuration for letting it know this.  Perhaps this not true for launchpad modules. But it is for other embedded applications. 

I could trigger logout of embedded applications in Work Zone from IAS by "Front Channel Logout" when Work Zone triggered logout of XSUAA.  Perhaps this works for you too. Please let know if it does. 

[FranciscoGarcia · Accepted solution]

Hi @Dinu,

It looks like you were right. Setting the logout URL of the approuter in "Front Channel Logout" is closing the approtuer session correctely.

Thanks, 

[BrendanFarthing · Accepted solution]

Hi @Dinu,

Can you please explain what you mean by "I could trigger logout of embedded applications in Work Zone from IAS by "Front Channel Logout" when Work Zone triggered logout of XSUAA"?

I am trying to get "Sign Out" to work on the user menu of SAP Build Work Zone Standard, but cannot get it to kill a user's session entirely (BTP session + Corporate IdP Session (ADFS)).

We have a Corporate IdP (ADFS using SAML) connected to IAS as a proxy, which is then connected to our BTP CF subaccount using OIDC.

Our Work Zone Standard is running in that subaccount. When a user selects "Sign Out" from Work Zone Standard itself, it goes to the standard logoff.html page and says the user is signed out and has a button to sign in again. But when the user clicks sign in, they are not asked to enter their credentials again (which is what we want, the devices in question are shared by many users) and instead it just logs back in again as the last user.

We'd also like stand alone HTML5 apps (using the Work Zone Standard managed app router) to be able to fully logout (clear the ADFS session as well), but we cannot get that to work either.

Do you think "Front Channel Logout" in IAS within the OIDC config for this subaccount will make SLO work and fully log the users out of Work Zone (BTP and ADFS sessions killed)? If so, what exactly to we enter into IAS and where?

Thanks,

Brendan