This lesson covers some approaches for managing analysis authorization concepts, including using separate applications, namespaces, and folders to define areas of responsibility and support security requirements in data warehouse implementations.
Describing Approaches for Analysis Authorization Concepts
Objective
After completing this lesson, you will be able to describe approaches for analysis authorization concepts
Business Example
Separating Areas of Responsibility
This diagram is illustrating strategies for supporting analysis authorization concepts: Separate Applications, Separate Namespaces and a slightly more flexible solution.
There are several strategies to realize areas of responsibility and to support security requirements.
Combinations of these concepts are common in data warehouse implementations. Let's have a look at these strategies in a little bit more detail.
Separate Applications
In cases where areas of responsibility can be clearly divided and do not share many common objects, they can be managed through distinct data warehouse applications. This approach is beneficial when users in one area should not have access to data from another area. For example, separating HR data from operational or CRM data within separate BW applications. To create global reports consolidating data from various areas of responsibility, extract pertinent data segments into a central global data warehouse.
Separate Namespaces
In scenarios where areas of responsibility require a strict and stable separation despite sharing numerous common objects, it is advised to use distinct namespaces. For example, establishing separate namespaces for procurement and sales along with a common objects namespace encompassing shared elements like day, product, employee, and business partner. Global reports that combine data from both areas can then be created by constructing views across both namespaces within the common objects category.
Separate Folders
Keep in mind that the design of responsibilities can change over time. Areas of responsibility are regularly further divided into subareas. In a data warehouse setup, it is possible to establish a folder hierarchy that reflects a dynamically changing hierarchy of areas of responsibility. For instance, you can create InfoAreas like online sales and shop sales as sub InfoAreas under Sales to accommodate evolving responsibilities.
Recommendation
With all three concepts, an authorization management can be implemented. However, with the first two concepts, the technical impact of changing the organization is high. For this reason, we recommend that you work with separate data warehouses and namespaces only for areas that remain as they are.
With the namespace approach, adding a new namespace for extra responsibilities is straightforward. Technical names are difficult to remodel. Therefore, be careful when defining namespaces.
Even if you have a strict organization, you may want to reorganize it later. Even if you have only one subsidiary now, you may want to be able to create new areas later. In such cases, you are more flexible if your concept is based on a hierarchy of folders such as InfoAreas in SAP BW/4HANA. Adding new folders and moving objects to other folders is usually no problem. For most cases, we recommend a folder hierarchy because it allows the highest degree of flexibility.
Approaches for Analysis Authorization Concepts
Steps to an Analysis Authorization Concept
Note that the two approaches discussed are just starting points to define analysis authorization concepts. An accurate investigation of the analysis authorizations requirements is mandatory.
The following considerations apply to analysis authorization concepts:
Factor in authorization requirements during the initial design phase of the SAP BW/4HANA data model.
Use a transparent data model and naming conventions to support the authorization definition.
Define which characteristics are authorization-relevant.
Consider key figure authorizations.
As a general recommendation, consider the following:
All authorization-relevant characteristics are checked when they are included in an InfoProvider used by the query. Avoid flagging too many characteristics as authorization-relevant. This keeps the administrative effort to a minimum and ensure satisfactory performance. To prevent performance from being impaired, we recommend having no more than 10 authorization-relevant characteristics in a query. Authorization-relevant characteristics with the asterisk (*) authorizations are an exception. You can include more authorization-relevant characteristics of this type in a query.
Once the authorization-relevant characteristics have been identified, the next step is determining the suitable approaches for defining Analysis Authorizations. In the scenario depicted in the figure, there are four InfoProviders featuring varying authorization-relevant characteristics. Specific values may require authorization for some, while full authorization is necessary for others.
Approach 1: InfoProvider-based Concept
The starting point for the design of Analysis Authorizations is the InfoProvider and its authorization-relevant characteristics. That means that only one InfoProvider is authorized in an Analysis Authorization.
There might be more than one Analysis Authorization per InfoProvider due to different user-specific authorized values for the authorization-relevant characteristics.
This concept leads to multidimensional analysis authorizations where an analysis authorization contains more than one authorization-relevant characteristic. With this, it is possible to authorize certain combinations of characteristic values.
Remember: The scenario in the following figure is only possible with multidimensional analysis authorizations.
InfoObject-based Concept
The starting point for the design of Analysis Authorizations is the authorization-relevant characteristic (InfoObject). That means that only one InfoObject is authorized in an Analysis Authorization.
On the one hand, the InfoObject-based concept it more flexible when a new authorization-relevant characteristic comes up. Then only one or only a few new analysis authorizations would have to be created.
On the other hand, multidimensional analysis authorizations are not possible with this concept.
Thus, this InfoObject-based concept is more likely used when the requirements for the authorization concepts are lower.
The two approaches do not always have to be considered strictly separated from each other, but can also be used in a mixed form.
Log in to track your progress & complete quizzes