{"id":50497,"date":"2023-08-18T09:30:42","date_gmt":"2023-08-18T07:30:42","guid":{"rendered":"https:\/\/www.cubeserv.com\/authorizations-in-power-bi-in-interaction-with-sap-bw\/"},"modified":"2023-11-11T15:15:39","modified_gmt":"2023-11-11T14:15:39","slug":"authorizations-in-power-bi-in-interaction-with-sap-bw","status":"publish","type":"post","link":"https:\/\/www.cubeserv.com\/en\/authorizations-in-power-bi-in-interaction-with-sap-bw\/","title":{"rendered":"Authorizations in Power BI – in interaction with SAP BW"},"content":{"rendered":"\t\t
Rising interest rates, new regulatory requirements, problems in supply chains – more than ever, companies are facing the challenge of being able to quickly assess the impact of new situations and initiate appropriate measures if necessary. Against this backdrop, the IT infrastructure is being rethought in many places and requirements are being redefined. The focus is on greater flexibility, faster access times, less coordination effort, and dependencies. In addition to conceptual considerations (see also the blog entry on the topic of “Data Mesh<\/a>“), new data modeling and reporting tools such as Microsoft’s Data Factory, Analysis Services, and Power BI are also being evaluated.<\/p>\n When selecting new tools, the question quickly arises as to whether and to what extent existing data models and authorization logic can be integrated. As a rule, a lot of money, time, and nerves have already been invested in this. A complete rebuild should therefore be avoided.<\/p>\n Today’s blog entry is dedicated to the topic of “Authorizations in Power BI – in interaction with SAP BW”. First, the most important elements of the Power BI authorization concept are outlined. Then we will show you a way to dynamically transfer existing BW analysis authorizations to Power BI – to avoid time-consuming and costly redefinitions.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Areas of work<\/p>\n \u00a0<\/span><\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Containers for combining logically related elements, from data sources (datasets) to reports, dashboards, and apps. Bundle the other artifacts in a common area. Roughly comparable to an info area in SAP BW.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t At this level, Azure Active Directory users (or user groups) can be assigned a workspace role. These are already predefined and include: Administrators, Members, Contributors and Readers. The role assignment has a direct impact on the creation, release and modification authorization of datasets, reports, dashboards and apps.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t Datasets<\/p>\n \u00a0<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Container for one or more data sources. The data can be available both physically and virtually – depending on the type of access (import or live connection). Provide the basis for reports.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t The authorizations for datasets can be assigned in two ways: via the assignment of a workspace role (at the workspace level) or at the level of the respective dataset. The authorizations relate to changing, releasing, and creating content based on the dataset. In the case of role assignment, the specific authorizations are implicitly derived from the role (role-specific gradations). If a user is assigned directly, however, the scope of authorization can be defined individually.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t Reports<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Tabular and\/or graphical representation of the contents of a dataset. Can be created and modified via Power BI Desktop as well as via Power BI Service (Web). Enables self-service functionality for end users.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t Similar to datasets, the authorizations for calling up and creating reports can be assigned in two ways. Via the assignment of a workspace role or the direct assignment of a user to a report. The authorizations can include, on the one hand, the release of the report (granting read authorization for other users) and, on the other hand, the authorization to create content (build option). This authorizes other users to build their own reports based on the underlying dataset.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t Dashboards<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Summary of content from different reports and datasets. The home page can contain any number of tiles and widgets that can be used for detailed navigation.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t In contrast to the other artifacts (datasets, reports, and dashboards), apps are equipped with an additional authorization layer. As with the other artifacts, permissions can initially be inherited via the workspace role or assigned directly. However, direct assignment offers additional functions. Individual user groups can be defined at this point. Here, access to the underlying reports & dashboards can be set for specific user groups. Due to this feature, it is recommended to always distribute dashboards and reports via apps.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t Apps<\/p>\n \u00a0<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Summary of content from different reports and datasets. The home page can contain any number of tiles and widgets that can be used for detailed navigation.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t In contrast to the other artifacts (datasets, reports, and dashboards), apps are equipped with an additional authorization layer. As with the other artifacts, permissions can initially be inherited via the workspace role or assigned directly. However, direct assignment offers additional functions. Individual user groups can be defined at this point. Here, access to the underlying reports & dashboards can be set for specific user groups. Due to this feature, it is recommended to always distribute dashboards and reports via apps.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Now that an overview of functional authorizations has been provided, we will turn our attention to data authorizations in the following section. We will also look at the dynamic integration of SAP analysis authorizations in Power BI.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t In Power BI, data authorizations are mapped using the so-called “Row-Level-Security” approach. It enables the definition of individual data roles in which the authorized data volume can be restricted via DAX statements. The restrictions can relate to all characteristic fields of the underlying data sources. Calculated tables that represent a view of another table can also be used as the basis for authorization – this is particularly interesting for the so-called dynamic RLS (more on this later). In this case, the reporting model only consists of one data source (headcount). A Dax filter is used to restrict the characteristics “Business unit” and “Country” to the characteristics to be authorized.<\/p>\n While the roles are defined within “Power BI Desktop”, the user or user group assignment is carried out in “Power BI Service”. The published dataset has the option “Security at row level” for this purpose. The corresponding users can be assigned here:<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Without a corresponding assignment, an error message is displayed to users with read authorization.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Attention: Security at the line level does not apply if the users are assigned one of the above-mentioned workspace roles (administrator, member, or contributor). These roles should therefore be assigned with great care and only to power users.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t In the example shown at the beginning, RLS was mapped using the static method. This should be avoided in practice for the following reasons:<\/p>\n Due to these limitations, it is advisable to map authorizations using the dynamic RLS approach.<\/p>\n Dynamic RLS is characterized by the fact that the authorized values are kept in a separate table for each user. The DAX function “USERPRINCIPALNAME” is used to determine the user when a report is called up and the data is filtered according to the authorization table. This offers the great advantage that the maintenance effort within the data roles is reduced to a few statements:<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t The authorization table is linked to the data table (here “Headcount”) via “Relationships”. Filtering the authorization table thus automatically filters the data accordingly. Depending on the complexity of the data model, however, it may be necessary to create additional authorization tables. As a rule, 3 additional tables are required for each authorization-relevant characteristic – but these can be created relatively quickly within Power BI Desktop or Analysis Services. A concrete example is described in the following section.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t The starting point of the example is a simplified BW data model. This is outlined in the following figure (left). It consists of a composite provider that contains headcount data (heads, FTE, employees, organizational units, etc.). The characteristics “country” and “business unit” are marked as authorization-relevant. The authorizations are managed via function and data roles, whereby the data role contains a reference to the analysis authorizations. The permitted values of the two characteristics are stored here.<\/p>\n To implement the dynamic RLS approach in Power BI, a table is required at this point that contains the authorized values for each user and authorization-relevant characteristics. This list can be generated using a corresponding ABAP program.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Next, the Power BI model can be created in Power BI Desktop on this basis. Depending on the connection variant (import\/direct query), either the metadata or the complete table content is loaded into the model (for more details, see the following blog entr<\/a>y). In this context, however, it should be noted that table relationships and roles cannot be created in Power BI for every connection variant. Here is an overview of this:<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t SAP BW -> Power BI Desktop (Direct Query)<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t SAP BW -> Power BI Desktop (Import)<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t SAP BW -> Microsoft SQL Database -> Power BI Desktop (Import)<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t SAP BW -> Microsoft SQL Database -> Power BI Desktop (Live)<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\tThe Power BI authorization concept<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
Artifact
<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\tContent description
<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\tRelation to other artifacts<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n
Authorization setting
<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\n
\n
\n
\n
Mapping of data authorizations via Row-Level-Security (RLS)<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n
\n<\/span>The following illustration shows a simple example of a role definition for restricting the amount of data:<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\tStatic vs. dynamic Row Level Security<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n
Exemplary implementation of the integration of SAP BW analysis authorizations in Power BI via dynamic RLS<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
Variant
<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\tDynamic RLS supported<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t