Skip to content

ABAP Keyword Documentation →  ABAP - Dictionary →  ABAP CDS in ABAP Dictionary →  ABAP CDS - Access Control →  ABAP CDS - DCL Statements →  ABAP CDS - DEFINE ROLE →  ABAP CDS - DEFINE ROLE, condition 

ABAP CDS - DEFINE ROLE, pfcg_condition

Other versions: 7.31 | 7.40 | 7.54

Syntax


... ( [element1 |{ element1[, element2 ...] } 

    [, element2 |{ element1[, element2 ...] } ...]] ) 
         =|?= ASPECT pfcg_auth 

                ( auth_object [IN SCENARIO 'scenario'], 

                 [mapped_field1|{
PFCG_MAPPING = pfcg_mapping}[, 

                  mapped_field2|{
PFCG_MAPPING = pfcg_mapping} ...]][, 

                  auth_field1 = 'value'[, 

                  auth_field2 = 'value' ...]] ) ...

Effect

PFCG condition as part of an access condition cond_expr in an access rule of the statement DEFINE ROLE in CDS DCL. A PFCG condition joins the elements of the CDS entity specified on the left side of the operator = or ?= with the authorizations specified on the right side (and granted using the classic role editor (transaction PFCG) ). CDS access control takes this information and the authorizations of the current user and uses it to create fixed logical conditions, which are evaluated each time the object is accessed.

  • Left Side
  • The left side is a parenthesized comma-separated list consisting of multiple CDS elements of a CDS entity (or one element or no elements) for which the access condition is defined. An element element can be specified directly or by using a path expression path_expr and must have one of the valid data types. In a multivalue path expression, it is sufficient for the condition to be true for just one of the values.
  • Right Side
The right side is introduced using ASPECT pfcg_auth. Here, pfcg_auth is a predefined aspect used to associate the CDS elements with the authorizations of the current user for an authorization object of the SAP authorization concept. This association is made in a parenthesized comma-separated list:
  • The name of an existing authorization object is defined using auth_object.
  • mapped_field1, mapped_field2 are used to specify the names of the authorization fields of the authorization object to map them to the CDS elements on the left side in the specified order. The number of CDS elements must match the number of authorization fields. It is possible to map a single authorization field to multiple CDS elements. By default, CDS access control evaluates all authorizations of the current user for the specified CDS elements in accordance with this assignment. The PFCG condition is true whenever an authorization is present.
  • 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.
  • If the parentheses on the left side are empty, which means that no element from the CDS entity is specified, no authorization field mapped_field can be specified after auth_object. If further optional authorization fields auth_field1, auth_field1, ... are specified, the same applies as before. CDS access control evaluates all authorizations (or those authorizations specified using auth_field1, auth_field1, ...) of the current user for the authorization object. If there is at least one authorization, the PFCG condition is true, else false.

If the operator ?= is used, the evaluation is made in the same way as when using =. The condition is also met, however, if all CDS elements in the left parentheses have the null value or their type-dependent initial value. This applies even if the user does not have an authorization for the specified authorization object.

The operator NOT can only be specified in front of PFCG conditions with empty parentheses on the left side, namely those without CDS elements element and mapped authorization fields mapped_field. The following applies with respect to the order in which a PFCG condition is evaluated:

  • If multiple authorizations are evaluated, the resulting conditions are joined using a logical "or".
  • In the conditions of each authorization used, the values for the authorization fields in question are joined using a logical "and".
  • If there are multiple values for an authorization field, they are joined using a logical "or".

When these rules are applied to the access condition actually used by CDS access control, field values from authorizations are compared with content from CDS elements. Here, the field values are converted to the dictionary types of the CDS elements.


Notes

  • The access conditions produced by the rules above are transformed internally to selection statements by the ABAP runtime environment. In ABAP SQL reads, the additional conditions can be viewed in the SQL Trace tools (transaction ST05). The internal implementation can be made using WHERE conditions or common table expressions and can change between releases.

  • The key elements of the CDS entity play a key part in internal selection statements. In the CDS data definition, these elements should either be defined so that they identify a unique row or no key elements should be defined at all. If this is not the case. unexpected results can arise.

  • PFCG conditions with non-empty parentheses on the left side cannot be negated using the operator NOT, since this entails the opposite of an authorization check and hence unexpected results.

  • If a full authorization exists within a PFCG condition for an authorization field, no condition is created for the CDS element specified on the left side. This makes the PFCG condition accept all values, including the null value. If this behavior is unwanted, AND can be used to expand a literal condition element IS NOT NULL.

  • It is advisable to specify an element of the CDS entity directly and to only use path expressions in exceptional cases.

  • The operator ?= is applied to all CDS elements in the left parentheses. It cannot be restricted to individual elements.

  • The global and context-specific disabling of authorization checks (in transactions SU24 and SU25) is respected.

Addition

... IN SCENARIO

The optional addition IN SCENARIO can be used to apply the switchable authorization (transaction SACF) to an authorization object.

