Financial Management Blogs by SAP
Get financial management insights from blog posts by SAP experts. Find and share tips on how to increase efficiency, reduce risk, and optimize working capital.
cancel
Showing results for 
Search instead for 
Did you mean: 
marc_roeder
Product and Topic Expert
Product and Topic Expert
13,760


Abstract


The authorization concept of SAP BusinessObjects Planning and Consolidation 10.1, version for SAP Netweaver (short: BPC embedded) is based on BW Analysis Authorizations. There are three layers of authorizations in place: BW backend authorizations, environment authorizations, and Data Access Profiles (DAPs).

The difference between DAPs and the other two layers of authorizations is that DAPs are defined per BPC-model and not per provider as the other two layers are.
The DAP is defined on the basic providers of the model and for CompositeProviders (HCPRs) or MultiProviders, a “lifting” technique is used to determine the authorization on the higher-level provider from the basic providers.

In the first part of this text, we describe the lifting algorithm and discuss its implications. In the second part, we give some examples of authorization configurations on the different layers.

In the usual case where the characteristics of the basic providers are mapped to the same characteristics in the HCPR, this lifting is straight forward. The lifting only really does anything special if there is a non-trivial mapping between the characteristics of the basic providers and the HCPR/MultiProvider.

Preface


Notes 2314554 and 2332057 need to be implemented for this feature to work as described here.

For the sake of readability, this text only talks about HCPRs. However, the same algorithms are valid for MultiProviders. This means that a MultiProvider behaves just like the an HCPR of the same structure.

Analysis Authorizations and DAPs


If a query is run in the context of a BPC environment and model, the applicable authorizations are calculated in the following way:

  1. The Analysis Authorizations B maintained in /nRSECADMIN and assigned to the user directly or via /nPFCG role are extended by the environment authorizations E for the current environment as maintained in /nRSECENVI. The extension is done by simply taking the union of the two lists of authorization objects. The result of this is a set of Analysis Authorizations which potentially grants access to more objects than the initial set B.

  2. This extended set of authorizations is then restricted again by the DAP of the BPC-model in question. This restriction is an intersection of the authorization objects.


In effect, the user can only see or write data which he/she is authorized to by the DAP and the union of environment and BW authorizations. In short, this can be summarized as








A = (B∪E) ∩ D



(1)



Where A is the resulting authorization, B is the ordinary BW Analysis Authorization, E is the environment authorization for the current environment, and D is the DAP-authorization for the current model.

Note 1: If no DAP is maintained, this is interpreted as D=. Hence, no access to the data will be granted.

Note 2: If no Environment/Model context is used, only the Analysis Authorizations B are considered (see the last chapter).

Calculating the DAP-Authorization Part


Relevant Providers


The basic difference between ordinary BW analysis authorizations (as well as environment authorizations) and BPC’s Data Access Profile (DAP) concept is that DAPs are defined per model for all authorization-relevant characteristics (“dimensions” in BPC terminology). It is not possible to set an authorization for an individual provider of the model within the DAP.

The list of relevant characteristic is determined by considering all authorization-relevant characteristics of all basic providers of the model. This includes all InfoCubes, DSOs (ordinary or advanced) which are added to the model explicitly. It also includes all part-providers of all HCPRs of the model.
In short: the DAP is defined on the characteristics of the basic providers of the model.

The DAP-authorization on HCPRs (no matter whether they are members of the model themselves or just theirs part providers) are calculated using a lifting algorithm.

The Lifting Algorithm


When the authorization for an HCPR is requested, the authorizations B and E in equation (1) are maintained on the HCPR level, but D is defined on the model level. In order to evaluate (1), the DAP authorizations are lifted using the following rules

  1. For a target characteristic in the HCPR, the pre-image in the basic providers is looked up and the authorization defined in the DAP is copied

  2. If a characteristic which is not part of the DAP (not part of the model) supplies a characteristic in the HCPR, the *-authorization (all-authorization) is used in the target

  3. If a characteristic of the HCPR is supplied from different source characteristics, the intersection of the source authorizations is taken


This leads to the lifted DAP authorizations D’ which are now defined on the characteristics exposed by the HCPR. So in this case, the resulting authorization is calculated as








A = (B ∪ E) ∩ D’



(2)



Examples


1. Unique Mapping


Suppose we have a InfoCube contained in an HCPR (as the sole part provider). In the HCPR, characteristics might be mapped to other characteristics provided they all refer to a common base characteristic.

