Explaining the Authentication Flow of SAP Build Work Zone

As outlined in the introduction of this unit, SAP Build Work Zone is running as a service on SAP BTP and therefore, relies on the identity provider (IdP) trust configuration on the subaccount level. Furthermore, the Digital Workplace Service (DWS) layer leverages dedicated authentication related settings, which need to be considered. This lesson will explore the authentication related aspects across the SAP Build Work Zone product architecture, and how the different elements are connected to another.

For SAP Build Work Zone, IAS will at least need to be used in proxy mode when connecting to another SAP or third party. IdP is not supported. Directly connecting a corporate identity provider to the SAP BTP subaccount will not work for SAP Build Work Zone or SAP SuccessFactors Work Zone. While the manual trust configuration on the BTP subaccount with IAS (based on SAML2) is supported, the recommended trust setup with IAS is using the automated, establish trust feature (OpenID Connect).

Regardless of the selected configuration mode of IAS and a potentially connected corporate IdP, the information configured for this trust setup is important as it is directly impacting the user attributes available across the SAP Build Work Zone experience or setup, namely:Subaccount → Security → Users list (if the Create Shadow Users During Logon option is enabled).

Note

If the automatic creation of shadow users is not enabled, these will need to be created either manually on the BTP subaccount cockpit admin UI, or using the XSUAA APIs. The login to SAP Build Work Zone will not work if no shadow user exists for the user trying to access it.

• Subaccount → Connectivity → Destinations (for example, the userIdSource property).
• Attributes for Principal Propagation to on-premise backend systems (using destinations and SAP Cloud Connector).
• Attributes shown in the user avatar in SAP Build Work Zone shell header.

In addition to the SAP BTP subaccount level trust, an additional trust configuration is required for the Digital Workplace Service component running as an iframe in SAP Build Work Zone. This trust is also an Identity Authentication SAML2-based trust. This setup is configured purely as a fallback mechanism. More details can be found in the next section, Authentication Flow, of this guide.

Note

At the time of publishing this course, this fallback IAS trust configuration for DWS is still required, although opening any DWS URL is already re-directing to the SAP Build Work Zone URL, also pre-authentication.

When a user accesses any link for SAP Build Work Zone, the trust between the subaccount and IAS (and optionally the connected IdPs) is leveraged. In contrast, the authentication for the Digital Workplace Service (DWS) iframe is achieved through a single_use_token, generated through an API call using the 'JAM' destination, leveraging OAuth2SAMLBearerAssertion as an authentication mechanism. This process is transparent to the user of SAP Build Work Zone or SAP SuccessFactors Work Zone, and doesn't require any additional login screen or other form of user interaction. It is happening in the background.

To recap, here is the anatomy of the SAP Build Work Zone product to understand the role of the DWS iframe.

When looking closely at this flow, the following elements need to be considered:

As a result, the DWS layer automatically has two trusted IdPs available after completing the initial setup. They must not be changed or disabled.

To summarize, here are the two authentication flows connected to those IdPs, and related configuration settings.