Page tree
Skip to end of metadata
Go to start of metadata

Data Based Authorization Concept for Analytic Queries

CDS access controls are based on CDS roles that are defined in Data Control Language (DCL), see  ABAP CDS views(and SAP Annotations) for further information. When CDS entities that are assigned to a CDS role are accessed, additional access conditions are evaluated. In case of an Analytic Query (based on a CDS Cube with access controls)this means that during query runtime, the authorized values are added to the WHERE clause of the SQL statement with a logical AND(done by the Kernel). In general, access controls are only evaluated when there is an Open SQL (ABAP SQL) access on the entity the access control is defined for('grant select on' - see example below). Access controls defined for entities that are used in another entity are ignored, so, only the top-level entity (accessed by SQL) is evaluated. However, note that views which are created by using the app Custom CDS Views(the YY1* views) inherit DCL definitions from the base provider view automatically(for details see below). 

When we compare this with the concept of OLAP Authorizations, we notice the following:

  • Authorized values are automatically applied as filter values. Hence, in case of missing authorizations, a user does not get an error message like 'no authorization...' but no or less data displayed in the query.
  • In the area of OLAP authorizations often variables replaced by the authorized values of the user are used. This, of course, is not necessary when queries are based on transient CDS providers with Access Controls.
Important to know
  1. You can define data restrictions for the data categories CUBE and DIMENSION(with annotation AccessControl.authorizationCheck and the corresponding Access Controls)
  2. The annotation AccessControl.authorizationCheck is ignored for an analytic query. This also fits the general concept of OLAP Authorizations where authorizations do not depend on the query.
  3. If a certain dimension is restricted on Cube level, this does not imply a corresponding restriction on the dimension itself. So, e.g. if you use the F4 help for a variable defined on such a dimension and the so called M-Mode is used(see F4 Modes), all master data values are displayed. If you want to avoid this, you need to define corresponding access controls for the dimension as well. See Examples I and II.
  4. If a certain dimension is authorization relevant this has no impact on the check of transactional data on the level of a corresponding CDS Cube. See Example III.
  5. Important remark the app Custom CDS Views: views which are created with this app inherit DCL definitions from the base provider view automatically. In this case, please always make sure in the custom CDS view and its underlying provider view, that for each key combination, only one record exists. (All other non-key fields only contain attribute values.) This is necessary since the DCL inherit procedure will generate left outer joins to the underlying provide view. The multiple records in the underlying provider view for the same key combination of keys will lead to wrong query results(similar to the situation explained in Ambiguous Join).
  6. It is not possible to use the concept of OLAP Authorizations for Analytic Queries(when the Infoprovider is based on an ABAP CDS object of Datatype CUBE). You need to use CDS access controls in order to manage user related access restrictions.
  7. In BW, in addition to OLAP authorizations, a basis authorization is necessary in order to run query. This authorizations are checked first, the corresponding authorization objects are S_RS_COMP1 and S_RS_COMP. If this basis authorization-check is successful, the OLAP-authorization-check (which checks the analysis-authorizations)is performed. See note 540720 and OLAP Authorizations for further details. This also applies to CDS queries. A user needs the corresponding authorization regarding S_RS_COMP1 and S_RS_COMP, otherwise the error BRAIN 800 occurs. As of BW752 release you can also use the authorization object SDDLVIEW instead of S_RS_COMP/1(SDDLVIEW is checked first, if nothing is maintained, the system accesses S_RS_COMP as in the past). It has the advantage that you can use the DDLS name(in UPPERCASE) of the CDS query and cube instead of the so called BW ODP names for S_RS_COMP, see Example and also note 3088823.
  8. In case the characteristic 0TCAKYFNM is authorization relevant(see note 820183), you need to assign a proper authorization to the user for the key figures used in the query. See Example.
  • The function "Show DCL authorizations for CDS"  in RSRT shows the restriction coming from the access control. See Example I below.
  • A manual authorization test for CDS Views can also be done with transaction SACM, see Example I below.
  • It might happen that the DCL sources become inconsistent. In such a case it is necessary to re-create a clean state for all DCL sources which is called initial load. See note 2274570 for further details.
Important SAP Consulting Notes and Wiki Pages

Example I

CDS view Zstpe_cds_V4 has the access control Authorization Check set to 'CHECK' meaning that it is 'authorization relevant'. 

The access control ZSTPE_ACC_CONT_4 defines a role which refers to the authorization object S_DBCON: the auhtorized values for the field AircraftType are retrieved from the corresponding user authorizations for this auth. object (field DBA_DBSID)

When we run the adhoc query for the transient provider "2CZSTPESQLVIEW4" (see CDS Naming Conventions) in RSRT and set the filter PlaneType = A319, but we get no data displayed:

Then we use the debug function "Show DCL authorizations for CDS" and "Display SAP Hana Query" to get more information:

The Hana Statement (open SQL) does no show any details about the authorized values, but of course the restriction of the query:

In contrast to the open SQL statement displayed in RSRT, the native SQL statement of an ST05 SQL trace show the complete WHERE clause:

Please note that the following two restrictions where added

  • "MANDT" = '003'    <- client restriction (added independent of the authorizations)
  • "AIRCRAFTTYPE" LIKE 'Q%'     <- auhorized values

So, it is correct that the query does not return data since the there is no intersection between the query filter and the authorized values of the user!

The function "Show DCL authorizations for CDS" in RSRT shows the client restrictions and the restriction coming from the access control (manual authorization test for CDS Views can also be done with trasnaction SACM) 

In case the user has no authorization at all the following statement is generated (which obviously can never return values)

Example II: Cube authorization relevant, F4 Help not Restricted

The following 'normal' BW query is defined on the CDS Cube from above. It uses a BW variable for the field Aircrafttype which is authorization relevant in this Cube.

When we use the F4 help for this variable(we execute the query in n RSRT), all values are displayed(when F4 Mode M used!), so we also get values displayed the user is actually not authorized to see on the cube level(transactional data). This effect is caused by the fact that the dimension Aircrafttype is not authorization relevant although it is on Cube level. Hence, in general, it makes sense to assign the same authorizations to the cube and the corresponding dimension.

If we choose the value A319-100 and run the query, no data is returned(since the user is not authorized to see this aircraft type):

In the ST05 SQL trace we can see that, in addition to the filter value A319-100 of the query, the system added the corresponding filter generated by the authorization(see Example I):

Example III: only Dimension authorization relevant

We check a 'normal' BW query which is based on a CDS Cube which is not authorization relevant. However, the dimension Aircrafttype of this Cube is authorization relevant.




When we run the query in RSRT and use the F4 helpy(F4 Mode M used) for the variable, no values(apart from #) are displayed since the user has only authorization to see values with the pattern Q* - and such values do not exist.

SQL statement(ST05 trace) of F4 help:

If we leave the variable blank and run the query we can see all aircraft types available in the provider:

  • No labels