BTP Security Fundamentals: Identity, Trust, and the Authorization Model

Explanation

SAP BTP is a multi-tenant, service-consumption platform where every subaccount, application, and integration flow needs a consistent way to answer two questions: who is this user or system, and what are they allowed to do. Unlike a classic ABAP system where authentication and authorization are handled inside a single system boundary, BTP separates identity management from application authorization, and it does so deliberately because BTP landscapes typically span multiple subaccounts, multiple runtimes (Cloud Foundry, Kyma), and multiple SaaS/PaaS services that must all trust a common identity source. At the center of BTP identity is the Identity Authentication service (IAS), which acts as the default or custom identity provider for a subaccount. Every subaccount is bound to a trust configuration pointing to an identity provider. Out of the box, BTP provides a default identity provider for platform users (administrators managing the subaccount via cockpit), but for business users consuming applications (Fiori apps, custom UI5 apps, integration flows requiring OAuth), organizations typically configure a corporate identity provider, often via IAS acting as a proxy/broker to an on-premise or cloud corporate directory (for example, connecting IAS to a corporate Active Directory Federation Service or another SAML/OIDC provider). This creates a trust chain: corporate IdP trusts nothing by itself, but IAS trusts the corporate IdP, and the BTP subaccount trusts IAS. Trust is established using standard federation protocols, SAML 2.0 or OpenID Connect, where metadata (certificates, entity IDs, endpoints) is exchanged between the two parties so that assertions/tokens can be cryptographically validated. Once a user is authenticated, BTP does not automatically know what they can do. Authorization on BTP is modeled through roles, role templates, and role collections. A role template is defined by an application (often shipped by SAP inside a multitarget application descriptor or defined by developers using an authorization and trust configuration file), describing granular permissions like 'Display Monitoring Dashboard' or 'Manage Integration Flows'. From role templates, actual roles are created within a specific scope (a specific application instance). Administrators then group one or more roles into role collections, which are the actual objects assigned to users or groups. This indirection exists so that authorization can be managed centrally and consistently even as applications are redeployed or scaled, and so that business logic ('this person is a Finance Approver') can map to multiple underlying technical roles across different apps. Beneath roles and role collections sit scopes, which are the actual technical permissions embedded in OAuth tokens. When a user authenticates and a token is issued (a JWT), that token carries the scopes derived from the role collections assigned to the user. Downstream services and integration flows validate these scopes before allowing an action, rather than re-checking a central authorization table on every call. This is fundamentally different from an ABAP authorization check against authorization objects; BTP's model is token-based and stateless, meaning once a token is issued, the receiving service does not call back to the identity provider for every request, it simply validates the token's signature and expiration and inspects the embedded scopes/claims. For someone new to BTP, the most important mental model is this: authentication answers 'who are you' and is resolved through trust with an identity provider (IAS or a custom IdP), while authorization answers 'what can you do' and is resolved through role collections mapped to scopes embedded in tokens. Getting either piece wrong — for example, trusting the wrong identity provider, or assigning an overly broad role collection — creates either an access-denied production incident or a security exposure, both of which are common in early BTP projects when teams underestimate how differently this model works compared to on-premise SAP authorization.

Code example

# Example: structure of an xs-security.json file used to define# role templates, scopes, and role collections for a BTP application# (used with the XSUAA service to generate authorization artifacts) {  "xsappname": "invoice-approval-app",  "tenant-mode": "dedicated",  "scopes": [    {      "name": "$XSAPPNAME.Approve",      "description": "Approve invoices above threshold"    },    {      "name": "$XSAPPNAME.View",      "description": "View invoice list"    }  ],  "role-templates": [    {      "name": "InvoiceApprover",      "description": "Can approve invoices",      "scope-references": ["$XSAPPNAME.Approve", "$XSAPPNAME.View"]    },    {      "name": "InvoiceViewer",      "description": "Can only view invoices",      "scope-references": ["$XSAPPNAME.View"]    }  ]} // After deployment, an administrator creates a Role Collection// e.g. "Finance-Approvers" and adds the InvoiceApprover role to it,// then assigns the role collection to specific users or groups// in the BTP cockpit under Security > Role Collections.

Real project scenario

A retail company rolling out a custom invoice-approval application on BTP found that finance managers in one region could not approve invoices even though they were listed as authorized in the business process documentation. Investigation showed that while the users existed correctly in the corporate identity provider federated through IAS, the BTP administrator had assigned them to a role collection called 'Invoice-Viewer' instead of 'Invoice-Approver' because the two role collections had similarly worded descriptions in the cockpit. This highlighted the need for clear naming conventions and periodic access reviews, since the underlying trust and authentication were working correctly the entire time — the issue was purely in role collection assignment, which is easy to get wrong at scale across dozens of subaccounts.

Common mistakes

• Assuming BTP authorization works like ABAP authorization objects, leading to confusion about why access changes take effect immediately in the token rather than requiring a system-wide profile regeneration • Assigning role collections directly based on scope names instead of using descriptive, business-aligned role collection names, causing administrative confusion later • Not distinguishing between platform users (cockpit administrators, authenticated via the default identity provider) and business users (application end users, authenticated via a custom IAS tenant), leading to incorrect trust configuration • Forgetting that scopes are embedded in the token at login time, so a role collection change does not take effect until the user re-authenticates or the token is refreshed • Leaving default or overly broad role templates (e.g., granting full admin scope) assigned to a large role collection used across many unrelated applications

Best practices

• Use business-oriented, unambiguous names for role collections that map clearly to job functions rather than technical scope names • Federate business user authentication through a dedicated custom IAS tenant rather than relying on the platform's default identity provider for application users • Periodically audit role collection assignments against actual business need, especially in subaccounts with many integration and custom UI5 applications • Document the trust chain (corporate IdP to IAS to subaccount) so support teams can quickly diagnose authentication failures • Educate business administrators that scope/token changes require re-login to take effect, to avoid false troubleshooting leads

Interview angle

Interviewers commonly probe whether a candidate understands the separation between authentication (identity provider trust) and authorization (role collections/scopes), and whether they can explain why BTP uses a token-based, stateless model instead of session-based authorization checks. Be ready to explain the relationship between role templates, roles, role collections, and scopes, and to describe a real scenario where you diagnosed an access issue by checking role collection assignment versus trust configuration.