- SAP Managed Tags:
Introduction
In this blog post, we will make a deep dive into the "Scoped Roles" feature, announced in September 2023. We will discuss how it can be used for centralized and decentralized authorization management, explain how your existing roles will be converted, and provide an example of the post-convertion tenant setup.The next blog in the series by jaigupta28 will provide practical tips on different scenarios to effectively apply Scoped Roles in your organization.
Please refer to the additional blogs, to get more details about this feature:
- Preliminary Information SAP Datasphere – Scoped Roles
- SAP Datasphere Scoped Roles Conversion
- SAP Datasphere Scoped Roles Examples | Scenarios
Scoped Roles
The new Scoped Roles concept in SAP Datasphere enhances the existing approach to user/roles/Space allocation for Space-specific privileges. Previously, assignment of roles to users and users to Spaces was decoupled. As a result, all the roles assigned to a user were applied to all the Spaces the user was assigned to.
With the introduction of the Scoped Roles, the assignment of roles and Spaces to a user has been coupled together, granting the authorizations based on the user/role/Space combination. This approach allows to assign different authorizations to the users across Spaces, providing extra flexibility to the security management.
Authorization management with the Scoped Roles consists of two steps:
- assign a Space(s) to a Scoped Role as a scope (defining the scope where the role is applicable),
- perform the user/role/Space assignment within the defined role scope.
For instance, users may be added to a Space in the Space management UI, selecting the user and one or a few Scoped Roles the Space is assigned to. The same user/Space assignment can be performed for a role in the Role Management UI, where you may choose one or a few Spaces that the user should have access to among the assigned role scopes. Either way, to grant authorizations to a user, a combination of a Scoped Role, a Space, and a user must be provided.
While Scoped Roles allow the granular privileges assignment across the Spaces, they also support mass assignment of Spaces/users/roles. Therefore, both centralized and decentralized approaches to the user authorization management can be used with the Scoped Roles in Datasphere depending on your needs.
Centralized Authorization Management
Centralized authorization management means that role and space allocation implies that all users of a Scoped Role have access to all the Spaces mapped to the role. Such approach simplifies onboarding new users and new Spaces:
- new users assigned to the role get access to all the scopes, and
- when a role is assigned to a new user, they get access to all the scopes, and
- a new scope (Space) assigned to the role is automatically assigned to all the role users,
- no direct user assignment to a Space should be performed in Space Management.
The centralized assignment of users/role/Spaces can be performed on tenant level:
- in the central roles management UI
- in the central user management UI
- through SAML attribute mapping
Example:
A team of developers should be able to create and modify data models in all Sales Spaces (Delivery Invoices, Orders). In this case, one centralized Scoped Role “SRC_Modeler” may be used with all the Sales Spaces mapped to it as scopes.
Figure 1. Centralized Scoped Roles
The role may be directly assigned to the users, no additional Space-level user management is required because all users will automatically get the Modeler access to the Spaces included in the role “SRC_Modeler” as scopes.
Decentralized Authorization Management
Decentralized authorization management implies a direct assignment of users to a Space, specifying privileges (roles) the user should have when accessing this Space. As a result, users may be assigned to one or a few scopes of a Scoped Role, not necessary all of them:
- new users assigned to a Space must have one or a few Scoped Roles specified, and
- new users assigned to a Scoped Role must have one of a few scopes (Spaces) assigned,
- no direct assignment of a role to a user should be performed in User Management.
The decentralized assignment of users/role/Spaces can be performed:
- on the Space level in the Space Management UI
- on the Tenant level in Role Management User Assignment UI
- in the Command Line interface
Example:
Finance and Sales business users should be able to consume the data models in the reporting layer relevant for their department. One decentralized Scoped Role “SRD_Consumer” may be used, with both Finance and Sales Spaces assigned to the role as scopes.
Figure 2. Decentralized Scoped Roles
The granular user assignment can be performed then for each Space, where users are assigned to the role “SRD_Consumer” depending on their department. As a result, users of the Finance department get the consumer access to the Finance Space only, and users of the Sales department - to the Sales Space.
Hybrid Authorization Management
Both types of authorization management may be used in one Datasphere tenant, providing that there is a dedicated set of roles used in each authorization management approach.
The roles described above, “SRC_Modeler” and “SRD_Consumer”, may safely co-exist in one tenant as long as “SRC_Modeler” is assigned to users only in a central way, and “SRD_Consumer” – only in decentral way respectively.
Figure 3. Hybrid authorization management
As of now, the separation between centralized and decentralized roles is performed on organizational level, therefore it’s important to establish rules, e.g. a naming convention, to distinguishing roles used for Centralized and Decentralized authorization management to avoid potential conflicts and unexpected privilege assignment.
Example:
Let’s say Space Sales is assigned to a centralized role “SRC_Modeler” and a decentralized role “SRD_Consumer” at the same time. Some users are assigned to the Space Sales in centralized way with “SRC_Modeler” role, others – in centralized way with “SRD_Consumer” role.
Space Administrator has full control over the users assigned to the Space, therefore in the Space Management UI:
- they may remove SALES_MODELER user from the Space, even though it was assigned centrally. While it doesn’t lead to any immediate issues, it breaks the expected “all Spaces to all users within the role” rule of the centralized user/role/Space assignment. And subsequent removing and adding the Space "Sales" back to the “SRC_Modeler” role will also assign the removed user back to the Space.
- they may assign new users to the Space with any Scoped Role that contain current Space as a scope, “SRD_Consumer” or “SRC_Modeler” in this case. If a New_User is assigned to a centralized role “SRC_Modeler” on a Space level, the user will get Modeler privileges granted to that Space only, which is expected for the decentralized user assignment. So far, no issues. However, if a new Space “Fixed Assets” is added to the centralized role “SRC_Modeler” later, all users of the role will get access to the new Space, including the New_User.
Both outcomes may be unexpected for the Space Administrator.
Tenant conversion
As explained in the blog SAP Datasphere Scoped Roles Conversion, during the tenant conversion:
- For each Standard Datasphere role with Space-specific privileges, “DW (Standard_role)”, a new Scoped Role “DW Scoped (Standard_role)” will be created.
- For each Custom role “(Custom_role)” a new Scoped Role “(Custom_role)_SAP_Scope” will be created with a description “Created during SDP conversion”.
- A new role “DW Scoped Space Administrator” will be created with privileges to perform Space-level assignment of a user and a Scoped Role.
- All Standard Datasphere role with tenant-level privileges (like DW Administrator) will stay without changes.
The converted standard and custom Scoped Roles will be automatically assigned to the users and scopes (Spaces) to reflect the pre-conversion privileges of the users and their assignment to the Spaces. The new role DW Scoped Space Administrator will be automatically assigned to all the users who had a role DW Administrator assigned before within the Spaces the users had access to.
Assignment of multiple users to one role with different Spaces performed during the tenant convertion matches the decentralized role management concept explained above. Therefore, the converted Scoped Roles should be used for decentralized role management only. New Scoped Roles should be created to facilitate the centralized role management after the tenant conversion. You may keep using the converted Scoped Roles for decentralized role management or create new decentralized Scoped Roles.
Example:
Let’s consider a security model in a sample Datasphere tenant before the conversion, we will reuse similar security model in the next blog as well:
- Users of finance (
) and sales (
) departments, responsible for building reports in SAP Analytics Cloud Platform, have consumer access to the Sales and Finance reporting Spaces. They have standard role DW Consumer assigned and are added to the respective Spaces depending on the department. - Development teams that create data models and reports for the finance (
) and sales (
) departments have a standard role DW Modeler assigned. The users are mapped to respective harmonization, propagation, and reporting layer Spaces depending on the line of business they work with. - A dedicated MDM team (
) manages data models in a Master Data Space. The team members have a custom role MDM assigned with modeling privileges and are assigned to the Master Data Space. - A team responsible for data integration monitoring and managing remote connections (
) have a standard role DW Integrator assigned. Users have access to all the Inbound layer Spaces, one Space per remote system. - A DW Viewer role is assigned to a few senior members of a Modeling team, who should be able to view data models in all the Datasphere Spaces they are assigned to, either from finance (
) or sales (
) data stream. Each team member can also see the Master Data Space and some of the Inbound layer Spaces, depending on the Space-level assignment. - There are two tenant administrators (
) with DW Administrator role assigned, responsible for the finance and sales Spaces respectively. Administrator 1 is also responsible for the Master Data Space and Administrator 2 for the Inbound layer Spaces.
- Users of finance (
The user-role assignment:
Figure 4. Roles-users assignment before the tenant conversion
The Space structure and Space-user assignment are provided below, the user color in the diagram matches the user color in role assignment. Functional users are mapped on the right side of the Space, administrators – on the left side.
Figure 5. Spaces-users assignment before the tenant conversion
After the tenant conversion, all the mentioned roles except DW Administrator will be converted into Scoped Roles because they contain Space-specific privileges. Each converted Scoped Role will be assigned the scopes (Spaces) that the role's users had access to before the tenant conversion. A new Scoped Role Space Administrator will be created; it will get all Spaces assigned that had a user with DW Administrator role assigned to before.
| Converted Scoped Role | Assigned scopes (Spaces) | ||
|---|---|---|---|
| Reporting layer | DWH layer | Inbound layer | |
| DW Scoped Consumer | Sales, Finance | ||
| DW Scoped Modeler | Sales, Finance | Delivery, Invoices, Orders, GL, AR, AP | |
| MDM_SAP_Scope | Master Data | ||
| DW Scoped Integrator | S/4, BW, CRM | ||
| DW Scoped Viewer | Sales, Finance | Delivery, Invoices, Orders, GL, AR, AP, Master Data | S/4, BW, CRM |
| DW Scoped Space Administrator | Sales, Finance | Delivery, Invoices, Orders, GL, AR, AP, Master Data | S/4, BW, CRM |
The users will be assigned to the respective converted Scoped Roles along with the Spaces they had access to before the tenant conversion. Users who had the role DW Administrator assigned will keep this role along with the tenant-wide privileges that it grants. In addition, they will get a new role DW Scoped Space Administrator assigned, along with Spaces they had access to.
Figure 6. Roles-users-scopes assignment after the tenant conversion
As you see, there are no changes to the privileges granted before the tenant conversion or to the Spaces the users have access to. The new converted Scoped Roles will seamlessly replace the legacy roles.
How to grant privileges to new Users/Spaces after the tenant conversion
While assigning privileges to a new user is straightforward in both centralized and decentralized authorization management approach, let’s have a look at mapping of a new Space to a Scoped Role. Depending on your intent to manage the Space centrally or decentrally, the steps will slightly differ.
For a Space managed in a centralized way
- Assign the Space as a scope to a centralized Scoped Role.
All users of the Scoped Role role will be automatically granted access to the new Space, no additional steps required.
For a Space managed in a decentralized way
- Assign the Space as a scope to a decentralized Scoped Role.
- Remove the automatic assigment of the new Space to the users.
You may preform the second operation in the Role Management User Assignment UI, selecting the new Space and removing all the users. For instance, if you add a new Space "HR" to the existing decentralized role “SRD_Consumer”, navigate to the User Assignment tab, select the new Space, select all users and then Delete User Assignment:
Figure 8. Remove user assignment in the Role Management UI
This approach is associated with a risk to unintentionally remove users when selecting the wrong Space. Therefore, the recommended approach would be to switch to the Space Management UI and remove all/unnecessary automatically assigned users there:
Figure 9. Remove user assignment in the Space Management UI
After adjusting the automatically assigned users, the Space Administrator can proceed with decentralized user assignment to the Scoped Role.
Summary
The Scoped Roles allow a more flexible and granular authorization management process in SAP Datasphere. They support both centralized and decentralized security management, with the ability to assign different authorizations to users across different Spaces. Regardless which approach you chose, keep the following recommendations in mind:
- Use separate roles for centralized and decentralized role management, preferably separating them by naming convention.
- Use the converted Scoped Roles for decentralized authorization management only.
- Create new Scoped Roles to facilitate the centralized authorization management.
- Remove automatically assigned users on a Space level after a new Space assignment to a decentralized Scoped Role.
