1. Overview
Identity and Access Management (IAM) in SAP S/4HANA Cloud Public Edition provides the foundational security layer that controls user access to business applications and backend services. Traditionally, IAM apps were grouped into business catalogs, with authorization default values aggregated strictly at the catalog level. These business catalogs served as the essential building blocks for constructing business roles. The traditional authorization flow works as follows:
Business Role → Business Catalog → Fiori→ Authorization Defaults / Services
While this catalog-centric model provided a straightforward way to bundle related apps, it operated on an “all-or-nothing” principle. Assigning a catalog granted access to every application within it.
To solve these limitations, SAP evolved the IAM architecture from rigid catalog bundles to modular application entities.
2. What Is “App as Entity”?
Starting with Release 2502, SAP introduced “App Authorization Variants” for SAP S/4HANA Cloud Public Edition. An App Authorization Variant acts as a standalone wrapper around an application’s authorization requirements, decoupling it from the catalog to make the individual IAM App -rather than the catalog- the smallest assignable unit of authorization.
With Release 2608, this capability expands into the broader “App as Entity” framework, enabling administrators to directly assign, toggle active/inactive, and manage application access with fine-grained precision when building Business Roles.
The diagram below illustrates this shift from broad catalog bundling to standalone, app-level role construction.
2.1 The Challenges of the Catalog-Only Approach
While catalogs provide great pre-bundled workplaces, relying solely on them introduced friction:
- Inability to create business roles for a specific subset of apps without custom catalog creation.
- High change-management effort when catalogs required splitting due to evolving requirements.
- Automatic exposure of newly added apps to end-users upon upgrades, along with their underlying authorizations.
By shifting to “App as Entity,” administrators can now assemble roles based on exact user tasks without rigid constraints, enabling the direct launch of all application types via assigned transaction codes in S/4HANA Public Edition and SAP BTP, ABAP environment.
2.2 Practical Scenarios:
- User Management: Grant user access to the Business User app without exposing access to the Business Roles app.
- Procurement: Assign access to a specific Purchase Order app without granting permissions to all applications inside the broader Procurement catalog.
3. How App Assignment Works
“App as Entity” does not replace Business Catalogs. Instead, Business Catalogs and direct app selection run side-by-side in parallel.
When configuring a role in the Maintain Business Roles Fiori app (F1492), administrators now have two assignment mechanisms:
|
Assignment Type |
How It Works |
Best Used For |
|
Assigned via Business Catalog |
The Business Catalog is assigned to the Business Role. IAM Apps within that catalog can be selectively activated or deactivated and are part of the resulting role accordingly. |
Standard role setup where a user needs the complete suite of applications in a functional area. |
|
Direct Assignment |
An App Authorization Variant /IAM App is selected directly for a Business Role without requiring the overarching Business Catalog to be assigned. |
Granular role setup where a user needs only 1 or 2 specific applications from a larger domain. |
3.1 In-App Granular Control
Beyond assigning broad Business Catalogs, administrators can now manage application access with pinpoint accuracy. The Maintain Business Roles app (F1492) allows security leads to directly add, remove, toggle, or inspect individual IAM Apps to match exact user job responsibilities.
3.1.1 Practical Example: Direct App Selection in Action
To see how “App as Entity” works in practice, consider configuring the “Internal Sales Representative” role as an example inside the Maintain Business Roles app.
As shown in the screenshot above, administrators are no longer limited to managing entire catalogs. Instead, the dedicated IAM Apps tab allows granular control over individual applications:
- Direct App Authorization Variants: Specific apps, such as Display Business Partner, Display Customer (Centrally), or Supplier are assigned directly as “App Authorization Variants” with their linked transaction objects.
- Selection & Activation Control: Checkboxes alongside each IAM App let administrators select specific items to Add, Remove, Activate, or Deactivate permissions without affecting the rest of the business domain.
- Catalog-Free Flexibility: Notice that this role has 0 Business Catalogs assigned yet contains 27 IAM Apps assigned directly. This proves that roles can now be built using standalone app entities tailored to exact job tasks.
3.1.2 Toggling Apps ON/OFF
In addition to Direct Assignment, administrators can open an assigned Business Catalog inside the Maintain Business Roles app (F1492) and toggle individual IAM Apps ON or OFF.
Important Note on Toggling:
Toggling an app OFF inside F1492 suppresses its underlying authorization defaults for that specific Business Role instance only. It does NOT alter or remove the app definition from the underlying Business Catalog in ABAP Development Tools (ADT), preserving the central catalog definition for other roles.
4. Application Scope: SAP Standard vs. Customer-Developed Apps
The “App as Entity” model applies to both SAP-delivered content and custom-built extensions:
4.1 SAP Standard Applications
As introduced in Section 2, SAP delivers standard content pre-configured as individual App Authorization Variants (SIA6 objects).
For standard applications, this eliminates the need to assign full standard catalogs. Security administrators can directly select individual SAP standard apps when building Business Roles, ensuring users receive access only to the exact standard functionality required for their tasks while avoiding the overhead of creating custom catalogs in ADT.
4.2 Customer-Developed Applications (Developer Extensibility)
Custom applications built via ABAP Cloud / ADT using the ABAP RESTful Application Programming Model (RAP) are defined as External IAM Apps (SIA6 objects).
- The Migration Requirement: To enable custom apps for individual selection in Business Roles, existing customer IAM Apps (SIA6) and their corresponding Business Catalogs (GBAK objects) must undergo a one-time migration using the built-in migration wizard in ABAP Development Tools (ADT).
- The Outcome: Once migrated, customer-developed apps can participate in direct assignments and individual toggling just like SAP standard applications.
5 On-Premise (PFCG) to Cloud IAM Migration Realities
A common question during cloud transformation projects is whether existing On-Premise PFCG roles can be migrated directly into S/4HANA Cloud Public Edition.
5.1 Key Architectural Differences
|
Feature |
On-Premise (PFCG) |
S/4HANA Cloud Public Edition (IAM) |
|
Primary Building Block |
Transactions (TCODES), Auth Objects, & Profiles |
IAM Apps (SIA6), Business Catalogs, & Business Roles |
|
Menu Maintenance |
Direct TCode insertion in PFCG Menu tab |
IAM Apps bundled in Business Catalogs via ADT |
|
Authorization Abstraction |
Direct maintenance of Auth Objects & Fields in SU24 |
Managed via IAM Apps, Business Catalogs, and Restriction Types |
5.2 Migration Reality
Because On-Premise PFCG roles lack the underlying IAM App metadata layer (SIA6 objects), there is no automated 1-to-1 role import tool.
- Best Practice: Customers migrating from On-Premise to S/4HANA Cloud Public Edition must construct their business roles using standard SAP reference catalogs or custom IAM Apps created in ADT.
6 Key Takeaways
- Greater Flexibility: Security teams can build roles aligned with real user job descriptions using Direct Assignment or Catalog-based Assignment.
- Reduced Customization: Eliminates the need to build redundant custom catalogs in ADT just to exclude a single application.
- Segregation of Duties (SoD) Preserved: Business Catalogs remain the standard for grouping apps and preserving regularly audited SoD compliance. App as Entity adds fine-grained flexibility on top of this foundation.
- Migration Needed for Custom Content: Existing customer-developed IAM Apps (SIA6) and catalogs (GBAK) must be migrated via the ADT wizard to participate in direct assignment.
7 More to read:
To dive deeper, explore the following official resources and reference guides:
- Identity and Access Management (IAM)
- Maintain Business Roles (Fiori App F1492)
- Creating an IAM App for the Business Service
- IAM Information System App (F2450) Usage Guide
#SAPCHANNEL