Authorization Control in SAP RAP

Authorization Control in SAP RAP

SAP RAP

So far in our billing document application, we controlled:

  • Data correctness using validations

  • Field behavior using feature control

  • Derived values using determinations

  • UI refresh using side effects

But there is still one critical requirement missing in any enterprise application:

Who is allowed to perform which operation?

This is where Authorization Control comes into the picture.


What is Authorization Control

Authorization control in RAP determines whether a user is allowed to execute a specific operation on a business object.

Unlike feature control, which enables or disables behavior based on data or system rules, authorization control decides based on user permissions.

So the question is no longer:

Should this operation be available?

It becomes:

Is this user allowed to perform this operation?

This check applies consistently to:

  • Fiori UI

  • OData calls

  • EML calls

  • Background execution

Authorization is part of business behavior, not UI logic.


Why Authorization Exists

In real systems:

  • Not every user can create billing documents

  • Not every user can update all document types

  • Certain operations require special roles

In classical SAP GUI, this was handled using:

  • AUTHORITY-CHECK statements

  • Authorization objects

  • SU24 proposals

  • PFCG roles

In RAP, authorization is integrated into the behavior definition and implemented in dedicated handler methods.


Types of Authorization in RAP

RAP supports two main types of authorization checks:

1. Instance Authorization

Authorization depends on the specific data of the instance.

For example:

  • Only documents of a specific currency can be updated

  • Certain billing types require additional authorization

Two different documents may behave differently for the same user.


2. Global Authorization

Authorization does not depend on instance data.

It applies globally.

For example:

  • Creation disabled after certain system time

  • Certain action allowed only during maintenance window

The rule applies equally to all instances.


Behavior Definition

Now let’s configure authorization in our Billing Document app in Billing Document Header entity.

managed implementation in class zbp_sac_i_bill_header unique;
strict ( 2 );
with draft;

define behavior for ZSAC_I_BILL_HEADER
persistent table zsac_bill_header
draft table zsac_bill_head_d
lock master total etag LocalLastChangeDat
authorization master ( instance )
etag master LocalLastChangeDat
{
  create ( precheck, features : global, authorization : global );
  update;
  delete ( features : instance );

  field ( readonly : update, mandatory : create ) BillId;

  field ( features : instance ) SalesOrg;

  action updateBillingDate result [1] $self;

  static action ( authorization : global )
      createBillingDocHeader
      parameter ZSAC_A_CREATE_BILL_PARAMS
      result [1] $self;

  factory action copyBillingDocument [1];

  ...
}

Let’s understand what we configured.

authorization master ( instance )

This activates instance-based authorization handling for this entity.

authorization : global

We defined global authorization for:

  • Create operation

  • Static action createBillingDocHeader

Now we implement both.


Instance Authorization

Our requirement:

If a document has:

  • Currency = 'ALL'

  • BillType = 'F2'

Then update should require special authorization.

If not authorized, update must fail.


Helper Method

METHODS is_update_allowed
  RETURNING VALUE(update_allowed) TYPE abap_bool.
METHOD is_update_allowed.

*  AUTHORITY-CHECK OBJECT 'Z_AO_DMO'
*    ID 'ACTVT' FIELD '02'.

  update_allowed = abap_false.

ENDMETHOD.

Here you can place your real AUTHORITY-CHECK.


get_instance_authorizations

METHOD get_instance_authorizations.

  DATA: update_requested TYPE abap_bool,
        update_granted   TYPE abap_bool.

  READ ENTITIES OF zsac_i_bill_header IN LOCAL MODE
      ENTITY zsac_i_bill_header
      FIELDS ( Currency BillType )
      WITH CORRESPONDING #( keys )
      RESULT DATA(lt_billdoc).

  CHECK lt_billdoc IS NOT INITIAL.

  update_requested =
    COND #( WHEN requested_authorizations-%update = if_abap_behv=>mk-on
            THEN abap_true
            ELSE abap_false ).

  LOOP AT lt_billdoc ASSIGNING FIELD-SYMBOL().

    IF -Currency = 'ALL'
       AND -BillType = 'F2'.

      IF update_requested = abap_true.

        update_granted = is_update_allowed( ).

        IF update_granted = abap_false.

          APPEND VALUE #(
            %tky = -%tky )
            TO failed-zsac_i_bill_header.

          APPEND VALUE #(
            %tky = -%tky
            %msg = new_message_with_text(
                     severity = if_abap_behv_message=>severity-error
                     text = 'No Authorization to update the record!!!'
                   )
          )
          TO reported-zsac_i_bill_header.

        ENDIF.

      ENDIF.

    ENDIF.

  ENDLOOP.

  result = VALUE #(
    FOR ls_billdoc IN lt_billdoc
      ( %tky = ls_billdoc-%tky
        %update =
          COND #( WHEN ls_billdoc-Currency = 'ALL'
                     AND ls_billdoc-BillType = 'F2'
                     AND update_requested = abap_true
                     AND update_granted = abap_false
                  THEN if_abap_behv=>auth-unauthorized
                  ELSE if_abap_behv=>auth-allowed )
      )
  ).

ENDMETHOD.

What happens now?

  • RAP asks: “Is update requested?”

  • If yes, it checks instance data

  • If rule matches and user not authorized:

    • Update fails

    • Error message returned

    • UI blocks the operation

Instance Authorization Control

Each instance can behave differently.

That is instance authorization.


Global Authorization

Now let’s implement a rule independent of document data.

Requirement: Create not allowed after 08:00 AM.


get_global_authorizations

METHOD get_global_authorizations.

  DATA(create_requested) =
    COND #( WHEN requested_authorizations-%create = if_abap_behv=>mk-on
            THEN abap_true
            ELSE abap_false ).

  IF create_requested = abap_true.

    IF cl_abap_context_info=>get_system_time( ) > '080000'.

      result-%create = if_abap_behv=>auth-unauthorized.

      APPEND VALUE #(
        %global = if_abap_behv=>mk-on
        %msg = new_message_with_text(
                 severity = if_abap_behv_message=>severity-error
                 text = 'Create not allowed after 8AM.'
               )
      )
      TO reported-zsac_i_bill_header.

    ENDIF.

  ENDIF.

ENDMETHOD.

Here:

  • No document data is checked

  • Rule applies globally

  • If unauthorized:

    • Create fails

    • Message returned

Global Authorization Control

Same rule applies for static action if configured with authorization : global.


Final Understanding

Instance authorization depends on record data.
Global authorization depends on system or user-level logic.

Both are implemented in dedicated handler methods and defined declaratively in behavior definition.

Once defined, RAP ensures:

  • UI respects the rule

  • API respects the rule

  • EML respects the rule

No UI coding required.

Thanks for reading.