Struggling to streamline your authorization setup across Business Intelligence systems? Want to maintain one central source of truth for your authorizations? You’re in the right place!
From concept to implementation, we’ll show you how to:
Leverage an SAP S/4HANA system as the central source for managing reporting roles and authorizations.
Use CDS views to make these roles and authorizations extraction-ready.
Extract and integrate the data into SAP Datasphere, complete with a model setup to illustrate the final result.
In this blog, we’ll take you step-by-step through a practical example of unifying your authorization setup using SAP Datasphere.
* Please note that there might be valid reasons to use; (1) a different ‘source’, or, flat file additions, e.g. due to license costs, as all users need an account in the source for this concept to work, (2) different content of the extraction setup, such as just replicating individual tables and modeling the concept in the system being extracted to, and/or (3) based on the authorization setup and naming conventions, different choices and/or tables may need to be used (e.g. RSECVAL_STRING and RSECHIE_STRING tables might be required if the authorization setup is done within SAP BW).
Within your company, several Business Intelligence (backend) tools are used and authorization for the same user is maintained in multiple places. As the authorization concept for ‘reporting’ is already unified among these systems, a standardized user creation process is proposed in the S4 source system, as leading system of record.
The example will focus on the authorization on ‘Controlling Area’ and the effect having this authorization has on ‘Project’ data (Table PROJ).
Aligning Composite, Single and ‘Data Access’ Roles with the naming convention for Reporting:
Composite Roles: ZREPORTING_ROLE_CXX (C for ‘Composite’)
Single Roles: ZREPORTING_ROLE_AXX (A for ‘Area’)
‘Data Access’ Roles: ZREPORTING_AXX_OXX_V<>, where:
AXX: Authorization Area 01, 02, …
OXX: Authorization Object 01, 02, …
V<>: Authorization Value of the Object
As an example, the following has been created:
Composite ZREPORTING_ROLE_C01, containing Single Roles ZREPORTING_ROLE_A01 and ZREPORTING_ROLE_A02 for Area 01 and 02 respectively
Data Access on Controlling Area (Field KOKRS), ZREPORTING_A01_O01_VA000 (value A000), ZREPORTING_A01_O01_V1000 (value 1000), and ZREPORTING_A01_O01_VALL (value ‘*’)
Standardized ‘User ID’ across all systems
Enabling validity From/To of the User ID for extraction purposes
Addition of required information to get the e-mail address used for Single Sign-on purposes (e.g. Address Number and Person Number)
Making sure the CDS view can be extracted:
Base tables for ‘User’ details:
USR21 (User Name/Address Key Assignment)
ADR6 (E-Mail Addresses (Business Address Services)
Base tables for ‘Authorization’ details:
AGR_USERS (Assignment of roles to users)
AGR_1251 (Authorization data for the activity group)
Output:
Selection conditions:
Extraction of additional base tables for validation purpose in Datasphere, TKA01 (Controlling Areas) and PROJ (Project definition), e.g.:
Creation of Replication Flow(s) to extract the CDS views. For example, for the ZZ1_DS_AUTH_V1 CDS View containing the User Authorization Data:
Filtering out in the Projection additional subsets of what is needed, field = KOKRS or field = ROLE , and set to Truncate.
This results in the following three tables:
After running the Replication Flow, for the ZZ1_DS_AUTH_V1 table the following data is now available:
The model in Datasphere itself will consist of a couple of components:
A model to generate all values for the Controlling Area, based on the Master Data. This might be needed to derive all values for users having the ‘VALL’ (i.e. ‘*’) Authorization. Such models might be relevant for all objects that are ‘Authorization relevant’, and might contain additional components (e.g. flattening of Hierarchies):
Resulting in a structure and content as:
2. A model to combine the output of the User Authorization Data (ZZ1_DS_AUTH_V1), based on ‘Area’ (A01) for which it is used combined with the above generated model for the Controlling Area being Authorization relevant:
In which the Projections:
User Values: Area (3) and User Values: KOKRS A01 (1) are filtered and Inner Joined
(3): low = ‘A01’, to make sure only users having access to Area A01 are used
(1): field = ‘KOKRS’ and ‘left(agr_name,18) = ‘ZREPORTING_A01_O01’ , to make sure only the Controlling Area field (KOKRS) and its relation to A01 (Area 01) and O01 (Object 01) is correct
Then, the KOKRS Values (2) is Inner Joined to add -if needed- the values for the ‘*’ Authorization
Based on the result of 2), containing only the ‘Derived’ Controlling Area and the E-mail Address, a DAC specific for this combination can be created, i.e. DAC_A01_O01
Based on the extracted PROJ-table, a simple Fact view (to add the DAC) and Analytical Model is created for validation.
Scenario 1:
As the NHOEVEN (SSO: nico.van.der.hoeven@mccoy-partners.com) user only has access to Controlling Area 1000, which does not exist in the S4 PROJ source, the output can be validated as a ‘negative’ test:
S4 PROJ Table:
Datasphere Analytical Model with KOKRS = 1000 Authorization
Scenario 2:
As a secondary test, the Authorization will be changed: ‘*’
Datasphere Analytical Model with KOKRS = * Authorization
S4 PROJ Table:
Which matches the data compared to the S4 PROJ Table for the individual Controlling Area’s:
Scenario 3:
Another shift in Datasphere, towards only having Access to the A000 Controlling Area.
Datasphere Analytical Model with KOKRS = A000 Authorization
This matches the 83 source records (as shown in the PROJ Screenshot of Scenario 2).
If you would like to know more about standardizing the (SAP) Authorization setup within your Business Intelligence landscape, or within its specific SAP Datasphere context, please contact Nico van der Hoeven (+31651528656).
As an innovation partner, we want to continue inspiring you. That's why we gladly share our most relevant content, events, webinars, and other valuable updates with you.