Skip to Content

Imagine you have written a nice CDS view, e.g. as follows:

@AbapCatalog.sqlViewName: ‘Z_T100_SABDEMOS’

define view z_t100_sabapdemos

  as select from t100

    { * }  where arbgb = ‘SABAPDEMOS’

It should select all messages for a distinct message class SABAPDEMOS from database table t100. And of course it does that, as the following code snippet proves:

SELECT *

      FROM z_t100_sabapdemos

      INTO TABLE @DATA(result).

cl_demo_output=>display( result ).

/wp-content/uploads/2015/12/access_cntrl1_846142.gif

Now your’re happy and ship your view, but ….

… someday you get an error message from a target system that users do not see all languages any more:

/wp-content/uploads/2015/12/access_cntrl2_846212.gif

… and some users do not see anything at all (sy-subrc = 4).

You logon to the system and examine the database access with SQL Trace (ST05) and find funny things:

/wp-content/uploads/2015/12/access_cntrl3_846213.gif

“DCL restrictions” what’s that now???

You look at the properties of your view in that system and find in the Problems tab:

/wp-content/uploads/2015/12/access_cntrl4_846214.gif

Uh-huh.

  • You’re view implicitly uses the default annotation @AccessControl.authorizationCheck: #CHECK.

    Documentation says “If Open SQL is used to access the view, an access control is carried out implicitly if a CDS role is assigned to the view.

  • And someone has created a CDS role in a DCL source code for your view!

You find it in ADT:

/wp-content/uploads/2015/12/access_cntrl5_846239.gif

@MappingRole: true

define role role_name {

  grant select on z_t100_sabapdemos

  where ( arbgb ) =  aspect pfcg_auth ( s_develop, objname,

                                                  objtype = ‘MSAG’,

                                                  actvt  = ’03’ )

                    and sprsl= ‘E’ ; }

What does that harmless looking code snippet do?

A CDS role adds an additional selection condition, a so called access condition, to a CDS view! If you access a CDS view that is mentioned in a role, Open SQL from ABAP 7.50 (and SADL Queries from ABAP 7.40, SP10) implicitly consider the access conditions defined in each role.

In our case:

  • A literal condition sprsl=’E’ restricts access to English only.
  • A so called PFCG condition aspect pfcg_auth ( s_develop … ) connects the CDS role to a classical authorization object s_develop and from that the CDS access control runtime generates an access condition that evaluates the authorizations of the current user for that object. Here, a predefined aspect pfcg_auth connects the authorization field objname to the view field arbgb. Additionaly, the user’s authorization is checked if it complies with fixed values for authorization fields objtype and actvt.

Neat!

If you write a view, you must be aware that this can happen. If you don’t want any access restriction, you must decorate your view with the annotation AccessControl.authorizationCheck: #NOT_ALLOWED. Then and only then CDS roles are ignored.

But of course, CDS access control becomes part of your data modeling efforts from ABAP 7.50 on  …

For more information, see ABAP CDS – Access Control.

PS: The CDS roles supported by ABAP CDS up to now are implicitly assigned to each user, so to say. User specific CDS roles are principally possible but not supported yet (those would involve selfdefined aspects). Instead, PFCG conditions offer a new implicit access to classical authorizations.

_

To report this post you need to login first.

10 Comments

You must be Logged on to comment or reply to a post.

  1. Shai Sinai

    Just out of curiosity,
    1. Will we be able to see what access controls are defined for CDS view (e.g. Where-used function or simple navigation from the objects tree)?

    2. Is the authorization check (pfcg_auth) done in DB level or translated to SQL statement before being sent to DB? (And can it be displayed directly in the trace?)

    (0) 
    1. Horst Keller Post author

      1. Up to now only in problems tab. But I guess there will be demand for more.

      2. As far as I know a generated SQL statement is sent by DBI. The actual realization can be seen but is subject to change. It’s not necessarily a simple WHERE but also access views can be generated.

      (0) 
          1. Shai Sinai

            2. Well, I’ve already said it’s just out of curiosity 😉

            (In general, I do like to understand “how things work”, even internally).

            (0) 
  2. Tracy Xian

    In case a new CDS view needs to be created from existing CDS view(s),  should we provide the access control for the new CDS view?

    (0) 
    1. Horst Keller Post author

      Yes, if you access a CDS entity in another one no access control is carried out. As a conequence wrapping one view in another one means to circumvent its access controls. You must create a role for the wrapping view too.

      (0) 
  3. Mohit Chopra

    Hello Horst,

    I have couple of doubts regarding DCL roles.

    1. I created a DCL role as displayed below.

    @EndUserText.label: ‘role_label’

    @MappingRole: true

    define role zscarr_role {

        grant select on Zscarr

        where ( CARRID ) =

        aspect pfcg_auth (  Z_CDS_MC,

                            carrid,

                            actvt = ’03’ );

    }

    Its working perfectly fine. In Authorization Object Z_CDS_MC i have Actvt 1 , 2 and 3 checked. What i analyzed is that it does not really matter what actvt i give in DCL Role. For Ex. I gave actvt =’03’ in above Role but it always goes and check What activities are permitted in authorization Object. Just needed to understand why is actvt added as a part of above syntax??

    2. The above role Only works if i try to access data from CDS Entity in Open SQL which is correct as well because all semantics are attached with CDS entity. Just needed to understand if in HANA Database level someone tries to access CDS SQL View which got generated automatically for CDS entity than how will authorization work? Do we need to provide separate authorization at HANA Level where we can only access CDS SQL View?

    (0) 
    1. Horst Keller Post author

      Hi Mohit,

      1) I guess it works as documented. You say, you have all Actvts checked in the authorization object. The documentation says

      • Further optional authorization fields auth_field1,auth_field2 of the authorization object can be specified to which literal values can be mapped using =. In this case, the evaluation only respects those authorizations of the current user in which all values specified in this way exist. Here, the same authorization field can be specified more than once with different values.

      It is merely a filter, which authorizations to check. If you specify actvt = ’03’  (or another) those authorizations are checked, where these value are covered. See also the second bullet point in the example of the documentation.

      2) For that the documentation says

      f a CDS role is defined for a CDS entity, the access conditions are evaluated implicitly each time an object is accessed using Open SQL or using an SADL query …

      and further

      When CDS views used as data sources in different CDS entities are accessed indirectly, no implicit access control takes place. This means the methods and CDS roles used to access CDS entities should be planned carefully when modeling an application. For example, accesses made on CDS entities without associated CDS role can be wrapped in CDS views with associated roles.

      Of course, when you access the physical DB view with Native SQL, the DCL role is not considered at all.

      (0) 

Leave a Reply