Configuring Trust, OAuth Clients, and Role Collections Across Subaccounts and Runtimes

Explanation

Once the conceptual model of identity, trust, and authorization is understood, the next challenge in a real BTP landscape is configuring it correctly and consistently across multiple subaccounts and runtimes, because most enterprise landscapes are not a single subaccount but a hierarchy: global account, multiple subaccounts for dev/test/prod, and often a mix of Cloud Foundry organizations/spaces and Kyma clusters within those subaccounts. Each subaccount can have its own trust configuration, meaning the identity provider used for login is not automatically inherited unless deliberately configured that way, and each runtime environment (Cloud Foundry, Kyma) consumes identity and authorization slightly differently at the technical binding level even though the underlying concepts (XSUAA-issued tokens, IAS trust) are shared. Configuring trust begins in the subaccount's Security settings, where an administrator adds a Trust Configuration pointing to an identity provider. For a custom IAS tenant, this involves downloading the subaccount's SAML/OIDC metadata and uploading it into IAS (or configuring it via IAS admin console), and conversely importing the IAS tenant's metadata into the subaccount trust configuration. This bidirectional exchange establishes mutual trust: the subaccount will accept assertions signed by IAS's certificate, and IAS knows the subaccount's expected audience and callback URLs. In multi-subaccount landscapes, a common pattern is to configure one shared custom IAS tenant as the trusted identity provider for all subaccounts belonging to one line of business, so that users have a single sign-on experience across dev, test, and production application instances, while still using separate role collections per subaccount to prevent, for example, a test-environment role collection accidentally granting access in production. Applications running on Cloud Foundry typically bind to the XSUAA (Authorization and Trust Management) service instance, which is configured via the xs-security.json descriptor discussed conceptually in the authorization model. When an app is pushed and bound to an XSUAA service instance, the service broker creates the OAuth client, registers the defined scopes and role templates in the subaccount, and issues client credentials used by the application to validate incoming tokens and, where needed, act as an OAuth client itself to call other services (service-to-service, machine-to-machine authentication using client credentials grant). This is distinct from the user-to-application flow, where a human logs in via browser redirect (authorization code grant), authenticates against the trusted identity provider, and receives a token containing their scopes. On Kyma, the same underlying XSUAA and IAS services are consumed, but instead of a buildpack-based binding, applications typically use Kubernetes-native patterns: a service instance and service binding are created via the SAP BTP service operator (custom resources), and the resulting credentials (client ID, client secret, token endpoint, JWKS URL) are mounted into the pod as a Kubernetes secret. The application code (or a sidecar/istio policy in more advanced setups) is then responsible for validating incoming JWTs against the JWKS endpoint. This means that in Kyma, security configuration is expressed declaratively as Kubernetes manifests rather than manifest.yml or mta.yaml bindings, and troubleshooting requires checking both the service binding secret and the pod's environment/mounted volume rather than only the cockpit's service instance view. A frequent point of confusion in intermediate-level projects is understanding that role collections are subaccount-scoped, not global-account-scoped. Deploying the same application to two subaccounts (say, quality and production) requires separately creating and assigning role collections in each subaccount, even if the underlying xs-security.json and role templates are identical, because role templates only become 'live' role collections once an administrator explicitly creates them in the target subaccount's Security > Role Collections screen (or via automation, such as a Cloud Foundry CLI script or content transport approach used for CI/CD security artifact promotion). Failing to script or document this step is one of the most common causes of 'it works in test but not in production' access issues in BTP projects.

Code example

# Example: creating and binding an XSUAA service instance for Cloud Foundry# using the Cloud Foundry CLI, referencing an xs-security.json descriptor cf create-service xsuaa application xsuaa-invoice-app -c xs-security.jsoncf bind-service invoice-approval-app xsuaa-invoice-appcf restage invoice-approval-app # Example: Kyma/Kubernetes service instance and binding using# the SAP BTP service operator (simplified custom resource) apiVersion: services.cloud.sap.com/v1kind: ServiceInstancemetadata:  name: xsuaa-invoice-appspec:  serviceOfferingName: xsuaa  servicePlanName: application  parameters:    xsappname: invoice-approval-app    scopes:      - name: "$XSAPPNAME.Approve"        description: "Approve invoices"---apiVersion: services.cloud.sap.com/v1kind: ServiceBindingmetadata:  name: xsuaa-bindingspec:  serviceInstanceName: xsuaa-invoice-app  secretName: xsuaa-invoice-app-credentials # The resulting secret 'xsuaa-invoice-app-credentials' contains# clientid, clientsecret, url (token endpoint), and jwks endpoint# which the application pod uses to validate incoming JWT tokens.

Real project scenario

During a go-live for an integration monitoring dashboard, the project team promoted the application from a quality subaccount to production using the same mta.yaml and xs-security.json, assuming security setup would carry over automatically. On go-live day, all users received access-denied errors despite being correctly federated through the shared corporate IAS tenant. Root cause analysis showed that while the XSUAA service instance and role templates were correctly created in production during deployment, no one had created the actual role collections or assigned users to them in the production subaccount, since that step had been done manually in quality and was never scripted. The team resolved this by building a post-deployment automation step using the platform's command-line tooling to create role collections and assign a default administrator group immediately after each environment's first deployment, preventing recurrence in later phases.

Common mistakes

• Assuming role collections migrate automatically between subaccounts during deployment promotion, when in fact they must be explicitly created and assigned per subaccount • Confusing the Cloud Foundry XSUAA binding pattern with the Kyma service-operator/secret pattern and applying troubleshooting steps from one runtime to the other • Using the client credentials (service-to-service) OAuth flow for scenarios that actually involve a human user, resulting in tokens without the expected user-specific scopes • Not rotating or securing XSUAA/IAS client secrets consistently, especially when secrets are manually copied instead of managed through the service binding lifecycle • Configuring trust to a personal or temporary IAS tenant during a proof of concept and forgetting to repoint to the corporate-managed IAS tenant before go-live

Best practices

• Script or automate role collection creation and initial assignment as part of the deployment pipeline rather than relying on manual cockpit steps • Maintain a single, centrally governed custom IAS tenant per line of business or organization rather than ad hoc trust configurations per subaccount • Clearly separate service-to-service (client credentials) OAuth clients from user-facing (authorization code) clients, and document which is used where • Store and rotate XSUAA/IAS client secrets using the platform's supported service binding and credential rotation mechanisms rather than static copies • Validate trust and role collection configuration explicitly as part of go-live checklists, rather than assuming successful deployment implies working security

Interview angle

Expect questions about the practical difference between configuring security on Cloud Foundry (xs-security.json, service bindings) versus Kyma (BTP service operator, Kubernetes secrets), and about why role collections must be re-created per subaccount even with identical application code. A strong answer connects the technical binding mechanics back to the conceptual model of trust and scopes, and cites a concrete example of diagnosing an access issue caused by an incomplete security artifact promotion between environments.