Designing Authorization Concepts and Segregation of Duties for Hybrid Clean-Core Landscapes

Explanation

Authorization architecture in a hybrid SAP landscape is significantly more complex than in a single ECC system because authorization models differ structurally across platforms: classic PFCG roles with authorization objects on ABAP systems, business catalogs and business roles in S/4HANA (especially Fiori-based access), and scopes or role collections in BTP. An architect's job is to design a coherent authorization concept that maps business job functions consistently across these models without duplicating logic or creating conflicting access paths. The starting point is a business role model: define job functions and their required capabilities independent of technology, then map each function to the appropriate technical constructs per system. In S/4HANA, business catalogs bundle Fiori app authorizations and are combined into business roles, which are then assigned to PFCG-style composite roles or directly to users depending on the release and configuration approach. In BTP, role collections aggregate roles defined in the security descriptor of individual applications, and are assigned to users or groups, often via the same IAS/IPS identity layer used for authentication. Segregation of duties (SoD) is the second major pillar. Classic ECC/S4 SoD analysis (e.g., using GRC Access Control or an equivalent access risk analysis tool) evaluates authorization objects and transaction combinations that create conflicting capabilities, such as the ability to both create and approve a vendor. In a hybrid landscape, SoD analysis must extend to BTP-based extensions and custom Fiori apps: a poorly scoped custom app that calls a sensitive OData service can silently reintroduce an SoD conflict that the core system's role design intentionally separated. This is a common blind spot when clean-core extensions are built quickly without security architecture review. Under clean-core principles, custom authorization objects should be minimized; instead, extensions should reuse standard authorization checks exposed by released APIs and business catalogs. When a custom authorization object is unavoidable (for example, to protect a custom Fiori app that isn't covered by standard catalogs), it should be designed with the same granularity discipline as standard SAP objects: avoid overly broad wildcard authorizations, and document the object's purpose so it survives system upgrades without becoming orphaned dead code. Cross-system SoD is the hardest architectural problem: a user might have limited access in S/4HANA but combined with BTP application access could achieve an SoD-conflicting outcome that no single system's authorization concept detects in isolation. Addressing this requires either an SoD tool capable of cross-system risk aggregation, or a governance process that manually reviews role combinations for users who span multiple systems, particularly integration/service accounts. Deployment differences matter significantly here: S/4HANA public cloud constrains custom authorization object creation and requires extensions built within the SAP BTP extensibility model, meaning most fine-grained authorization design happens through BTP role design rather than ABAP authorization objects. Private cloud and on-premise editions retain the ability to define custom authorization objects directly in the ABAP stack, offering more flexibility but also more risk of scope creep and technical debt if not governed. A robust rollback and change-governance process is essential: role changes should go through a transport-based (or equivalent content package) promotion path with SoD impact analysis before go-live, and emergency access (firefighter) processes should be logged and time-boxed with post-review, rather than granting standing elevated access.

Code example

* Illustrative PFCG-style composite role structure (conceptual)* Business role: "Accounts Payable Clerk"*   -> Composite role: Z_AP_CLERK*     -> Single role: Z_AP_INVOICE_ENTRY (authorization objects for invoice posting)*     -> Single role: Z_AP_VENDOR_DISPLAY (display-only vendor master access)* Business role: "Accounts Payable Approver"*   -> Composite role: Z_AP_APPROVER*     -> Single role: Z_AP_INVOICE_APPROVE (release/approve authorization)*     -> Single role: Z_AP_VENDOR_DISPLAY (shared display role)* SoD rule (conceptual, evaluated by access risk analysis tool):*   Conflict = Z_AP_INVOICE_ENTRY assigned to same user as Z_AP_INVOICE_APPROVE* BTP role collection mapping:*   Role Collection "AP_Extension_User" -> Role "InvoiceExtensionViewer" (custom Fiori app)*   Reviewed against SoD matrix to ensure no combined conflict with S/4HANA approver role

Real project scenario

An architecture team building a custom BTP invoice-exception app discovered during a security review that the app's service consumed an OData API allowing invoice status changes, which combined with an existing S/4HANA approver role created an unreviewed SoD conflict for a subset of users who had both accesses. The team redesigned the BTP role collection to remove the status-change scope for that user group and added the new role combination to the organization's cross-system SoD matrix, along with a recurring quarterly review of BTP role collections alongside S/4HANA role changes.

Common mistakes

• Designing S/4HANA and BTP authorizations in isolation without a shared business role model, causing inconsistent access mapping • Ignoring SoD impact of custom Fiori/BTP apps that call sensitive backend APIs • Creating custom authorization objects with overly broad wildcard values for convenience during development • Granting standing firefighter/emergency access instead of time-boxed, logged elevated access • Assuming SoD analysis tools automatically cover BTP scopes without explicit configuration or manual review • Failing to include role and authorization changes in a formal transport/change governance and testing process

Best practices

• Build a technology-independent business role model first, then map to PFCG roles, business catalogs, and BTP role collections • Extend SoD risk analysis explicitly to cover custom BTP apps and their backend API scopes • Minimize custom authorization objects; reuse standard catalogs and released API authorization checks under clean-core principles • Require SoD impact review as a gate in the role/transport change governance process • Use time-boxed, logged firefighter access instead of standing elevated privileges • Periodically review cross-system role combinations for integration and service accounts, not just human users

Interview angle

Expect questions on how you would design a business role model that spans ABAP composite roles, S/4HANA business catalogs, and BTP role collections, how you detect cross-system SoD conflicts introduced by custom extensions, and how clean-core constraints in public cloud change where authorization logic can live. Strong answers reference governance processes (SoD tooling, transport-based promotion, firefighter logging) rather than only technical configuration steps.