Production Architectural Blueprint

SAP ABAP Cloud IAM & Business Catalog Architecture Guide

Security Domain: ABAP Cloud Identity & Access Management (IAM) Standard: S/4HANA 2022/2023/2025 & S/4HANA Cloud Clean Core Tier: Tier-1 On-Stack

1. The Paradigm Shift: From PFCG to ABAP Cloud IAM

In classic ABAP systems, authorization management was heavily decoupled from the development lifecycle. Developers built reports, function modules, and transactions, while security administrators used transaction PFCG to manually insert authorization objects, field values, and menu entries.

In ABAP Cloud (Language Version 5), this workflow is eliminated. To maintain upgrade stability and prevent authorization discrepancies during quarterly or annual cloud upgrades, SAP introduced Clean Core IAM:

• Every service binding is consumed via an IAM App Descriptor (ADT object type IAPP).
• IAM Apps bundle authorization object proposals (SU22 defaults) directly with the code artifact.
• IAM Apps are assigned to Business Catalogs (ADT object type BCAT).
• Security administrators assign Business Catalogs to Business Roles in Fiori Launchpad without manual object manipulation.

2. The Clean Core IAM Object Hierarchy

Layer	Artifact Type	Managed In	Clean Core Responsibility
1. Service	RAP Service Binding (OData V4)	ADT (Eclipse)	Defines protocol and exposed business entities
2. App Descriptor	IAM App (IAPP)	ADT (Eclipse)	Binds service to authorization defaults (SU22)
3. Catalog	Business Catalog (BCAT)	ADT (Eclipse)	Logical grouping of apps for a business persona
4. Role	Business Role (BR_...)	Fiori Launchpad (App Maintain Business Roles)	Assigned to end users with restriction field values

3. Dual Protection: CDS DCL vs RAP Behavior Authorizations

A common architectural pitfall in ABAP Cloud is relying on only one layer of access control. Clean Core enforces dual protection:

1. Read Access Protection (CDS Access Control - DCL): Evaluated automatically by the SAP HANA database engine on every SQL / EML query. If the user lacks authorization for the row, the database excludes the record transparently.
2. Modification Protection (RAP Behavior Implementation): Evaluated by the RAP runtime during draft actions, CRUD operations, and custom actions. Implemented in the behavior pool via get_global_authorizations and get_instance_authorizations.

4. Implementing RAP Authorization Methods

CLASS lhc_salesorder DEFINITION INHERITING FROM cl_abap_behavior_handler.
  PRIVATE SECTION.
    METHODS get_global_authorizations FOR GLOBAL AUTHORIZATION
      IMPORTING REQUEST requested_authorizations FOR SalesOrder RESULT result.

    METHODS get_instance_authorizations FOR INSTANCE AUTHORIZATION
      IMPORTING keys REQUEST requested_authorizations FOR SalesOrder RESULT result.
ENDCLASS.

CLASS lhc_salesorder IMPLEMENTATION.

  METHOD get_global_authorizations.
    IF requested_authorizations-%create = if_abap_behv=>mk-on.
      AUTHORITY-CHECK OBJECT 'V_VBAK_VKO'
        ID 'ACTVT' FIELD '01'.
      IF sy-subrc <> 0.
        result-%create = if_abap_behv=>auth-unauthorized.
      ELSE.
        result-%create = if_abap_behv=>auth-allowed.
      ENDIF.
    ENDIF.
  ENDMETHOD.

  METHOD get_instance_authorizations.
    READ ENTITIES OF zr_salesorder IN LOCAL MODE
      ENTITY SalesOrder
      FIELDS ( SalesOrganization )
      WITH CORRESPONDING #( keys )
      RESULT DATA(lt_orders).

    LOOP AT lt_orders ASSIGNING FIELD-SYMBOL(<order>).
      IF requested_authorizations-%update = if_abap_behv=>mk-on.
        AUTHORITY-CHECK OBJECT 'V_VBAK_VKO'
          ID 'ACTVT' FIELD '02'
          ID 'VKORG' FIELD <order>-SalesOrganization.
        IF sy-subrc <> 0.
          APPEND VALUE #( %tky = <order>-%tky %update = if_abap_behv=>auth-unauthorized ) TO result.
        ELSE.
          APPEND VALUE #( %tky = <order>-%tky %update = if_abap_behv=>auth-allowed ) TO result.
        ENDIF.
      ENDIF.
    ENDLOOP.
  ENDMETHOD.
ENDCLASS.

5. Governance & Anti-Patterns to Avoid

• Anti-Pattern 1: Hardcoding Usernames: Never check sy-uname directly in application code. Always use AUTHORITY-CHECK or CDS DCL.
• Anti-Pattern 2: Unreleased Authorization Objects: Never consume deprecated or unreleased authorization objects in Tier-1 code. Verify release contract C1 in ADT.
• Anti-Pattern 3: Skipping IAM App Descriptors: Never expose an OData service without an IAM App. An unmapped service defaults to unrestricted or completely inaccessible depending on the cloud edition.