◉ CDS roles defined using the DCL statement DEFINE ROLE. Currently, a CDS role is mapped to each user implicitly. This is why they are also known as mapping roles.
◉ Access conditions defined in a CDS role CDS entities. Access conditions can be the following:
◉ Literal conditions that compare elements of a CDS entity with literal values.
◉ PFCG conditions that associate elements of a CDS entity with authorizations in the SAP authorization concept.
If 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 (unless access control is disabled using the value #NOT_ALLOWED for the annotation @AccessControl.authorizationCheck. If access control is enabled, only that data is read that meets the access conditions.
Each CDS role is defined a separate piece of CDS source code. This CDS source code can only be edited in the ABAP Development Tools (ADT). When activated, the CDS role is characterized as a global internal object in ABAP Dictionary. The CDS source code of a CDS role is edited in a different editor from the CDS source code of a CDS entity (CDS view or CDS table function). The ADT documentation describes how the different types of source code are created.
Notes
◉ CDS access control provides an additional method for checking authorizations in the SAP authorization concept. Authorizations in the SAP authorization concept are based on authorization objects and are granted in the classic role editor (transaction PFCG). In classic authorization checks, the authorizations are either checked implicitly (such as when transactions are called) or explicitly using the statement AUTHORITY-CHECK. CDS access control expands these checks to include implicit evaluations of access conditions.
◉ It is advisable to continue to use classic authorization checks for start authorizations (used to check whether a user can start an application in the first place). CDS access control can be used within an application to perform instance-based authorization checks (used to check the authorization of a user as defined by the data model and the data in question).
◉ When CDS entities are accessed using Open SQL, ABAP programs cannot distinguish whether data is not read because it does not exist or because they are not allowed by CDS access control.
◉ Currently, CDS roles can only be defined for CDS views and not for CDS table functions. Implicit access control only takes place when a CDS view is accessed directly using Open SQL or using an SADL query. 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.
◉ ABAP CDS does not currently support assignment roles, a category of role based on the CDS data model that needs to be assigned to users explicitly by the user administrator.
ABAP CDS - DCL Statements
The data control language DCL of the ABAP CDS follows the general CDS syntax rules and comprises the following statement for the definition of CDS roles:
◉ DEFINE ROLE
Note
DCL has its own editor in ADT, which is documented there.
ABAP CDS - DEFINE ROLE
Syntax
@MappingRole: true
[@role_annot1]
[@role_annot2]
...
[DEFINE] ROLE role_name {
GRANT SELECT ON cds_entity WHERE condition [AND|OR condition] ...;
[GRANT SELECT ON cds_entity ...;]
... }
Effect
Defines a CDS role called role_name in CDS source code. A CDS role associates one or more CDS entities with CDS access control. An access condition is defined in the role for each of these CDS entities. When a CDS entity of this type is accessed using Open SQL or an SADL query, the access condition is evaluated as an additional selection condition.
The annotation @MappingRole must be listed before the definition of the role with DEFINE ROLE. It is also possible to list further annotations before the role definition: @role_annot1, @role_annot2, and so on. The annotation @MappingRole is used to define the CDS role as a mapping role , assigned to every user regardless of the client.
The CDS entities are specified in curly brackets after GRANT SELECT ON. Currently, only CDS views defined using DEFINE VIEW can be specified for cds_entity. It is not possible to specify CDS table functions defined using DEFINE TABLE FUNCTION. At least one CDS entity must be specified. Multiple CDS entities are separated using a semicolon (;). A single CDS entity can be specified more than once in a single CDS role or in multiple CDS roles.
For each CDS entity cds_entity specified in the CDS role, a WHERE clause must be used to defined an access condition. The access condition can consist of subconditions condition joined using the operators AND or OR. Here, AND is a stronger join than OR. Subconditions can be placed in parentheses, ( ), as follows:
◉ Parentheses must not be nested.
◉ Precisely two subconditions must be joined in one set of parentheses.
◉ A maximum of four sets of parentheses can be joined with each other.
The subconditions condition of an access condition are as follows:
◉ Literal conditions that use values specified literally to restrict access
◉ PFCG conditions that evaluate authorizations in the SAP authorization concept based on authorization objects.
When a CDS entity specified in the definition of a role is accessed using Open SQL or an SADL query, the access condition is evaluated implicitly and its selection restricted accordingly.
◉ In SELECT reads, a logical "and" adds an access condition to the selection condition of the statement passed to the database by the database interface.
◉ If reads are performed using an SADL query, the access condition is also added to the query internally.
If a CDS entity is specified more than once in a CDS role or in multiple CDS roles, the resulting access conditions are joined using a logical "or".
Notes
◉ Access controls are applied to CDS entities (CDS views) by default when accessed using Open SQL. The associated annotation @AccessControl.authorizationCheck has the default value #CHECK.
◉ In this case, CDS entities without assigned roles produce a syntax check warning in the DDL editor. This can be disabled using the annotation value #NOT_REQUIRED. The value #NOT_REQUIRED does not, however, disable implicit access control.
A CDS role can be defined for a CDS entity in every package and in every system and dictates that implicit access control applies. To disable access control for a CDS entity, the value #NOT_ALLOWED must be used for the annotation @AccessControl.authorizationCheck. In this case, the definition of a role for the CDS entity produces a syntax check warning in the DCL editor.
◉ If a CDS role is defined for a CDS entity, this is displayed as information about its CDS source code on the Problems tab in the ABAP Development Tools (ADT). The view must first be configured so that this information is displayed.
◉ The parenthesis rules above for subconditions in access conditions restrict these conditions to the situations discussed, with the following being the most significant:
( cond1 OR cond2 ) AND ( cond3 OR cond4 ) AND ...
(Here, a maximum of four ANDs are allowed.) Parentheses should only be used for this purpose and not to make code easier to read.
◉ Separate CDS source code must be created for each CDS role. The CDS source code of a CDS role is edited in a different editor from the CDS source code of a CDS entity (a CDS view or CDS table function). The ADT documentation describes how the different types of source code are created.
Example
The following CDS role defines an access condition for the CDS view demo_cds_auth_lit_pfcg. Both a PFCG condition for the authorization object S_CARRID and a literal condition for the currency field are specified.
@MappingRole: true
define role demo_cds_role_lit_pfcg {
grant select on demo_cds_auth_lit_pfcg
where (carrid) =
aspect pfcg_auth (s_carrid, carrid, actvt='03') and
currcode = 'EUR'; }
The CDS view is as follows:
@AbapCatalog.sqlViewName: 'DEMO_CDS_LITPFCG'
@AccessControl.authorizationCheck: #CHECK
define view demo_cds_auth_lit_pfcg
as select from scarr { key carrid,
carrname,
currcode,
url };
The program DEMO_CDS_AUTH_LIT_PFCG uses SELECT to access the view. CDS access control limits selections to that data for which the current user has an authorization (in the classic role editor in transaction PFCG) and that meets the literal condition.
➥ ABAP CDS - DEFINE ROLE, role_annot
Syntax
... @annotation ...
Effect
Specifies an annotation annotation as a role annotation in the definition of a CDS role of the ABAP CDS in front of the statement DEFINE ROLE. The character @ must be placed in front of the name annotation of the annotation. The table below shows the possible ABAP annotations that can be specified, and their meanings. No other annotations can be specified.
◉ EndUserText Annotations
◉ MappingRole Annotations
The first column displays the name annotation of an ABAP annotation and the second column displays its meaning. The third column shows the possible values value. The fourth column displays the value, which has been set implicitly for value, if the annotation is not used explicitly. If nothing is specified for value, the annotation should be specified without a value.
EndUserText Annotations
| annotation | Meaning | Possible Values | Default Value |
| EndUserText.label | Translatable short text of the CDS role | Character string with maximum 60 characters | - |
Note
ABAP annotations introduced using EndUserText are used to define translatable semantic texts for a CDS object. The value of an annotation like this is saved in special tables that have a language key and that are translatable. The value specified in the source code should consist of text in the original language of the CDS source code and is translated into the required languages.
MappingRole Annotations
| annotation | Meaning | Possible Values | Default Value |
| MappingRole | MappingRole | MappingRole | false |
Note
Every definition of a CDS role must currently contain the ABAP annotation MappingRole with the value true.
➥ ABAP CDS - DEFINE ROLE, condition
Syntax
... literal_condition|pfcg_condition ...
Effect
Part of an access condition in the WHERE clause of the statement DEFINE ROLE in the ABAP CDS DCL. Two categories of conditions can be specified, which can be combined using AND or OR:
◉ Literal conditions literal_condition that compare an element of a CDS entity with fixed values.
◉ PFCG conditions pfcg_condition that associate an element of a CDS entity with authorizations in the SAP authorization concept.
On the left side of a condition of this type, it is possible to specify elements of the CDS entity for which the access condition is defined directly or using path expressions. The following restrictions apply:
◉ Only certain data types are permitted.
◉ Path expressions path_expr in the DCL have the same syntax as path expressions in the DDL, with the difference that literal values in parameter passes or conditions cannot contain commas (,) or section symbols (§). If specified, a cardinality [1:] cannot contain any blanks, as before.
Notes
◉ It is advisable to specify an element in a CDS entity directly in the DCL and to only use path expressions in exceptional cases.
◉ The way an access condition defined in a CDS role for a CDS entity is characterized when the CDS entity is accessed using Open SQL can be viewed in the SQL Trace tool (transaction ST05). This implementation is not fixed, however, and can change between releases.
1. ABAP CDS - DEFINE ROLE, literal_condition
Syntax
... element operator 'value' ...
Effect
Literal condition as part of an access condition in the WHERE clause of the statement DEFINE ROLE in the ABAP CDS DCL. A literal condition uses a logical operator operator in a relational expression to compare an element element (in the CDS entity for which the access condition is defined) with a literal value value in quotation marks. The element element can be specified directly or by using a path expression path_expr and must have one of the valid data types.
When a literal condition is evaluated by CDS access control, only those rows are selected in which the content of the CDS element element meets the condition.
Notes
◉ Within the definition of a role, literal conditions can be used together with PFCG conditions or as individual conditions.
◉ It is advisable to specify an element of the CDS entity directly and to only use path expressions in exceptional cases.
Example
The following CDS role defines an access condition for the CDS view demo_cds_auth_literal. A single literal condition is specified for the element carrid in the CDS view.
@MappingRole: true
define role demo_cds_role_literal {
grant select on demo_cds_auth_literal
where carrid = 'LH'; }
The CDS view is as follows:
@AbapCatalog.sqlViewName: 'DEMO_CDS_LITERAL'
@AccessControl.authorizationCheck: #CHECK
define view demo_cds_auth_literal
as select from scarr { key carrid,
carrname,
currcode,
url };
The program DEMO_CDS_AUTH_LITERAL uses SELECT to access the view. CDS access control selects only that data that matches the literal condition. This means that a maximum of one row is selected regardless of any other conditions in the view.
➥ ABAP CDS - DEFINE ROLE, operator
Syntax
... operator ...
Effect
Operator of a comparison expression in literal conditions in the WHERE clause when defining a role using DEFINE ROLE in the ABAP CDS DCL. The operator compares a left side and a right side. The left side is always an element of the CDS entity to which the rule applies. The right side is represented using a literal value. The result of the expression is true or false.
| operator | True if |
| = | The value of the left side is equal to the value of the right side. |
| <> | The value of the left side is not equal to the value of the right side. |
| < | The value of the left side is less than the value of the right side. |
| > | The value of the left side is greater than the value of the right side. |
| <= | The value of the left side is less than or equal to the value of the right side. |
| >= | The value of the left side is greater than or equal to the value of the right side. |
| [NOT] LIKE | The string on the left side matches (does not match) the pattern on the right side. The percent sign (%) can be used as a placeholder for any string and the underscore character (_) for any single character. |
| IS [NOT] NULL | The value on the left side is (not) the null value. |
Note
The operator LIKE does not have the addition ESCAPE in the DCL for defining an escape character for the placeholders % and _.
Syntax
... ( [element1 [, element2 ...]] ) =
ASPECT pfcg_auth
( object, [mapped_field1 [, mapped_field2 ...]]
[, auth_field1 = 'value' [, auth_field2= 'value' ...]] ) ...
Effect
PFCG condition as part of an access condition in the WHERE clause of the statement DEFINE ROLE in the ABAP CDS DCL. A PFCG condition joins the elements of the CDS entity specified on the left side of the operator = with the authorizations specified on the right side (and granted using the classical 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.
◉ 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.
◉ The predefined aspect pfcg_auth must be specified on the right side introduced using ASPECT. This aspect is used to associate the CDS elements with the authorizations of the current user for an authorization object in the authorization concept. This association is made in a parenthesized comma-separated list:
◉ The name of an existing authorization object is defined using 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 the same authorization field to multiple CDS elements, but it is not possible to specify multiple authorization fields for a single CDS element. By default, CDS access control evaluates all authorizations of the current user for the specified CDS elements in accordance with this mapping. Only those rows are selected for which an authorization exists.
◉ 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 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 at least one authorization exists, this applies to the entire CDS entity and CDS access control does not apply any additional selection conditions. If there are no authorizations, no data is read.
The following applies with respect to the hierarchy of the evaluation of a PFCG condition:
◉ 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 mapped to the dictionary types of the CDS elements.
Notes
◉ The access conditions that result from the rules above are internal objects from CDS control. In Open SQL reads, the additional conditions can be viewed in the SQL Trace tools (transaction ST05). This implementation can be made using WHERE conditions or joins in authorization views and can change between releases.
◉ PFCG conditions can be combined within the definition of a role using literal conditions.
◉ It is advisable to specify an element of the CDS entity directly and to only use path expressions in exceptional cases.
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 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
( object,
field1,
field2,
ACTVT = '02'); }
The current user has two authorizations for the authorization object 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 transformed to a LIKE condition. The actual variant in question, however, can have a different appearance.
◉ 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 authorizations of the current user are used that contain the two activities "02" and "03", plus the authorization field country with the value "DE". Only those rows are read in which the CDS element element matches the authorization field of these authorizations.
@MappingRole: true
DEFINE ROLE demo_role {
GRANT SELECT ON entity WHERE
(element) = ASPECT pfcg_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 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( 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 object with the activity "03".
@MappingRole: true
DEFINE ROLE demo_role {
GRANT SELECT ON entity WHERE
( ) = ASPECT pfcg_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 object (with any values).
@MappingRole: true
DEFINE ROLE demo_role {
GRANT SELECT ON entity WHERE
( ) = ASPECT pfcg_auth( object ); }
Example
The following CDS role defines 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.
➥ ABAP CDS - DEFINE ROLE, Mapping of Field Values
Elements of CDS entities are associated with an authorization object in PFCG conditions. The access condition itself is generated from authorizations of the current user for the authorization object. Here, comparisons of the content of CDS elements with field values of the authorizations are created. The following points should be noted.
◉ Invalid Values
◉ Wildcard Characters
Invalid Values
The field values of authorizations are saved as text fields with length 40. For comparisons, they must be convertible to the data type of the CDS elements:
◉ The rules for lossless assignments must be followed. If this is not possible, the field value is ignored.
◉ The field value is also ignored in cases where an authorization requires a pattern comparison using a wildcard character (*), but the data type of the CDS element is not character-like.
If the CDS element has one of the data types DF16_DEC or DF34_DEC for decimal floating point numbers, the rule for lossless assignments cannot be checked before the comparison is generated and an exception might be raised.
Notes
◉ Field values that are ignored are, for example, field values that are longer than the CDS element or field values with a non-numeric content for a numeric CDS element.
◉ If field values are ignored, CDS access control may block access completely.
◉ Ignored field values are not logged, which means that they cannot be detected by the system administrator or by the user.
Wildcard Characters
If a field value contains a wildcard character (*) as its final character, it is used to create a LIKE condition in which the wildcard character * is replaced by the SQL wildcard character %.
If the field value contains the SQL wildcard characters % and _, they are given an escape symbol # implicitly (unlike in the operator LIKE for literal conditions). This means that CDS access control checks the characters % and _ in field values like regular characters.
Example
The field value "10%*" produces the condition LIKE '10#%%'.
3. ABAP CDS - DEFINE ROLE, Data Types
The operand specified on the left side of a literal condition or PFCG condition of a CDS role can only have one of the following data types (and not any predefined data type in ABAP Dictionary):
- Numeric Types
- INT1, INT2, INT4, INT8
- DEC
- DF16_DEC, DF16_RAW
- DF34_DEC, DF34_RAW
- Character-Like Types
- CHAR
- SSTRING
- Special Types
- DATS, TIMS
- NUMC
In PFCG conditions, field values of authorizations are compared with CDS elements of the permitted data types and an appropriate mapping takes place.
Note
The data types DF16_DEC and DF34_DEC display different behavior in mappings for PFCG conditions than the other data types. Any invalid values can raise exceptions and are not ignored in the access condition.
No comments:
Post a Comment