So let’s assume that the characteristic ZCOUNTRY references 0COUNTRY and we have the following mapping between the InfoCube and the HCPR:
















InfoObject (InfoCube)



Mapping target in HCPR



ZCOUNTRY



0COUNTRY



0CALYEAR



0CALYEAR



The DAP of the model is defined on the characteristics of the basic providers of the model. If the HCPR or the InfoCube is part of the model, a possible DAP could look like this:
















InfoObject



DAP D: authorized values



ZCOUNTRY



DE, FR, GB



0CALYEAR



2015, 2016



Note that 0COUNTRY is not part of the DAP. This is true no matter whether the HCPR or the InfoCube or both providers are explicitly added to the model.

If a query is run on the HCPR, the resulting DAP-authorizations are:



















Characteristic (of HCPR)



Source characteristic for mapping



Resulting authorization D’



0COUNTRY



ZCOUNTRY



DE, FR, GB



0CALYEAR



0CALYEAR



2015, 2016



The authorization for 0CALYEAR is simply read from the DAP, while for 0COUNTRY, the pre-image ZCOUNTRY is looked up and the authorization of ZCOUNTRY is applied to 0COUNTRY.

2. Complex Mappings


In HCPRs with multiple part providers, a characteristic exposed by the HCPR might be supplied by different characteristics of the part providers (all of them need to reference a common characteristic).

In the following example, we have one InfoCube which supplies the HCPR’s-characteristic 0COUNTRY from the InfoCube’s characteristic ZCOUNTRY. And we could have a second InfoCube which HCPR’s-characteristic 0COUNTRY from the characteristic ZCNTRY2.
There’s also some cross-mapping happening here: InfoCube 1 supplies ZCROSS2 from ZCROSS1 and InfoCube 2 supplies ZCROSS1 from ZCROSS2. This essentially leads to an exchange of names of the two characteristic between the InfoCube layer and the HCPR layer.
Let’s not spend too much time on the question whether this kind of modeling is helpful for understanding the data.
























InfoObject (InfoCube 1)



Mapping target in HCPR



ZCOUNTRY



0COUNTRY



0CALYEAR



0CALYEAR



ZCROSS1



ZCROSS2



ZCROSS2



<not mapped>



























InfoObject (InfoCube 2)



Mapping target in HCPR



ZCNTRY2



0COUNTRY



0CALYEAR



0CALYEAR



ZCROSS1



<not mapped>



ZCROSS2



ZCROSS1



The DAP is defined on the union of all characteristics of all part providers. Let’s assume it looks like this:




























InfoObject



DAP D: authorized values



ZCOUNTRY



DE, FR, GB



ZCNTRY2



DE, ES, IT



0CALYEAR



2015, 2016



ZCROSS1



1, 2, 3



ZCROSS2



3, 4



Now the DAP authorizations are lifted to the HCPR like this:


































Characteristic (of HCPR)



Source characteristics
for mapping



Authorization
from source



Resulting authorization D’



0COUNTRY



ZCOUNTRY
ZCNTRY2



DE, FR, GB
DE, ES, IT



DE



0CALYEAR



0CALYEAR



2015, 2016



2015, 2016



ZCROSS1



ZCROSS2



3, 4



3, 4



ZCROSS2



ZCROSS1



1, 2, 3



1, 2, 3



Note that the cross-mapping of ZCROSS1 and ZCROSS2 defined in the HCPR leads to a cross-mapping of the authorization.

3. HCPR with External Part Provider


Up to now, we looked at cases where all part providers were considered providers of the model. Be it because the part providers were explicitly added to the model’s provider list or be it because the HCPR was defined as a provider of the model.

With the HCPR definition as in example 2, we now assume that InfoCube 1 is added to the provider list of the model, but not InfoCube 2 or the HCPR. Let’s further assume that there is some other provider InfoCube 3 in the model and that the characteristics ZCROSS2 is part of InfoCube 3 (but ZCOUNTRY is not).

The DAP definition could look like this:
























InfoObject



DAP D: authorized values



ZCOUNTRY



DE, FR, GB



ZCALYEAR



2015, 2016



ZCROSS1



1, 2, 3



ZCROSS2



3, 4



