Description

This syntax variant is available for managed and unmanaged RAP BOs only.

In the header part of a behavior definition of a managed or unmanaged RAP BO, it is possible to specify with privileged mode disabling ContextName. The effect is that the authorization context for disable ContextName is automatically disabled when a RAP BO consumer uses privileged access to the RAP BO in question. ContextName must be an authorization context for disable defined in the same BDEF. Not more than one authorization context can be specified.

Example:

with privileged mode disabling DemoContextBdl

in the BDEF has the effect that the EML statement

read entity privileged DemoContextBdl
   all fields with value #( ( name = field1 ) )
   result data(result)
   failed data(failed).

behaved as if

authority-check disable begin context DemoContextBdl~privileged context.
   read entity privileged DemoContextBdl
   all fields with value #( (name = field1 ) )
   result data(result)
   failed data(failed).
authority-check disable end.

had been written.

So with the syntax with privileged mode disabling, the RAP framework leaves out calls to authorization objects. No implementation in the ABAP behavior pool is required.

There are other kinds of authority checks, such as CDS access control. If a business object is protected from unauthorized access using any other method than authorization objects, the BDEF can define an empty authorization context that is referred to in ContextName.

Example:

BDEF header: with privileged mode disabling EmptyContext

BDEF body: define authorization context EmptyContext { }

In the case of empty authorization contexts, privileged EML calls are handled as follows:

• In a managed RAP BO, the RAP framework automatically and implicitly checks for other authorizations, such as CDS access control.
• In an unmanaged RAP BO, rules for the handling of a privileged access can be defined in the respective RAP handler methods in the ABAP behavior pool.

Description

This syntax variant is available for projection BDEFs only. It enables BDEF privileged mode for a projection BDEF. As a prerequisite, the underlying projected BDEF must define privileged mode. The syntax for enabling privileged mode in a projection BDEF is as follows:

with privileged mode disabling base context
  [and ContextName]

base context refers to the authorization context for disable that is specified in the projected BDEF. It is mandatory to reuse the authorization context from the projected BDEF.

If the projected BDEF specifies an empty authorization context, this can also be reused by the projection BDEF.

With the optional addition and ContextName, it is possible to specify an additional authorization context for disable in the projection BDEF. ContextName must be an authorization context for disable defined in the same projection BDEF. For all privileged operations on the projection BDEF, both the authorization context of the projected BDEF and the context of the projection BDEF are disabled.

Example

The following example shows a projection BDEF based on the projected BDEF DEMO_RAP_AUTH_CONTEXT. It enables privileged mode, reuses the authorization context for disable from the projected BDEF and adds one further authorization context to the projection layer.

Note: This example is intentionally kept short and simple and serves demonstration purposes only. The ABAP behavior pool is not implemented here. In a real-life scenario, AUTHOBJ1 would be implemented in the ABAP behavior pool.

projection implementation in class BP_DEMO_RAP_AUTH_CONTEXT_PROJ unique;
strict(2);
with privileged mode disabling base context and ac_3;

define authorization context ac_3
{
'AUTHOBJ1' ;
}

define behavior for DEMO_RAP_AUTH_CONTEXT_PROJ
{
  use create;
  use update;
  use delete;
}

define own authorization context by privileged mode;

Description

This syntax variant is available for interface BDEFs only. It enables BDEF privileged mode for an interface BDEF, so that access with EML can take place in privileged mode using the addition PRIVILEGED. Since interface BDEFs cannot define any access restrictions or authorization contexts themselves, it is a prerequisite that the underlying projected BDEF defines privileged mode. A privileged access is then delegated to the implementation of the underlying base RAP BO. The syntax for enabling privileged mode in an interface BDEF is as follows:

with privileged mode;