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
Authorization management with OpenSearch's Document Level Security - SAP Cloud Logging
Where the predecessor SAP Application Logging service reused CF space permissions for read-only access, SAP Cloud LoggingSAP Cloud LoggingAn instance-based observability service built on OpenSearch that stores and analyses logs, metrics and traces from Cloud Foundry, Kyma, Kubernetes and other runtime environments.sap official, btp integrates with SAP Cloud Identity ServicesCloud Identity ServicesIdentity Authentication and Identity Provisioning as one tenant: the login, the user store or the federation to a corporate identity provider, and the provisioning of users into whatever sits behind it.sap official, btp (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.
Where it sits
Explains
SAP Cloud LoggingBTPSAP Cloud LoggingAn instance-based observability service built on OpenSearch that stores and analyses logs, metrics and traces from Cloud Foundry, Kyma, Kubernetes and other runtime environments.AuthorizationBTPAuthorizationDeciding 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.
Source
reachable
Who is behind it
Hariharan-Gandhiauthor
Properties
About this work
For authorization
Applies in
Group by34 of 34 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
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
How to Access SAP Cloud Logging Service Dashboards Using IAS SAML AuthenticationHow to Access SAP Cloud Logging Service Dashboards Using IAS SAML AuthenticationWalks through wiring SAML 2.0 single sign-on between SAP Cloud Identity Services (IAS) and SAP Cloud Logging so its OpenSearch dashboards accept IAS logins instead of a service key: creating the SAML application in IAS, editing the instance's saml parameters (admin_group, idp.metadata_url, idp.entity_id, sp.entity_id), setting the matching entity ID and endpoints on the IAS side, and mapping an IAS group to the all_access role through a groups attribute. It also shows how to read a 403 on the dashboard as SAML login succeeding while the group-to-role mapping is still missing.Umezuki, published 2025-12-30
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
SAP API ManagementのアクセスログをSAP Cloud Loggingで可視化する方法SAP API ManagementのアクセスログをSAP Cloud Loggingで可視化する方法In Japanese. API Management's own screens show call counts but not the individual request log — no audit trail, no header or IP detail, which leaves auth failures hard to diagnose. The author's fix is an API Policy that builds a structured log entry with AssignMessage and forwards it through a syslog drain to SAP Cloud Logging, and confirms the ingest endpoint works by PUTting a test message to it directly with Postman before wiring the policy.yasuyukiuno, published 2025-09-24
Instance Sharing - SAP Cloud LoggingInstance Sharing - SAP Cloud LoggingExplains how to share one SAP Cloud Logging instance across Cloud Foundry spaces, subaccounts and regions instead of provisioning one per space, contrasting built-in platform sharing, where credentials are transferred automatically but the scope stays narrow, within a single subaccount in the post's own example, with reusing a service key through a Cloud Foundry User-Provided Service, which applies across regions, subaccounts and environments but leaves credential transport and rotation to the customer. Walks through a cf share-service example and the cost, legal and ingestion-throughput tradeoffs against dedicated instances.Hariharan-Gandhi, published 2025-08-13
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
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
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.
From Application Logging to Cloud Logging: Service Innovation GuideFrom Application Logging to Cloud Logging: Service Innovation GuideSAP Cloud Logging replaces SAP Application Logging service, moving each customer from a shared multitenant stack to a dedicated, fully isolated one, and this guide sets out what changes with the move: a deployment per compliance region instead of per Cloud Foundry landscape, SAML/IDP-based authentication instead of Cloud Foundry-bound auth, retention that is configurable instead of fixed at seven days, and hourly capacity-unit pricing instead of fixed-size monthly plans. It also states the deprecation timeline for logging on BTP: SAP Application Logging closes to new or renewed CPEA contracts after 2025-07-31, while contracts signed before that date keep their entitlement until their next renewal.Hariharan-Gandhi, published 2024-11-22
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.
Kyma Integration with SAP Cloud Logging. Part 2: Let's ship some tracesKyma Integration with SAP Cloud Logging. Part 2: Let's ship some tracesWalks through shipping traces from SAP BTP, Kyma runtime to SAP Cloud Logging: a Kyma TracePipeline resource pointed at the service binding's OTLP endpoint, an Istio Telemetry resource that sets the mesh-wide sampling percentage, and Cloud Logging's Trace Analytics view to filter the resulting spans by service name or request ID. For a multitenant JavaScript CAP application it instruments with @cap-js/telemetry, naming the npm packages to add, and covers Cloud Native Buildpacks and manual Istio header propagation for services outside CAP.gabbi, published 2024-04-19
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
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
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
Why developers should care about credential-types for xsuaa?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.former_member2839, published 2022-07-05
Why developers should care about credential-types for xsuaa?
Authorization has changed twice since this was published, most recently in CAP Java 3.7.1, 2025-01-30. Affects A recipe, Runnable code.
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
AI-assisted operations: SAP Cloud ALM and SAP Cloud Logging in actionAI-assisted operations: SAP Cloud ALM and SAP Cloud Logging in actionSAP Cloud Logging in an operations loop for the SAP Business AI Platform, with SAP Cloud ALM: the abstract assigns detecting a problem to Cloud ALM, supporting its resolution to AI, and the deeper analysis to Cloud Logging, and names the loop as automated detection, alerting and AI-guided troubleshooting with a person deciding, which is what operations automation covers. Which AI, and what it may do without that person, the abstract does not say. A TechEd 2026 session (Wednesday 28 October, Berlin), presented by Stephanie Jerch and Thorsten Sandfuchs, written here from SAP's abstract; the recording is not yet published.
Deploy, review, break, fix: Govern cloud transports with agility and AIDeploy, review, break, fix: Govern cloud transports with agility and AIFive BTP services in one delivery chain, as the abstract lays it out: a transport is triggered in SAP Content Agent Service, tested in SAP Cloud Transport Management, its failure is raised by SAP Alert Notification service for SAP BTP and remediated by a SAP Joule agent with SAP Automation Pilot, and SAP Cloud Logging keeps the history for root-cause analysis. The chain from alert to remediation is the operations automation concern; what the Joule agent decides on its own is not in the abstract. A TechEd 2026 session (Thursday 29 October, Berlin), presented by Biser Simeonov, Daniel Funkert, Sven Rullmann and Thorsten Sandfuchs, written here from SAP's abstract; the recording is not yet published.
What’s next for the core platform capabilities of SAP Business AI PlatformWhat’s next for the core platform capabilities of SAP Business AI PlatformA preview of the operations layer beneath SAP Business AI Platform: selected road map highlights across Joule Studio runtime, Cloud Identity Services and SAP Cloud Logging, on how enterprise AI is governed and run. The edges are to the two named services and to SAP Joule, whose agents the Joule Studio runtime runs; the abstract names the three areas and no highlight. A TechEd 2026 session (Tuesday 27 October, Berlin; also XP825V, virtual), presented by Andre Lamego and Jens Huesken, written here from SAP's abstract; the recording is not yet published.
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
SAP Cloud Loggingartifact
Authorizationcapability, core and community
SAP Communitypublishing source
SAP Communitybtp-tag
SAP Communitycloud-foundry-tag
Source
Type
blog
Published on
Host
community.sap.com
Discovered via
First seen
History
- Entered the atlasDiscovered via SAP Community · btp-tag, SAP Community · cloud-foundry-tag.
For your agent
- Ref
content:authorization-management-with-opensearch-s-document-level-security-sap-cloud-log- JSON
- /content/authorization-management-with-opensearch-s-document-level-security-sap-cloud-log.json
- MCP
- Connecting an agent