Portal Service (Neo) iFrame authentication with SAP IAS

[DanielKawkab]

Hello fellow devs,
our customers uses the Portal Service in the Neo environment to provide his applications to his customers. Some of the apps are deployed in the BTP, but there are also apps that are deployed in the backend. Those apps are either Web Dynpro - or UI5 apps.

Since the portal service integrates those apps via an iFrame we want to use the SAP IAS (Identity Authentication Service) as an Identity-Provider-Proxy for Azure B2C to enable authentication in those iFrames, because the corporate identity provider Azure B2C will block authentication in iFrames by default. The IAS on the other hand caches the user session after the initial login and will not request the Azure B2C on followed iFrame authentication requests, but instead will return the cached session, while allowing the authentication in an iFrame.

Here's the catch:
We use a custom domain for our portal service. So the domain is not 'XYZ.hana.ondemand.com' , but 'subdomain.corporate-domain.com'. Whenever i use the IAS for iFrame authentication scenarios in a portal, which is accesible via a custom domain, the IAS won't return the cached session, but will request the Azure B2C, which returns the iFrame authentication block in its header. This does not happen, if i use a portal service instance which does not have a custom domain and consequently runs on the same domain as the IAS instance (SAP's default domain 'ondemand.com').

Therefore i highly suspect that modern browsers block the IAS session cookies, since the IAS is basically a third-party for our cloud portal, because they do not share the same domain. Consequently my plan was to set a custom domain for the IAS (configurable via admin cockpit) which has the same domain as the portal service's custom domain.

Unfortunately it seems like a IAS custom domain will not change the hostname of the IAS instance or the domains (for sso, slo and acs) in the IAS metadata. The IAS domain in the trust management will keep the default name and the URLs in the IAS SAML 2.0 configuration will also keep the default IAS domain, while only changing the last part of the URL to the custom domain. The same changes happen for the metadata of the IAS instance.

Has anyone encountered a similar behavior and was able to solve it?

Best regards,
Daniel

[gregorw]

Have you raised an incident via SAP Support on this topic?

[DanielKawkab]

Hi gregorw,
as of now, i did not. I first wanted to evaluate if this behavior is wanted or not.

[former_member103524]

Hi Daniel,

IAS tenant is by default accessible on these two domains xyz.accounts.ondemand.com and xyz.accounts.cloud.sap (SAP common domain). You can add a custom domain like accounts.corporate-domain.com. Most of the times (specially in SAML2 scenarios) you don’t have to update the Entity ID, and can keep using the old one. The best approach is Entity ID to match the domain, but in case there are many applications which have to be migrated, you can keep it. On the other hand, the endpoints like sso, acs, slo are dynamic – if access the metadata with the new domain, you will get these endpoints with that domain. You can easily test it with the two domains:

https://<xyz>.accounts.cloud.sap/saml2/metadata

https://<xyz>.accounts.ondemand.com/saml2/metadata

Or accessing IAS admin console via xyz.accounts.cloud.sap/admin

MS Azure should be also on the same domain in case it is used.

Best regards,

Valentin Ivanov