Personas
This unit explores the big picture of the different security-related elements across SAP Build Work Zone in more detail, and explains how they play together in an integrated landscape.
When exploring the security architecture of SAP Build Work Zone, the first element to consider is the fact that different personas with different required authorizations must access the system performing different kind of actions. These are, first and foremost, independent of the integrated business applications (be it SAP or third party), but specifically refer to SAP BTP platform and the SAP Build Work Zone or SAP SuccessFactors Work Zone service level.
Here, the following personas must be considered:
- Company administrator
- Support administrator
- (Administrative) area administrator
- Page content administrator
- Internal user
- External user
Given the implied authorizations those personas have and require, they're either leaning more towards IT or business, respectively. This is outlined in the figure, Advanced: Administrator Types (Digital Workplace Service [DWS]).
What is done by the different administrator types?
- Company administrator
Accesses the full range of capabilities within the Administration Console, and configures digital experience to the organizations needs.
- Assigned manually in Administration Console or through SCIM API.
- Role Collections assignment required.
- Support administrator
Accesses a subset of the functionality available to company administrators to support them and lessen their workload.
- Assigned manually in Administration Console.
- Role Collections assignment required.
- Area administrator
Manages area content, collaborates within designated area, and has a smaller but significant subset of the company administrator capabilities.
- Assigned manually in Administration Console.
- Role Collections assignment required.
- Page content administrator
Manages the content and design of workpages and specific content, and acts as a subject matter expert
- Assigned manually in Administration Console.
- Role Collections assignment required.
- Workspace administrator
Manages the content within particular workspaces.
Assigned manually in admin settings of workspace.
Identity Provider Layer
In the default (suggested) configuration, these high-level personas are assigned dedicated user groups on SAP Cloud Identity Services, Identity Authentication (IAS) (represented below as the Identity Provider Layer). Instead of maintaining the group assignment on IAS directly, IAS can, for example, only act as a proxy identity provider (IdP) to another IdP like Microsoft Entra ID or Ping Identity (where such group assignments can also happen).
While this is the standard setup provided by SAP, IAS doesn’t actually require users to be persisted or groups to be assigned. However, it does have implications for how other security aspects must be configured. In either case, the Identity Provider Layer includes several attributes in either the SAML assertion or the OpenID Connect token (JWT). These in turn are leveraged on the SAP BTP subaccount level and subsequently for the services running on it.
Note
SAP Cloud Identity Services, Identity Authentication (IAS) must at least be used as a proxy. Directly connecting a corporate identity provider to the SAP BTP subaccount doesn’t work for SAP Build Work Zone or SAP SuccessFactors Work Zone. The manual trust configuration on the BTP subaccount with IAS (based on SAML2) is still supported. However, for now, the recommended trust setup with IAS is using the automated, establish trust feature (OpenID Connect).The latter enables the strongly recommended direct integration of SAP Build Work Zone with IAS.
Platform Layer - Role Collections
To access any service or application deployed on the SAP BTP (CF) subaccount, the underlying role collections must be assigned to the user trying to access it. For SAP Build Work Zone and SAP SuccessFactors Work Zone, several persona-specific role collections are created automatically upon subscribing to the service. Those can’t be altered in terms of included roles, but users can be added or removed from the role collection assignment. In the default setup, those standard role collections aren’t assigned to the individual user, but are mapped to certain attributes coming from the connected IdP. Also, custom role collections can be created and then leveraged for integrated business content. This is covered in more detail in the lesson focusing on authorizations.
Note
The default role collection mapping relies on the Group attribute directly from IAS, but this setup can be adjusted based on the overall solution setup and requirements. Role collections can alternatively be mapped on other attributes coming from IAS, attributes coming from another IdP (connected to IAS in proxy mode), manually assigned to individual users through the admin UI of the BTP subaccount cockpit, or assigned to users via the dedicated XSUAA SCIM API.Application Layer
With the role collections on the BTP subaccount level assigned, the authorization to access the service itself are granted. Unlike many other BTP services, SAP Build Work Zone and SAP SuccessFactors Work Zone also require service-specific user persistence and role assignment.
These topics are covered in even further detail in a later lesson. However, the following key aspects must be considered for the big picture:
- Connected to the subaccount level authorizations, SAP Build Work Zone (both standard and advanced edition) content available across sites is managed through the content manager. This is specifically relevant for integrated content providers such as SAP S/4HANA, as the related roles, apps, and more, are directly added on the tenant-level (not in the Digital Workplace Service [DWS] layer).
- Regardless of the connected IdP for authentication and user created in XSUAA on the BTP subaccount, a dedicated user record must be created in the DWS component of SAP Build Work Zone. On the high level, these users can be created as internal or external, which will already determine several key settings on which feature sets a given has or hasn’t got access to.
Note
This additional user persistence on the DWS level is required to support the extended feature set of the product, for example, the invite or @ mention flow. These only work if the user already exists in the system. Therefore, they can’t rely on a user having logged in already. Otherwise, it doesn't work for new joiners on their first day.- As outlined in an earlier unit, one key feature of SAP Build Work Zone are workspaces. The access to those workspaces isn't typically controlled through role collections, but instead persisted or directly assigned on the DWS component. Depending on the type of the workspace (public or private), only internal or external users can be added.
The exception to this is the non-member access to public workspaces, which can be based on role collections.
- In addition to inviting individual users to workspaces, adding them to private folders, or assigning them to certain administrative areas, there’s also a dedicated role concept in the DWS component. It's the user list, a list of users (such as an e-mail distribution list) that can be leveraged to mass-invite or assigned multiple users at once to a given workspace, for example. These user lists can either be created through the DWS admin UI or provisioned into the system through a dedicated API (imported user lists). User lists support both types of users. However, currently, external users can only be added to imported user lists. The SCIM API leveraged for these imported lists is covered in more detail later.
Integrated Business applications
In addition to the elements covered so far, there's also the security element of integrated SAP or third party business applications. As outlined in the earlier units of this course, the integration can happen in different ways, for example, by using content federation to launch a business app in-place, or surface business data of an application in the form of a UI integration card. From a security perspective, those scenarios are important to consider, although not directly controlled within SAP Build Work Zone. Instead, the authorizations and other security-related aspects are controlled on the side of the respective business application.
The figure, Security Architecture in SAP Build Work Zone, connects those building blocks into a big picture that helps understand the SAP Build Work Zone security architecture.
