SAP Fiori Authorization: Catalogs, PFCG Roles, Services and Backend Checks

In S/4HANA private/on-premise Fiori, PFCG roles can contain catalogs and related service/authorization proposals. Spaces/pages control visible organization of apps but are not the only authorization layer. Target mappings resolve semantic object/action to an application. The UI calls OData/HTTP services whose technical authorization must be assigned/active. Once the backend receives the request, classic AUTHORITY-CHECK, CDS DCL and RAP global/instance authorization can restrict business data and actions. Depending on release/content model, catalogs are maintained through SAP-delivered/business catalog tools rather than old group-centric launchpad designs.

Use a layered trace when a user cannot see a tile, cannot launch an app, gets 403/authorization error, or sees less/more data than expected. Missing tile: check role/catalog/space-page/target mapping. Launch failure before backend call: check service/ICF and technical authorization. Backend 403/data restriction: trace the actual backend identity and business authorization. Do not solve every Fiori issue by adding broad catalogs or SAP_ALL.

PFCG role content, SU24 proposals, launchpad content manager, ICF/Gateway registration, OData service groups, backend authorization objects, CDS DCL and RAP authorization participate in different stages. SAML/OIDC/IAS handles authentication but not application authorization. Hub deployments can require roles in both frontend and backend; embedded deployments consolidate systems but not the logical layers.

A user sees the Purchase Order app tile and opens it, but list data returns 403. Because the tile exists, catalog/navigation authorization is not the primary problem. Gateway logs show the request reaches the backend under the user. STAUTHTRACE finds a failed purchasing authorization for purchasing organization. The role is corrected narrowly. Adding another Fiori catalog would have changed nothing because content access was already successful.

Fiori role-content models continue to evolve, especially between on-premise/private and Public Edition. Public Cloud uses managed business roles/catalogs rather than classic unrestricted PFCG administration. The layered principle remains: content, technical service and business data/action authorization are separate controls.

Security role teams own content/service/business roles; Fiori teams own catalog/intent configuration; Basis/Gateway own service activation; ABAP/RAP teams own backend checks; business owners approve organizational access.

PFCG role types, SU24/SU53/STAUTHTRACE, Fiori launchpad catalogs/spaces and Gateway activation topics provide deeper references. CDS DCL covers row-level authorization.

Production review: For each app, document semantic intent/app ID, catalog/business role, service/binding, backend user, main application authorization objects/DCL and test users for allowed/denied scope. During incidents capture whether the tile is visible, metadata/data HTTP status and the trace from the exact failing request. This avoids mixing navigation entitlement with business data authorization.

Additional validation: Security validation for SAP Fiori Authorization: Catalogs, PFCG Roles, Services and Backend Checks: define a small access matrix with at least one permitted user, one denied user and two different organizational scopes. Trace the actual backend identity and record the authorization object/role/content evidence for both success and denial. Confirm that removing UI navigation does not leave the underlying service/action executable and that technical users follow least privilege. Any broad emergency role used during testing must be removed before sign-off so it cannot hide missing design.

Final verification: For SAP Fiori Authorization: Catalogs, PFCG Roles, Services and Backend Checks, keep one compact evidence pack containing the configuration or artifact version, the exact productive-style input, the expected business outcome, the actual runtime result and the standard SAP monitor or log that proves it. Have a second team member reproduce the result from that evidence without relying on the original developer's memory. This is especially important after upgrades, because a technically available feature can change defaults, supported scope or operational behavior across releases even when the object name remains the same.