Explaining the Provisioning of Users and Roles in SAP Build Work Zone

To successfully log in to SAP Build Work Zone, users and assigned authorizations must be available across several components of the overall solution architecture. This includes the usual SAP BTP subaccount level user and role (collection) assignment. Furthermore, SAP Build Work Zone, advanced edition and SAP SuccessFactors Work Zone require service-specific user persistence and role assignment, both on the service level (tenant) and in the Digital Workplace Service (DWS) layer.

To access SAP Build Work Zone, advanced edition or SAP SuccessFactors Work Zone, users must be assigned to one or more default role collections that are created upon subscribing to this service on the subaccount level. Additionally, an XSUAA shadow user (to which these role collections are assigned and mapped) on the SAP BTP subaccount → Security → Users.

Shadow Users can be created in three ways. Not all are specific to SAP Build Work Zone but are uniformly used and available when using any service on the SAP BTP multi-cloud (CF) environment:

• Manually create users through the admin UI on the SAP BTP subaccount cockpit.
• Create users via the XSUAA SCIM API, for example, using the SAP Cloud Identity Services, Identity Provisioning (IPS). For this setup, a dedicated target system type is available to create, update, and remove users.
• Automatically create and update users based on the login via the connected IdP. For this to work, the create shadow users flag for the IdP trust must be enabled.

Note

The shadow user must be created for the correct IdP, specifically the one used for logging into the applications, but not the platform-level one leveraged for the SAP BTP subaccount cockpit login. While those are two separate configurations or IdPs trust, both can use SAP Cloud Identity Services, Identity Authentication (IAS) as primary or proxy IdP.

Role collections can also be assigned in multiple ways, not all specific to SAP Build Work Zone but uniformly used and available when using any service on the SAP BTP multi-cloud (CF) environment:

• Manually assign through the admin UI on the SAP BTP subaccount cockpit.
• Use attribute mapping (for example, Groups) from the connected IdP, either relying on the SAML2 assertion or OIDC token values.
• Assign through the XSUAA SCIM API, for example, using the SAP Cloud Identity Services, Identity Provisioning (IPS). For this setup, a dedicated target system type is available to assign or unassign role collections to users.

Note

The default onboarding flow mentions specific user group names that are mapped to role collections in SAP BTP cockpit. The same mapping is done by the SAP Build Work Zone, advanced edition or SAP SuccessFactors Work Zone booster, which relies on those exact user groups names from Identity Authentication. Alternatively, if different group names can be used and mapped to role collections in SAP BTP cockpit, those user groups can either be manually created in Identity Authentication or come from a SAML assertion / OIDC token from a corporate IdP (in which case, IAS would only be acting as a proxy IdP).

Note

All options outlined above for shadow user creation and role collection assignment, are supported for SAP Build Work Zone, advanced edition or SAP SuccessFactors Work Zone, although the automatic creation of shadow users and mapping based on the Groups assertion attribute is suggested in the documentation as the default setup.

As explained in previous units, specifically the unit on different integration scenarios, connecting to content providers is one key integration mechanism to make different business apps available to users in SAP Build Work Zone. In the context of this content provider configuration, the role assignment (referring to the roles in the source system mapped to roles in the SAP Build Work Zone content manager) is an important aspect. There are two options available for assigning those content provider roles inside SAP Build Work Zone:

• Roles are automatically created as role collections on the SAP BTP subaccount following a specific syntax or prefix. As outlined in an earlier lesson, the assignment to those roles is then done.
• Directly assign the roles inside SAP Build Work Zone, using a dedicated API. This presents one of two REST APIs based on the System for Cross-domain Identity Management (SCIM 2.0) specification.

For this second option, the SCIM API is used to create a base SCIM user record alongside the SCIM groups representing the required roles from the source system, for example, SAP S/4HANA. The default for using this API is the SAP Cloud Identity Services, Identity Provisioning (IPS) with a dedicated connector available for these role assignments. Alternatively, the API can be connected to from any other external client. It isn't limited to the usage of IPS. The figure, Content Manager Role Assignment Through SCIM API - For integrated Content Providers, outlines the different options the API provides for this purpose.

SAP Build Work Zone exposes two REST APIs based off the System for Cross-domain Identity Management (SCIM 2.0) specification*. This first API is specifically leveraged for the role assignment in the content manager, optionally available in the context of integrating with external content providers.

The use of content providers and the related SCIM API for role mapping is optional and depends on the integration scope. However, the creation of users and role assignment in the Digital Workplace Service (DWS) is mandatory even for the initial login to SAP Build Work Zone. As outlined earlier in this unit, this is understood as complementary to the XSUAA shadow users and role collection assignments.

To support this requirement, SAP Build Work Zone also provides a second REST API based on the System for Cross-domain Identity Management (SCIM 2.0) specification. Similarly, with the first API discussed in the previous lesson, the SAP Build Work Zone implementation doesn't cover all possible optional elements of the SCIM 2.0 specification.

The two entities, Users and Groups from the SCIM API, are represented in the SAP Build Work Zone product as either internal or external users, or imported user lists, respectively:

User provisioning

This enables you to create, update, and delete profiles available in Digital Workplace Service (home pages, workspaces, and profile pages).

It doesn’t include any other SAP or third-party applications (for example, to access SAP Fiori apps hosted in SAP S/4HANA from SAP Build Work Zone, user must have account and authorizations in SAP S/4HANA).

Group provisioning

This enables you to create, update, and delete (imported) user lists available in Digital Workplace Service (home pages, workspaces, and profile pages).

Imported users lists can’t be changed in the UI of SAP Build Work Zone. Member lists can be used to grand access to administrative areas, home pages, or workspaces.

When connecting to this SCIM API, it’s important to use the Digital Workplace Service (DWS) URL, not the SAP Build Work Zone subscription URL from SAP BTP. The authentication for the SAP Build Work Zone SCIM API is done using 2-legged OAuth. For this reason, only the automatically created OAuth client "Workzone API Client" can be used. The client details are provided during the SAP Build Work Zone / SAP SuccessFactors Work Zone onboarding wizard, and then in Administration Console → External integrations → OAuth Clients.

Note that the DWS URL relates to the overall SAP Build Work Zone URL as follows:

The default for using this API is the SAP Cloud Identity Services, Identity Provisioning (IPS) with a dedicated connector available for these role assignments. Alternatively, the API can be connected to from any other external client. It isn't limited to the use of IPS. The following API endpoints and operations are supported.

SAP Build Work Zone exposes two REST APIs based on the System for Cross-domain Identity Management (SCIM 2.0) specification*. This second API is a specifically leveraged user, and user list management in the Digital Workplace (DWS) layer, and is mandatory for the initial login to the system.

In addition to creating basic user profiles and user lists, there are several special features and considerations in the context of using this SCIM API:

The SCIM.userType attribute determines whether a user is created as an internal (full access / regular) or as an external one:

• Employee = Internal user
• Public = External users

Note

External users are the most restricted user type. They’re guests of the organization and are given access to only the specific workspaces to which they've been invited, as well as to dedicated workpages or menu entries and their user profile. They’re allowed only limited information about, or interactions with, other users.

• Dedicated external user home sections in the menu shared with the other external users
• No permissions to create workspaces or to access My Workspace
• Search and collaboration scope restricted to external workspaces
• Contact information for external users can be hidden