The SAP Launchpad service offers two architectures for implementing a central access point. In this blog we will have a closer look at the features and implications when building a site with either. Also, it needs to be mentioned that this covers the runtime scenario and that the design time always requires a cloud connector.

In a central launchpad the applications are hosted in a content provider, usually a SAP ERP system such as S/4HANA, ERP or Enterprise Portal system. See the Supported Platforms/Products in the official help documentation for more information. Also have a look at the excellent Blog Series Building a central Launchpad using SAP Launchpad Service for an in depth look at the configuration steps.

Tunneled Access

Launchpad Service – Tunneled Access

In a tunneled access architecture the content provider system or backend is connected to the Launchpad service via the SAP Cloud Connector. This means that the launchpad site and its apps are accessible from the internet. Single-Sign On (SSO) is realised via the principal propagation mechanism (see the below section on security for more detail).

Important to note: It is recommended to use SAP Identity Authentication service for authentication with SAP Business Technology Platform. Since the launchpad service opens individual applications in an iFrame the IdP must also allow for framing. IAS supports framing by default and can be configured to forward authentication requests to a corporate identity provider, even when a session is already in place.

Let’s have a look at the logon flow to understand how SSO would work with tunneled access launchpad:

In the above architecture there’s a corporate identity provider which allows for authentication via SAML 2.0, and which is also the central user store used in the organisation. As recommended, there is also a SAP Identity Authentication (IAS) tenant which acts as a SAML proxy for all authentication requests coming from SAP Business Technology Platform, as well as other SAP cloud solutions. The logon flow looks as follows:

1. User opens Launchpad site
2. Launchpad service redirects to IAS for authentication
3. IAS redirects to corporate IdP, where the user authenticates
4. Corporate IdP returns SAML-Response to IAS
5. IAS accepts the SAML token and returns a newly signed SAML token to the user
6. User opens a Tile: Session with IdP/IAS already open, User is already authenticated
7. (for on-premise systems) Principal Propagation via SAML Bearer Token & X.509 Cert

Please note that principal propagation in a central launchpad with content federation requires setting the cloud connector access control to use the principal type X.509 Certificate (strict usage). See the Launchpad Service help and Configure Access Control(HTTP).

Direct Access

Launchpad Service – Direct Access

In a direct access scenario apps are only accessible when the browser is in the same network zone as the content provider. While the launchpad still provides the launchpad shell and all associated functionality, the applications or their data are not accessible from the public internet. Contrasted with the tunneled access scenario, the integration happens in the browser of the end user.  Please be aware that as of the time this blogs was written, there are some functional limitations, compared to the tunneled access scenario, as custom and dynamic tiles are not supported.

Consequently, the logon flow for SSO changes with a direct access scenario:

While the setup of the corporate identity provider and the  IAS is the same, the actual flow changes once a user accesses an application in the launchpad site.

1. User opens Launchpad site.
2. Launchpad service redirects to IAS for authentication.
3. IAS redirects to corporate IdP, where the user authenticates.
4. User opens an app and accesses content provider.
5. The content provider redirect to corp IdP for authentication.

The authentication mechanism used by the content provider system may vary, depending on the configuration there. The supported authentication mechanism for direct access are Kerberos or SAML. In order for SAML to work, the browser must accept third-party cookies.