BTP & Integrationintermediate

BTP Security Part 2: Trust, OAuth Clients and Role Collections Across Subaccounts

Key takeaway

Configure security consistently in every subaccount: trust to Identity Authentication, xs-security. json with scopes, role templates and role collections delivered by the app, XSUAA service instances as OAuth clients, attribute-based restrictions, and standardized role collection design across dev/test/prod.

Explanation

📌 KEY POINTS
✅ xs-security.json defines scopes, attributes, role templates and (optionally) role collections for the app.
✅ Creating the XSUAA instance registers the app as an OAuth client with those authorizations.
✅ Trust to Identity Authentication (OIDC) is set per subaccount.
✅ Role collections with the same names across environments make group mapping repeatable.
⚠️ Wildcard scopes or one "Admin" role for everything defeat least privilege.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 1 introduced the model. Now configuration.

━━━━━━━━━━━━━━━━━━━━
▶ 1. XS-SECURITY.JSON

xsappname, scopes, attributes, role templates.

━━━━━━━━━━━━━━━━━━━━
▶ 2. XSUAA INSTANCE

Plan application; bound to app/approuter.

━━━━━━━━━━━━━━━━━━━━
▶ 3. TRUST

OIDC trust to IAS; user groups in token.

━━━━━━━━━━━━━━━━━━━━
▶ 4. ROLE COLLECTIONS

Naming; same across environments.

━━━━━━━━━━━━━━━━━━━━
▶ 5. ATTRIBUTES

Restrict data (e.g. by country) via attributes.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Write xs-security.json with two scopes.
Create/update the XSUAA instance.
Map collections to groups in each subaccount.

✅ CHECKPOINT: viewer and admin users see different functions.

Code example

ABAP Code

===== xs-security.json ====={  "xsappname": "orders",  "tenant-mode": "dedicated",  "scopes": [ { "name": "$XSAPPNAME.Display" }, { "name": "$XSAPPNAME.Admin" } ],  "attributes": [ { "name": "Country", "valueType": "string" } ],  "role-templates": [    { "name": "Viewer", "scope-references": ["$XSAPPNAME.Display"], "attribute-references": ["Country"] },    { "name": "Administrator", "scope-references": ["$XSAPPNAME.Display", "$XSAPPNAME.Admin"] } ],  "role-collections": [ { "name": "Orders_Viewer", "role-template-references": ["$XSAPPNAME.Viewer"] } ]}cf create-service xsuaa application orders-auth -c xs-security.json  (or via MTA resource)

Real project scenario

A company rolling out BTP apps defined role collections manually in each subaccount; names differed and mappings broke on transport. Delivering collections via xs-security.json standardized them.

Common mistakes

Manual per-env collections.
Broad admin roles.
Renaming scopes.
No attributes where needed.
Missing trust setup.

Best practices

Collections in xs-security.json.
Least privilege.
Stable scope names.
Use attributes.
Standard trust setup.

Interview angle

Questions: "What's in xs-security.json?", "What does the XSUAA instance do?", "How do you keep roles consistent?"
Strong answer: file content, OAuth client, trust, collections, attributes.

Practice this lesson

Quick check

1. In an XSUAA-secured application's xs-security.json, what is the main functional difference between a scope and an attribute?

2. What is primarily achieved by configuring a trust relationship between a BTP subaccount and the SAP Identity Authentication service (IAS)?

3. Role collections have different names in each environment, so group mappings break after transports. What fixes this?

Interview questions

1. How would you apply BTP Security for Integration and Application Architecture in a real SAP project? Walk through the design or implementation approach.

Answer it in your own words first, then compare.

2. What are the most important design decisions, trade-offs, and best practices in BTP Security for Integration and Application Architecture?