BlogBlogA post on somebody's own site or a community platform. Nobody edits it after publication, so it dates from the day it was written.See every one →SAP Community
Why developers should care about credential-types for xsuaa?
Rotating secrets, argued from a habit rather than a feature: the author names the practice implicit in many beginner tutorials — lifting a secret out of a binding to use it elsewhere — and notes CAP has features that make it unnecessary in development. Then the three credential types side by side, configured on a CAP application's uaa resource in mta.yaml and through a deployment extension.
Where it sits
Explains
AuthorizationCAPBTPAuthorizationDeciding who may read or change what, at service, entity and instance level — role checks, forwarded user context, and restrictions evaluated as query filters rather than after the fact.
Since then
Authorization has changed twice since this was published, most recently in CAP Java 3.7.1, 2025-01-30
Source
reachable
Who is behind it
former_member2839author
Before you read it
read from the pageApplicabilityCore changedAuthorization has changed twice since this was published, most recently in CAP Java 3.7.1, 2025-01-30.
This is a derived prompt to re-check the work, not a claim that the work is wrong. Exact stale statements are recorded separately after editorial review.
Properties
About this work
What was found on the page
Prose
2,042 words
Numbered steps
14
Code blocks
46
For authorization
Applies in
Group by33 of 33 pieces
Piece, what it offersStill applies
Named-User Attribution Across BTP Subaccounts: A Two-Hop IAS Token Exchange for Cloud IntegrationNamed-User Attribution Across BTP Subaccounts: A Two-Hop IAS Token Exchange for Cloud IntegrationA central BTP application that manages Cloud Integration across subaccounts with client_credentials collapses every user into one technical service principal: target subaccounts' role collections are bypassed and the audit log names a service key instead of a person. The post works through a two-hop exchange — an IAS app-to-app hop, then the target subaccount's XSUAA jwt-bearer hop — that carries the calling user's own identity across the subaccount boundary through a shared Cloud Identity Services tenant, so the target subaccount enforces the user's own role collection and records their identity in the audit log. It walks through the IAS app-dependency setup, the AppRouter and SAP Destination service configuration the exchange needs, and states the pattern applies to any XSUAA-protected service in a separate subaccount, not only Cloud Integration.agnissh, published 2026-08-24
Connecting a Custom MCP Server to Joule Work Desktop: A Seamless and Secure Authentication FlowConnecting a Custom MCP Server to Joule Work Desktop: A Seamless and Secure Authentication FlowWalks through connecting a custom MCP server to Joule Work Desktop: a Dynamic Client Registration handshake (RFC 7591) followed by an Authorization Code + PKCE flow through the organisation's SSO via XSUAA or IAS, so authentication establishes the human identity that Joule then attaches to every subsequent tool call. That forwarded identity lets the BTP backend apply its existing authorization checks and row-level data filtering instead of a second permission model, and a role change in XSUAA revokes access on the next token refresh.published 2026-08-17
Securing a CAP Node.js App with SAP AMS on BTP Cloud FoundrySecuring a CAP Node.js App with SAP AMS on BTP Cloud FoundryThe end-to-end version: a CAP Node.js project from cds init, role-based access through the Authorization Management Service and Identity Authentication Service, and an MTA deployment to Cloud Foundry. The prerequisite list is the useful part to read first — HANA Cloud, an IAS tenant and an AMS entitlement — because it says plainly what this path costs before you are three steps into it.Jacky Liu, published 2026-07-17
Effective from June 30th 2026 - XSUAA Deprecation of GET Method for OAuth Token RetrievalEffective from June 30th 2026 - XSUAA Deprecation of GET Method for OAuth Token RetrievalEffective June 30th 2026, the SAP Authorization and Trust Management service (XSUAA) deprecates the HTTP GET method for retrieving an OAuth access token from its /oauth/token endpoint, leaving only POST supported in line with RFC 6749. A client still requesting a token via GET with grant_type and credentials in the query string stops working after the cutover and must switch to a POST request with form-encoded body parameters.Yogananda, published 2026-06-14
From XSUAA to AMS: Architecting S4HANA CAP Extensions with Policy-Based AuthorizationFrom XSUAA to AMS: Architecting S4HANA CAP Extensions with Policy-Based AuthorizationWhy scope-based authorization runs out, argued from enterprise extension work rather than from the documentation: XSUAA handles roles well, but real requirements are business-context restrictions — country, company code, organisational unit — and expressing those as scopes does not scale. The migration to policy-based authorization is presented as an architectural move for S/4HANA extensions rather than a configuration change.Avinash Vaidya, published 2026-05-27
How to Restrict CRUD Operations in SAP CAPM Using @Capabilities, @readonly and Test APIs with .httpHow to Restrict CRUD Operations in SAP CAPM Using @Capabilities, @readonly and Test APIs with .httpEntities are exposed with full CRUD by default, and this is how to take operations away again — @Capabilities for Insert, Update and Delete individually, @readonly for the blunt version. Tested with .http files rather than a UI, which keeps the check on the service.DeepaRagho, published 2026-05-22
Dynamic authorisation with user attributes in SAP CAP and AMSDynamic authorisation with user attributes in SAP CAP and AMSThe same argument as the XSUAA-to-AMS piece, opened from a concrete failure: an acquisition puts 500 users on sales data restricted by division, and role-based access control answers it with Sales_Manager_EMEA, Sales_Manager_APAC and so on until the roles multiply past managing. Attribute-based authorisation replaces the set with one policy carrying a restriction, and the post walks through defining it in AMS against Cloud Identity Services. The clearest statement of role explosion among the three AMS pieces here.pedro_iranzo, published 2026-05-04
Agentic AI on BTP: a Single Agent with LangGraphAgentic AI on BTP: a Single Agent with LangGraphA CAP TypeScript agent puts a LangGraph StateGraph in front of AzureOpenAiChatClient from @sap-ai-sdk/langchain, reaching SAP AI Core's Generative AI Hub, and lets its tool-calling loop draw on five deployed MCP servers — OData MCP Proxy, CI MCP Server, AI Core MCP Server, BTP MCP Server and BTP CF MCP Server — through @langchain/mcp-adapters' MultiServerMCPClient. Because agent, servers and APIs share one XSUAA tenant, the chat service forwards the signed-in user's own JWT instead of a service account, so each downstream server enforces that user's own authorizations. Past roughly a hundred combined tools the single prompt slows down and stops separating concerns, which is why the author's next post splits it into one specialist agent per MCP server behind an orchestrator.published 2026-05-03
SAP BTP XSUAA Security Configuration Comparison: Attribute-Based vs. Authority-Based ApproachesSAP BTP XSUAA Security Configuration Comparison: Attribute-Based vs. Authority-Based ApproachesTwo shapes of the same xs-security.json set against each other, with the resulting JWT printed for both. The consequence for application code is what makes it worth reading: under the attribute-based configuration a CAP handler reads req.user.attr.department, and under the authority-based one it does not, because the attribute is not there. Carries a migration guide between the two.rajeshkputumbaka, published 2026-02-18
Securing CAP Applications with SAP Cloud Identity Services and AMSSecuring CAP Applications with SAP Cloud Identity Services and AMSIdentity Authentication and AMS together as the current answer for a CAP application — authentication, single sign-on and the identity lifecycle on one side, policies on the other.gopalanand, published 2025-12-04
Authorization management with OpenSearch's Document Level Security - SAP Cloud LoggingAuthorization management with OpenSearch's Document Level Security - SAP Cloud LoggingWhere the predecessor SAP Application Logging service reused CF space permissions for read-only access, SAP Cloud Logging integrates with SAP Cloud Identity Services (IAS) and controls per-document visibility through OpenSearch's Document Level Security: an IAS group becomes a backend role, mapped to an OpenSearch role that carries a DLS query filter, so a search request only ever returns documents whose indexed field (space_name, organization_id, or another keyword field) matches what that role's filter allows. It walks through fixed per-space roles, a shared multi-space role using a terms query, and a single dynamic role that substitutes ${user.roles} into the filter so the match is against the caller's own groups, then lists operational pitfalls — wildcard index patterns breaking Dashboards, DLS roles that also hold write access creating log entries nobody can read back, and match queries against a .keyword field being non-deterministic where term queries are exact.Hariharan-Gandhi, published 2025-11-24
Joule Studioがリリースされたので早速CAPアプリを自然言語で操作するカスタムスキルを構築してみたJoule Studioがリリースされたので早速CAPアプリを自然言語で操作するカスタムスキルを構築してみたA walkthrough of building a custom Joule Studio skill on a CAP bookshop app: cds add sample and cds add mta scaffold the project and its deployment descriptor, cds compile srv/ --to xsuaa generates the role template behind the @requires: 'admin' check on AdminService from the SAP Authorization and Trust Management service (XSUAA), and mbt build packages the app for deployment to the SAP BTP, Cloud Foundry Runtime. The skill reaches the deployed OData API through the SAP Destination service, configured with the OAuth2 Client Credentials grant using the client ID, secret and token endpoint from the app's XSUAA service key, so Joule answers a natural-language question about a book by its ID.takayuki_tanaka, published 2025-07-30
Securing SAP CAP Applications: XSUAA, Roles, and Authorization Best PracticesSecuring SAP CAP Applications: XSUAA, Roles, and Authorization Best PracticesWalks through securing a CAP service end to end: declaring scopes and role templates in xs-security.json for the SAP Authorization and Trust Management service (XSUAA), restricting CDS service definitions with @restrict per role, and dropping into handler code where a rule needs custom logic, with a @sap/cds Node.js example that tests roles through req.user.is and a Java one that tests scopes through hasScope. It closes in the BTP cockpit, where a role collection is assigned to users so that their JWT carries the scopes those checks read.Soumya-Pirlamarla, published 2025-07-14
SAP IAM integration with SAP Cloud Identity ServicesSAP IAM integration with SAP Cloud Identity ServicesIdentity and access management for SAP SaaS in a landscape where SAP is one vendor among several: SAP Cloud Identity Services as the designated interface, single sign-on over SAML 2 and OIDC, identity lifecycle through SCIM 2 replication of users and groups, and authorization designed per domain — an S/4HANA role and a BTP role collection are different objects that both have to reach the user. Drawn from customer projects, and the source of what authentication here says about Cloud Identity Services.published 2025-05-13
CAP-JAVA implementation for Authorization Management Service (AMS)CAP-JAVA implementation for Authorization Management Service (AMS)Short and deliberately narrow: the author defers the concepts to kevin_li's post and writes only the CAP Java part — the development flow, designing the authorization model, and assigning and checking a policy. Read the other one first; this is the half that touches the code.Harvey_Yao, published 2024-12-27
Enabling Authorization Policies in SAP Cloud Identity Services - IAS with AMS/CAPEnabling Authorization Policies in SAP Cloud Identity Services - IAS with AMS/CAPAuthorization policies defined in Identity Authentication and consumed by a CAP application through AMS — the configuration half of the move away from XSUAA scopes, from the identity service's side rather than the application's.Yogananda, published 2024-12-27
Enabling Authorization Policies in SAP Cloud Identity Services - IAS with AMS/CAP
Authorization changed in CAP Java 3.7.1, 2025-01-30. Affects A recipe.
CAP for nodejs安全的暴露接口练习CAP for nodejs安全的暴露接口练习Starting from the risk-management sample, the walkthrough adds an open ExternalAPI service beside the existing RiskService, then moves every security annotation into a separate service-auth.cds file: @requires: authenticated-user on one entity, role-scoped @restrict grants for RiskViewer and RiskManager on another. It tests the unprotected action locally with cds watch, calling it from Postman with the session cookie read out of SAP Business Application Studio's preview tab. It then deploys to BTP and reads Risks with a client-credentials OAuth token fetched from a service key of the cpapp-auth instance, after changing that entity's READ grant from RiskViewer to authenticated-user, which the post, citing capire's CDS-based Authorization page, describes as a grant for a technical user integrating systems rather than for access from a front end.ArthurYang, published 2024-12-10
Authorization Management Service in SAP Cloud Identity ServiceAuthorization Management Service in SAP Cloud Identity ServiceStates the direction of travel plainly — BTP moving authorization management from XSUAA to AMS inside SAP Cloud Identity Service — and then explains what a policy is, which is the unit that replaces a scope. Split between authorization for Cloud Identity itself and for custom business applications, and it is the concept post the CAP Java write-up refers back to.kevin_li, published 2024-10-17
XSUAA Local TestingXSUAA Local TestingAdding XSUAA to a CAP project two ways, and then the part that is usually missing: getting the authorisation to behave on a laptop rather than only after deployment. The default authentication mechanism is the easy half; testing it without a landscape is the reason this exists.ManasaManu, published 2024-10-17
XSUAA Local Testing
Authorization has changed twice since this was published, most recently in CAP Java 3.7.1, 2025-01-30. Affects A recipe, Runnable code.
SAP CAP(Cloud Application Programming)开发框架概述SAP CAP(Cloud Application Programming)开发框架概述A Chinese-language walkthrough of CAP built mainly from CAPire's own "About CAP" page: CDS entities, associations, compositions and aspects for data modelling, with an extend Books with @restrict: [{ grant:'WRITE', to:'admin' }] aspect as its authorization example; CQL and CQN queries shown against both a local service and OData's $select/$expand; and the service-and-event model — this.on, this.emit, srv.on — that carries CAP's async processing. It closes with the author's own setup: installing @sap/cds-dk, scaffolding a bookshop project with cds init, and running it with cds watch against local SQLite, mocked authentication and file-based messaging standing in for HANA Cloud, IAS and Kafka.ArthurYang, published 2024-01-07
XSUAA Based Authentication - Using Managed ApprouterXSUAA Based Authentication - Using Managed ApprouterOne half of a pair published the same day, both starting from capire's list of authentication kinds and then going end to end on XSUAA. This is the managed approuter route, where the platform runs the router and the application supplies configuration rather than a module.rahul_rajagopal, published 2023-09-25
XSUAA Based Authentication - Using Managed Approuter
Authorization has changed twice since this was published, most recently in CAP Java 3.7.1, 2025-01-30. Affects A recipe.
XSUAA Based Authentication - Using Standalone ApprouterXSUAA Based Authentication - Using Standalone ApprouterThe other half: the same end-to-end XSUAA setup with an approuter you deploy and own. Published alongside the managed version, and the two are worth reading together because the difference between them is the whole decision.rahul_rajagopal, published 2023-09-25
[Part - 1] Enrich CAP based Services with Behaviors using Annotations[Part - 1] Enrich CAP based Services with Behaviors using AnnotationsWalks through CDS annotations that add behaviour beyond CRUD: @readonly and @insertonly take away write, update or delete on an entity or element, each shown with the OData metadata it generates. @mandatory, @assert.unique, @assert.integrity, @assert.format and @assert.range then enforce input checks that @sap/cds runs on write, with the SQL or HANA constraint @assert.unique compiles to and the error code each rejection returns. It names @restrict and @requires but defers them, calling authorization too large a topic for this post.published 2023-01-28
SAP Job Scheduling Service + Cloud Application Programming Model application (CAP) + SAP Authorization and Trust Management Service (XSUAA)SAP Job Scheduling Service + Cloud Application Programming Model application (CAP) + SAP Authorization and Trust Management Service (XSUAA)Calling an unsecured endpoint on a schedule is trivial; this is the same thing once the endpoint is protected. The interesting part is the caller — the Job Scheduling Service is not a person, so CAP's pseudo-roles are where the post spends its time, and $XSSERVICENAME has to match the scheduler's own instance name.former_member412792, published 2022-12-12
Useful CAP CDS and Fiori Commands to Accelerate Development and DeploymentUseful CAP CDS and Fiori Commands to Accelerate Development and DeploymentA command-by-command walkthrough of @sap/cds-dk's cds add and fiori add generators: cds add xsuaa writes an XSUAA security configuration from the CDS model's authorization annotations, and cds add hana together with cds deploy --to hana switches persistence from the default SQLite database to SAP HANA Cloud. cds add mta and fiori add deploy-config, from @sap/generator-fiori, build the Cloud Foundry deployment descriptor together, adding a destination-service block and an xs-app.json that routes the Fiori app's calls through a named destination.TiaXu, published 2022-10-19
Qualtrics integration with domain based authorization in CAP project on HANA cloudQualtrics integration with domain based authorization in CAP project on HANA cloudSurveys pulled from Qualtrics into a CAP application in real time, with the twist in the title: authorisation decided by the user's domain rather than by a role collection. A pattern that comes up whenever the audience is wider than the tenant.former_member69893, published 2022-09-30
Qualtrics integration with domain based authorization in CAP project on HANA cloud
Authorization has changed twice since this was published, most recently in CAP Java 3.7.1, 2025-01-30. Affects Runnable code.
An approach to secure multiple integrated SAP CAP java applications with a common XSUAA service instanceAn approach to secure multiple integrated SAP CAP java applications with a common XSUAA service instanceOne XSUAA instance across several CAP Java applications that call each other, rather than one per application. Short, and written from inside SAP Labs as something the author tried — the value is the shape of the arrangement, not a walkthrough.sreanik_dhanyakumar2, published 2022-09-14
SAP Business Technology Platform: Authorization and Trust Management ServiceSAP Business Technology Platform: Authorization and Trust Management ServiceWalks through how the SAP Authorization and Trust Management service secures a BTP application: scopes, attributes and role templates in the security descriptor, and the OAuth 2.0 resource-owner, client and resource-server roles it builds on. Covers the XSUAA microservice as the OAuth 2.0 authorization server bound to each application through its service broker, the signed JSON Web Token it issues after authentication, and the App Router's place in front of the resource apps as the gateway that starts authentication and checks for cross-site request forgery.SekhuteTK, published 2022-09-09
How to get authenticated user information with CAP in three different ways – Using the XSUAA APIHow to get authenticated user information with CAP in three different ways – Using the XSUAA APIThe third of three approaches the author sets out, and the one that returns the most: going to the XSUAA API directly rather than reading what CAP already put on the request. Depends on an earlier post for the project setup, so it starts mid-stream on purpose.ale_biagi, published 2022-07-18
Insights of Cloud SDK, CAP, XSUAA, SSH and other BTP topics from 2021Insights of Cloud SDK, CAP, XSUAA, SSH and other BTP topics from 2021A year in review, and one section in it is the reason it is here: "CAP isn't the solution for everything" — the author's point being that a pure UI5 or Fiori application does not need a CAP service wrapped around it, and that an approuter or the HTML5 Application Repository may be the better answer. The XSUAA section is a complaint about complexity rather than a guide, which is also worth having on the record.dr_vup, published 2021-12-30
Understanding security approaches in SAP CAP using XSUAA in node.js flavor and MTA.Understanding security approaches in SAP CAP using XSUAA in node.js flavor and MTA.The long version, from the MTA project outward: what the deployment descriptor has to contain, how the authentication flow actually runs, and then the npm modules doing the work — @sap/xssec and @sap/xsenv named and explained rather than left as dependencies. Old, and the module names have moved on, but the flow it draws has not.balbinosoares, published 2020-03-16
Understanding security approaches in SAP CAP using XSUAA in node.js flavor and MTA.
Authorization has changed twice since this was published, most recently in CAP Java 3.7.1, 2025-01-30. Affects A recipe, Runnable code.
Using Postman for API Testing with XSUAAUsing Postman for API Testing with XSUAAA way to get a JWT without routing traffic through the approuter and picking the token out of it. The author walks the alternatives first — redirect through the router, intercept the token — and says what is wrong with each, before requesting the token from the service directly.mariusobert, published 2020-03-02
How SAP secures enterprise AI agents with identity propagationHow SAP secures enterprise AI agents with identity propagationCloud Identity Services as the identity layer for AI agents as well as people: the abstract states that both are managed in one directory, that user context is propagated by token exchange, and that authorisation is enforced at every hop, so no agent holds back-end credentials. Agents from Microsoft, Google and partners take the same flow through the agent gateway. Token exchange across a hop is the authentication side and the per-hop check the authorisation side; what the agent gateway is, and whether it is a product, the abstract does not say. A TechEd 2026 session (Wednesday 28 October, Berlin), presented by Gunnar Kosche and Sebastian Ries, written here from SAP's abstract; the recording is not yet published.
Details
Graph
Source
Type
blog
Published on
Host
community.sap.com
Discovered via
First seen
History
- explains → applies_to on capability:authorization (cap, btp)Door scope proposed from the title and summary, so a door page lists the piece only where it holds (docs/concepts/content-on-doors.md).
- Entered the atlasDiscovered via SAP Community · cap-tag.
For your agent
- Ref
content:why-developers-should-care-about-credential-types-for-xsuaa- JSON
- /content/why-developers-should-care-about-credential-types-for-xsuaa.json
- MCP
- Connecting an agent