Note that 0COUNTRY is not in the DAP definition, because it is not a characteristic of any of the basic providers of the model -- supplied by InfoCube 2 only, but InfoCube 2 is not part of the model.
But as we assumed that the model contains InfoCube 3 and InfoCube 3 contains ZCROSS2, this characteristic is a part of the DAP.

In this case, the lifting algorithm calculates the following result:


































Characteristic (of HCPR)



Source characteristics
for mapping



Authorization
from source



Resulting authorization D’



0COUNTRY



ZCOUNTRY
ZCNTRY2



DE, FR, GB
<all>



DE, FR, GB



0CALYEAR



0CALYEAR



2015, 2016



2015, 2016



ZCROSS1



ZCROSS2



3, 4



3, 4



ZCROSS2



ZCROSS1



1, 2, 3



1, 2, 3



The resulting authorization for 0COUNTRY is created by intersecting the authorization for ZCOUNTRY from the DAP (that is: DE, FR, GB) with the authorization of ZCNTRY2 which is lifted as * (the all-authorization), because ZCNTRY2 is not part of the model.

Intersecting the DAP with Backend/Environment Authorizations


In the above section, we looked at the D in the equation . As we have seen above, the DAP authorizations D are lifted to the HCPR to create the authorizations D’.


The authorizations for the HCPR are hence calculated as . In particular, the lifting is done first and then the intersection is taken (rather than intersecting on base level first and then lifting the result).



Examples


1. Unmapped Characteristics


Consider a BPC model containing an HCPR. The DAP for this model is defined on all authorization-relevant characteristics of all part-providers of the HCPR.

Suppose the HCPR contains one InfoCube which consists of characteristics ZCOUNTRY and 0CALYEAR. Assume further that only ZCOUNTRY is mapped in the HCPR (using the trivial mapping).
Both ZCOUNTRY and 0CALYEAR are DAP-relevant but it is possible to access the HCPR even if no values are maintained for the non-mapped characteristic in the DAP:































InfoObject



Backend Authorization BE



DAP authorizations D



Resulting authorization for HCPR in Env/Mod context



InfoCube



HCPR



ZCOUNTRY



DE, GB



FR, IT



DE, FR, GB



FR



0CALYEAR



2015, 2016



<not mapped>



<none>



<aggregation>



Note that the resulting authorization on the mapped characteristic is calculated by intersecting the DAP with the backend authorizations of the HCPR, not the InfoCube.

2. Different Backend Authorizations on HCPR and Part Providers


Looking at the above example again, we can see the effect of different authorizations on the HCPR and the part provider. In BW Analysis Authorizations, it is possible to grant different access rights to the same data depending on the provider that data is consumed with.

In our example, if the user consumes the data of the InfoCube through a query built on top of the InfoCube rather than the HCPR, he gets the following access rights:




























InfoObject



Backend Authorization BE



DAP authorizations D



Resulting authorization for InfoCube in Env/Mod context



InfoCube



HCPR



ZCOUNTRY



DE, GB



FR, IT



DE, FR, GB



DE, GB



0CALYEAR



2015, 2016



<not mapped>



<none>



<none>



So because of the unmaintained DAP on 0CALYEAR, the user is not able to see any data when looking at the InfoCube directly. Also the authorization for ZCOUNTRY has changed completely because now the intersection of D is taken with the authorization of the InfoCube.

Here is another example with an authorization set for 0CALYEAR in the DAP:
































InfoObject



Backend Authorization



DAP authorizations D



Resulting authorization



InfoCube



HCPR



InfoCube



HCPR



ZCOUNTRY



DE, GB



FR, IT



DE, FR, GB



DE, GB



FR



0CALYEAR



2015, 2016



<not mapped>



2015



2015



<aggregation>



Usecase: Enforcing the Use of Environment/Model


DAP authorizations as well as the work status feature only take effect if an Environment/Model context is set.

So by running a query in a frontend without Environment/Model context, it might be possible to plan on regions which would be locked under a work status if Environment/Model was set. The restrictions coming from DAPs and the environment authorizations are not applied in this scenario.

To enforce the use of BPC by enforcing the setting of Environment/Model in all frontends, Analysis Authorizations can be used. By giving no basic Analysis Authorizations on the relevant providers at all (i.e.  in the previous notation) and putting all backend authorizations into environment authorizations (E in our previous notation), these providers will not be accessible if Environment/Model is not set. This follows from the fact that only B is evaluated if Environment/Model is not set.

1 Comment