The following applies to the addition IN SCENARIO:

  • Unlike direct use in program code (CL_SACF=>AUTH_CHECK_SPEC), the use of switchable authorizations has the restriction that there is no interaction with the user interface (such as warning messages or dialogs in recording mode). The recording modes behave as if the check method were called using the parameter ID_SILENT = 'X' and do not persist any data in the SACF configuration.
  • The security audit log, which can be enabled from the SACF configuration contains the name of the CDS entity with the “STOB” flag, as well as the name of the authorization object and the requested and filter fields.
  • If the PFCG condition uses PFCG mappings, these must also have the addition IN SCENARIO and name the same scenario.

Examples

The following abstract examples explain various types of PFCG conditions:

  • The following example is a typical case. Multiple elements, element1, element2, are mapped to different authorization fields, field1, field2, of an authorization object auth_object. Those authorizations of the current user are evaluated in which a particular activity is allowed.
@MappingRole: 'true'
DEFINE ROLE demo_role {
    grant SELECT ON entity  WHERE
      ( element1, element2 ) = ASPECT pfcg_auth
          ( auth_object,
            field1,
            field2,
            ACTVT = '02'); }
The current user has two authorizations for the authorization object auth_object:
  • An authorization with the values "a", "b" for the authorization field field1 and the values "c", "d" for the authorization field field2
  • An authorization with the value "X*" for the authorization field field1 and the value "Y" for the authorization field field2
The access condition added to the CDS entity entity by CDS access control using a logical "and" can appear as follows (when expressed in SQL):
... ... AND ( ( element1 = 'a' OR element2 = 'b' ) AND
          ( element2 = 'c' OR element2 = 'd' ) OR
          element1 LIKE 'X%' AND
          element2 = 'Y' )
The values of each authorization are joined using AND and the conditions of both authorizations are joined using OR. The wildcard character * is converted to a LIKE condition. The actual variant in question, however, can have a different appearance.
If ?= instead of = is used in the example above, the access condition is expanded roughly as follows:
          ...
          element2 = 'Y' OR
          ( ( element1 IS NULL or element1 = '' ) AND
            ( element2 IS NULL or element2 = '' ) ) )
  • The following example illustrates how the evaluated authorizations are restricted using further authorization fields. Only those authorizations of the current user are used that contain both the activities "02" and "03", plus the authorization field country with the value "DE". Only those rows are read for which the CDS element element matches the authorization field field of these authorizations.
@MappingRole: true
DEFINE ROLE demo_role {
GRANT SELECT ON entity WHERE
  (element) = ASPECT pfcg_auth( auth_object,
                                field,
                                actvt   = '02',
                                actvt   = '03',
                                country = 'DE' );}
  • In the following example, the same authorization field field is used for the items mapped_field and auth_field. If the current user has an authorization with the values "X", "Y", and "Z" for this authorization field, this authorization is used by specifying field = 'X'. CDS access control then uses all three permitted values "X", "Y", and "Z" when the CDS entity is accessed.
@MappingRole: true
DEFINE ROLE demo_role {
GRANT SELECT ON entity WHERE
  (element) = ASPECT pfcg_auth( auth_object,
                                field,
                                field = 'X' ); }
  • No CDS element is specified in the following example. CDS access control prevents data from being read in full if the current user does not have at least an authorization for the authorization object auth_object with the activity "03".
@MappingRole: true
DEFINE ROLE demo_role {
  GRANT SELECT ON entity WHERE
    ( ) = ASPECT pfcg_auth( auth_object, ACTVT = '03' ); }
  • No CDS element or authorization field is specified in the following example. Here, the only requirement is that the current user has at least one authorization (any authorization) for the authorization object auth_object (with any values).
@MappingRole: true
DEFINE ROLE demo_role {
  GRANT SELECT ON entity WHERE
    ( ) = ASPECT pfcg_auth( auth_object ); }


Example

The following abstract example shows a valid negation of a PFCG condition using empty parentheses on the left side with the Boolean operator NOT:

... WHERE NOT ( ) = ASPECT pfcg_auth( auth_object ) ...

The access condition is true if the current user is not assigned the authorization object auth_object. This property can be used, for example, to implement the replacement of one authorization object with another authorization object.


Example

The following CDS role constructs an access rule for the CDS view demo_cds_auth_pfcg. A PFCG condition is specified that associates the CDS element carrid with the authorization field CARRID of the authorization object S_CARRID. If specified, actvt='03' restricts the CDS access control check to the associated authorizations of the current user that have the value "3" in ACTVT.

@MappingRole: true
define role demo_cds_role_pfcg {
  grant select on demo_cds_auth_pfcg
  where (carrid) =
  aspect pfcg_auth (s_carrid, carrid, actvt='03'); }

The CDS view is as follows:

@AbapCatalog.sqlViewName: 'DEMO_CDS_PFCG'
@AccessControl.authorizationCheck: #CHECK
define view demo_cds_auth_pfcg
as select from
scarr
{
key carrid,
carrname,
currcode,
url
};    

The program DEMO_CDS_AUTH_PFCG accesses the view.

  • There is no implicit authorization check when the CDS database view is accessed. Instead, the rows without authorization are removed from the results later using the statement AUTHORITY-CHECK.
  • When the CDS is accessed, the SELECT statement only reads the data for which the current user has authorization.

Continue

ABAP CDS - DEFINE ROLE, pfcg_mapping

ABAP CDS - DEFINE ROLE, Converting Field Values