Designing Authentication, Authorization and Identity Federation Across the Landscape
Explains how to design authentication, authorization and identity federation decisions across ECC, S/4HANA and BTP, including the trade-offs between centralized identity providers, role design strategies and cross-system trust.
Explanation
Once the overall scope of security architecture is understood, the next design layer is authentication and authorization, and how identity is federated across a hybrid landscape. Authentication answers who is connecting; authorization answers what they may do once connected. In SAP landscapes these two concerns are handled by different mechanisms depending on the deployment model, and an architect must design a coherent identity flow that spans them. In ECC and S/4HANA on-premise or private cloud, authentication traditionally relies on the application server's own user store, or is federated to a corporate directory via standards such as SAML or through a trusted single sign-on gateway. Authorization within ABAP systems is governed by the authorization concept: authorization objects, profiles and roles that control access to transactions, reports and data at a granular level, including organizational-level restrictions such as company code or plant. This model is mature and well understood, but it is scoped to the ABAP stack itself. BTP and SAP cloud services introduce a different identity model, typically built around an identity provider concept where a subscriber account trusts either SAP's default identity provider or a customer's own corporate identity provider through federation protocols. Authorization in BTP applications is usually expressed through role collections mapped to scopes defined in the application, a different paradigm from ABAP authorization objects. When a business process spans an S/4HANA system and a BTP extension, the architect must decide how identity flows between them: whether the end user's identity is propagated end to end (principal propagation), whether a trusted technical communication user is used for system-to-system calls, or a mix depending on the use case. A central architectural decision is whether to centralize identity through a single corporate identity provider connected to both on-premise and cloud systems, or to allow each system to manage authentication independently. Centralization reduces credential sprawl, simplifies joiner-mover-leaver processes and supports consistent multi-factor authentication policies, but requires careful availability planning since an outage in the identity provider can lock users out of everything simultaneously; failover and cached session considerations must be designed explicitly, not assumed. For authorization, a further decision is role design philosophy: task-based roles aligned tightly to job functions reduce over-provisioning but require more roles to maintain, while broader composite roles are easier to administer but increase the risk of unintended access combinations and segregation-of-duties conflicts, especially in finance and procurement processes. In S/4HANA public cloud, standard business roles are provided as templates with a more restricted customization model than private cloud or on-premise, so the architect's authorization design work shifts toward composing and extending standard roles rather than building entirely custom authorization objects, and the extent of that flexibility should be verified against the specific cloud edition rather than assumed uniform across offerings. Cross-system trust for integrations deserves separate treatment from human user authentication. Technical communication arrangements, certificate-based trust and OAuth client credentials flows are common for system-to-system calls, and each carries different rotation, monitoring and revocation implications. Architects should design a clear policy for credential lifecycle: rotation frequency, ownership, and what happens operationally when a certificate or secret needs emergency revocation, because a compromised integration credential can expose the same data as a compromised human account, often with less monitoring attention. Finally, segregation of duties analysis should be performed at the process level across systems, not just within a single ABAP system, since a user might hold conflicting access split across an S/4HANA role and a BTP scope that together create an unauthorized combination invisible to either system's own authorization report.
Real project scenario
A retail company connected its S/4HANA private cloud system to a BTP-based returns management extension using principal propagation so that store associates' identities carried through to backend postings. During testing, the team discovered that a subset of users had elevated BTP role collections left over from a pilot phase, which combined with their existing S/4HANA posting authorizations created a segregation-of-duties conflict allowing the same user to both approve and post high-value returns; the issue was only found because the security architect insisted on a cross-system SoD review rather than reviewing each system's roles independently.
Common mistakes
• Designing ABAP authorization roles and BTP role collections in isolation without a cross-system segregation-of-duties review • Assuming principal propagation is available or configured by default between on-premise and BTP applications without verifying the specific scenario • Using long-lived shared certificates or secrets for system-to-system trust without a defined rotation and revocation process • Centralizing identity without planning for identity provider outage or failover impact on business continuity • Assuming public cloud S/4HANA authorization customization flexibility matches private cloud or on-premise without checking the specific edition
Best practices
• Map authentication and authorization mechanisms explicitly for every system and integration in the landscape rather than assuming consistency • Decide deliberately between end-to-end identity propagation and technical service accounts for each integration, documenting the rationale • Perform segregation-of-duties analysis at the cross-system process level, not per individual system • Define credential and certificate rotation, ownership and emergency revocation procedures before go-live • Verify authorization customization flexibility against the specific SAP deployment edition rather than assuming uniform behavior across on-premise, private cloud and public cloud
Interview angle
Be prepared to explain the difference between ABAP authorization objects and BTP role collections, describe how you would design identity propagation across a hybrid scenario, and discuss how you would detect segregation-of-duties conflicts that span multiple systems rather than living inside just one.