Dear community,

Integrating SAP PaaS services from Business Technology Platform (BTP) into other portal environments is still en vogue nowadays. So, here goes a short guide how to make it happen with SAP Cloud Portal (same for Launchpad service) and Microsoft Teams as an example for the approach.

Off we go through the gate to find that new species of life that lives in both worlds – SAP and Microsoft – at the same time! (Stargate still a thing? Just curious)

Fig.1 Illustration of embedded BTP service in Teams; source for stargate illustration: Wikipedia, by Stefan Xp, CC BY-SA 3.0, image used as overlay as is

Embedding an external page into a web app (including the Teams desktop or web client) is straightforward. iFrames are an popular option to get it done.

Fig.2 Click path to embed external website

The beefy part starts with the ever present Single-Sign-On (SSO) requirement. By default, BTP comes with the SAP ID service. To pursue SSO you need to establish trust between the Identity Provider (IdP) that is attached to your hosting app and the SAP ID service. In my example case that is Azure Active Directory (AAD). In addition to that we need to configure XSUAA for CloudFoundry (excluding NEO environment here. See this post for more details).

Let’s look at the moving parts

First, we establish trust with our IdP (Azure AD). The configuration is quite “established”, so it still reads “SAP Cloud Platform” on the Azure portal screen 😀 Find the official docs for the process here.

Fig.3 Setup trust between AAD and BTP

See below example for reference to “flesh out” the official guidance a little more.

Fig.4 SSO config example on AAD for BTP CF domain ms-demo

Once you have established trust you end up with two IdPs being available on your BTP Subaccount. Note that both are available for logon. We will come back to that a little further down.

Fig.5 Additional registered IdP on BTP Subaccount

Trust: Check! What about embedding?

Nowadays, web applications and particularly PaaS or SaaS apps prohibit embedding by default to protect user experience, limit attack vectors, or for branding reasons for instance. Fortunately, BTP allows selective relaxation of that policy. We are looking at the content-security-policy header.

Both the Launchpad and the Portal Service have the same setting and view to maintain it:

frame-ancestors iframe frame object embed 'self' https://teams.microsoft.com;

Fig.6 CSP setting in BTP Portal Service for Teams embedding

Ok great, but the initial login goes to the XSUAA before it hits either of the two available IdPs.

So, next we need to configure our “SAP Authorization and Trust Management Service in CF” (XSUAA) instance to allow embedding by our web application (Microsoft Teams in this example). There are differences by BTP Feature Set. Below example is described for Feature Set B. See the official SAP docs for the other parts.

Fig.7 Subaccount settings for embedding

During my testing I needed to use the Security REST API and PATCH the iframeDomains attribute from Postman instead of the cockpit, because it was not fully functional yet. Find my collection for ease of use here.

Awesome, let’s test!

Fig.8 SAP XSUAA login before redirect to IdP

Not quite there yet. On the upside, we have working trust and embedding! But on the downside, we don’t have immediate SSO, because our portal service doesn’t know which IdP it shall select. How do fix this?

On the NEO environment you were lucky because you could just add the smart URL parameter “saml2idp” to pick the IdP. Unfortunately for CF, SAP decided not to implement something like this yet. Check the customer voice to upvote.

Alternatively, design your CF subaccount in such a way that you can get away with switching off the SAP ID service for your subaccount for login completely.

Fig.9 Switch off default IdP for logon

With that, every single service and app running on that subaccount can only be logged-on using your custom IdP. That might be problematic though: Imagine you have a user split for end-users and developers. Often developers access Business Application Studio (BAS) running on that subaccount with their S-Users. After the switch, this is not possible anymore.

Possible mitigations could be onboarding all users only through the custom IdP or moving all services/apps that require default IdP to another subaccount. Speaking of BAS for instance, you can easily deploy to other subaccounts and CF spaces.

Choose wisely 😉 and once you did, you will find that breath-taking life form on the other end of our “Portal-Gate” illustrated in figure 1, that thrives both in the SAP and the Microsoft world…

Fig.10 Successful SSO from Microsoft Teams and SAP Cloud Portal Service

Beautiful, isn’t it?

For now we need to stick to the subaccount design, if you want to avoid the “IdP picker-screen” (see fig.8).

What about self-hosted Fiori Launchpad (FLP)?

See my dedicated post on that matter.

Besides that there are FLP exposure topics. On Azure that usually involves Azure Application Gateway including Web Application Firewall. Have a look at below sources to address:

• Fiori exposure on Azure
• SSO for Fiori with Azure AD

Pay attention to the automatic redirect setting for the IdP. Tobias Hofmann created a nice post for it.

Final Words

Not too bad, huh? Today, we investigated BTP application and service embedding challenges and shed some light on how to configure SSO with a custom Identity Provider. We used the SAP Cloud Portal Service, Azure AD and Microsoft Teams as examples to support the approach.

In case you want to get started for free find the trials here:

• Azure trial for AAD
• BTP on Azure trial
• M365 developer program for Microsoft Teams

What do you think @community? Anything to add?

As always feel free to ask lots of follow-up questions.