QSAP admin setup guide

Status, stated plainly

Some parts of QSAP are live today and others are rolling out. Every section below is labelled.

Until SSO is live, pilots use per-user access tokens that the QSAP admin issues. Don't run a production rollout on those tokens. Wait for SSO.

0Overview

Architecture

 Users' AI assistant                QSAP                                  SAP S/4HANA Cloud
 (Claude, ChatGPT, Gemini,  ───►    (in your SAP BTP subaccount,  ───►    Public Edition
  Copilot Studio, ...)      MCP     or managed by Quantana)       HTTPS   released OData APIs
                            over    - sign-in (OAuth 2.1 facade)  OData   (read only), via
                            HTTPS   - role policy (groups →               Communication
                                      tools/plants)                       Arrangements
                                    - input checks, short cache
                                    - hash-chained audit trail
                                       │
                                       │ OIDC (authorization code + PKCE)
                                       ▼
                              SAP Cloud Identity Services (IAS)
                              (optionally proxying Microsoft Entra ID / Okta)

• Users connect their AI assistant to one address, for example https://qsap.yourcompany.com/mcp.
• QSAP signs each user in through your identity provider. It then applies your QSAP role policy and calls only SAP's released OData APIs. Every call is read-only and recorded in a tamper-evident audit trail.
• Technical mode Available: one communication user serves all calls. QSAP still enforces per-person policy and audits the real person.
• Per-user mode Rolling out: OAuth 2.0 SAML Bearer. SAP sees and authorises each person with their own roles.

Who owns what

Time estimate

Prerequisites

• S/4HANA administrator with access to the Communication Management apps (Maintain Communication Users, Communication Systems, Communication Arrangements). In Public Edition this is typically the business role template Administrator (SAP_BR_ADMINISTRATOR).
• SAP BTP subaccount administrator (Option A only): can create a Cloud Foundry space and assign about 1 GB memory quota.
• Identity administrator for SAP Cloud Identity Services (and, if used, Microsoft Entra ID or Okta).
• A DNS name for QSAP, for example qsap.yourcompany.com, or the default BTP route.

1SAP side (S/4HANA Cloud Public Edition)

In S/4HANA Cloud Public Edition, external systems call APIs through communication arrangements. An arrangement ties a communication scenario (a SAP-defined bundle of APIs) to a communication system (the caller, here QSAP) and a communication user (its credentials). SAP's Communication Scenarios overview (Sales) puts it this way: "APIs usually come with a predefined communication scenario." For a worked SAP procedure using the same three apps (prerequisite role SAP_BR_ADMINISTRATOR, then communication user, communication system and arrangement), see Material Stock Integration (SAP_COM_0164) in the SAP Digital Manufacturing integration guide.

1.1 Create the communication user

App: Maintain Communication Users → New.

The user authenticates with user/password over HTTPS, or with an X.509 client certificate (mutual TLS) if your security policy requires it. Both are supported today — tell Quantana which one you want before go-live so the connection can be configured and tested against your tenant.

Current build, to be precise: QSAP's technical mode connects to a live S/4HANA Cloud tenant with SAP_AUTH_METHOD=basic (user ID + password, set via SAP_USER/SAP_PASSWORD) or SAP_AUTH_METHOD=client-cert (mutual TLS, certificate and key loaded from files named by SAP_CLIENT_CERT_FILE/SAP_CLIENT_KEY_FILE). Quantana configures and tests the connection with your communication user on your own tenant during onboarding, before any user is connected.

1.2 Create the communication system

App: Communication Systems → New.

For the per-user trust steps, SAP's tutorial Integrate SAP BTP ABAP Environment and SAP S/4HANA Cloud using the OAuth 2.0 SAML Bearer Assertion Flow walks through the same Communication Systems screens: enable the OAuth 2.0 identity provider and upload the signing certificate.

1.3 Create one communication arrangement per API

App: Communication Arrangements → New → choose the scenario → select communication system QSAP → inbound user QSAP_COMM_USER. Repeat for each scenario. The same system and user can be reused across all arrangements.

These are the exact released APIs and entity sets that QSAP calls (taken from QSAP's source):

To find a scenario ID: on the SAP Business Accelerator Hub, open the API and look under Overview → Configuration Details → Communication Scenario. SAP Help says the same: check the API's Details tab to see which communication scenarios it belongs to. Scenario contents can change between releases, so check against your current release.

After saving each arrangement, note the service URL. All APIs share the tenant's API host, for example https://my123456-api.s4hana.cloud.sap/sap/opu/odata/sap. Quantana needs only that base URL.

1.4 Read-only by design

• QSAP's SAP client only sends HTTP GET requests with $select, $filter, $top and $orderby. It has no generic query tool and no write routes.
• Material Stock – Read is itself read-only: SAP's documentation says create/update/delete (CUD) operations are not supported by this API service.
• Other scenarios (Production Order, BOM, Sales Order) include write operations because SAP bundles them. QSAP never invokes them. Where an arrangement lets you deactivate inbound services you don't need, leave only the services above active.
• The audit trail proves it. Every SAP call is recorded with its URL and HTTP status in an append-only, SHA-256 hash-chained log (section 6). Your auditors can confirm that no write calls were made.

1.5 Per-user mode: business users and authorisations Available with QSAP SSO (rolling out)

• Each QSAP user must exist as an SAP business user whose email matches the email in your identity provider. The SAML NameID that QSAP sends is that email.
• In the communication arrangement, choose OAuth 2.0 as the inbound authentication method. The arrangement then shows OAuth 2.0 details (client ID, token service URL, SAML2 audience). Send those three values to Quantana.
• SAP then applies that person's business roles and restrictions (for example a plant restriction) to every call. A user without stock display authorisation gets no stock data, whatever QSAP's policy says. Assign business roles that contain the business catalogs for each API's data, and check each API's SAP Help page for the required authorisations. For example, SAP documents that stock display needs a role such as Warehouse Clerk or Inventory Manager.
• QSAP caches the SAP token per user until shortly before it expires. This flow has no refresh token.

1.6 Private Edition and on-premise: differences

• APIs: the same released OData services exist. Activate them in /IWFND/MAINT_SERVICE instead of using communication arrangements, and grant authorisations through PFCG roles.
• Technical mode: a technical (system) user with a read-only PFCG role over the four services.
• Per-user mode: the ABAP OAuth 2.0 server with the SAML 2.0 Bearer flow (transactions SAML2 and SOAUTH2). See SAP Help: SAML 2.0 Bearer Assertion Flow for OAuth 2.0.
• Network: the system is usually not internet-facing. Reach it through the SAP Cloud Connector and BTP Destination service, or through your reverse proxy / SAP Web Dispatcher. QSAP's BTP-destination connector is reserved in the design and not yet built. Raise on-premise needs with Quantana early.

2Identity (SSO)

The steps below follow the current design. AI assistants (Claude, ChatGPT and others) expect an MCP server to offer OAuth 2.1 with dynamic client registration and PKCE. IAS does not offer dynamic client registration, so QSAP acts as the OAuth authorization server façade for the assistants. It delegates the actual login to IAS through one confidential OpenID Connect application. Users see your normal company login.

2.1 Create the OIDC application in IAS

Admin console of SAP Cloud Identity Services → Applications & Resources → Applications → Create. See Configure OpenID Connect (OIDC) Application for Authorization Code Flow.

Send Quantana the issuer URL (e.g. https://<tenant>.accounts.ondemand.com), the client ID, and, through the secrets channel only, the client secret.

2.2 Groups

Create user groups in IAS, for example QSAP_FINANCE, QSAP_PPC_1710 and QSAP_ADMIN (see section 3). Then assign users to them. See Assign Groups to a User. Group names reach QSAP in the groups claim.

2.3 If your workforce signs in with Microsoft Entra ID or Okta

Recommended: IAS as a proxy. Configure Entra ID (or Okta) as a corporate identity provider in IAS, as described in Configure Trust with OpenID Connect Corporate Identity Provider. Then set the QSAP application to authenticate through it. Users sign in with their Microsoft or Okta account, and IAS passes identity and groups to QSAP. Microsoft's architecture guidance covers this pattern: Using Microsoft Entra ID to secure access to SAP platforms and applications.

• To bring Entra groups through, emit a groups claim from the Entra application (Configure group claims). Then either map those claim values to IAS groups or forward them.
• Make sure the user's email reaches IAS. The same email is used in SAP for per-user mode.

Alternative: direct OIDC app in Entra ID. The QSAP design supports one OIDC identity provider. A direct Entra app (Register an application) with the same redirect URI, PKCE, the email claim and a groups claim works the same way. With the IAS proxy you also get IAS as SAP's standard identity hub, which you will probably want for SAP anyway.

3Roles and access

The QSAP_ADMIN group works today. The full group → tools/plants policy file is rolling out with QSAP SSO.

QSAP's role policy maps each identity group to the tools its members may call and the plants/regions they may ask about. A denied call returns a clear message to the assistant and is written to the audit trail as denied.

3.1 Example starter matrix

Example policy entries (illustrative; Quantana loads the final file):

{
  "QSAP_PPC_1710":  { "tools": ["list_open_work_orders", "get_work_order", "check_order_shortages",
                                "check_plant_shortages", "get_bom", "check_inventory"], "plants": ["1710"] },
  "QSAP_SALES":     { "tools": ["list_sales_orders", "check_inventory"], "plants": ["1710", "1720"] },
  "QSAP_MARKETING": { "tools": ["check_inventory"], "plants": ["*"] }
}

3.2 How SAP authorisations and QSAP policy combine

• Technical mode: SAP sees one communication user, so QSAP's policy is the access control. The communication arrangement sets the outer limit (only the four APIs), and the policy narrows it per person.
• Per-user mode: both must allow. QSAP's policy checks first (tool and plant), then SAP applies the person's own business roles and restrictions. The stricter of the two wins. This is defence in depth: a mistake in one layer doesn't expose data.

4Deploy QSAP

4.1 Option A: in your SAP BTP subaccount (Cloud Foundry)

1. BTP admin: create (or choose) a subaccount and a Cloud Foundry space, for example qsap-prod. Assign about 1 GB memory quota. Add Quantana's deployer as a Space Developer in that space only.
2. Quantana deploys QSAP as a container image. No source code is placed in your account.
3. Configuration is set as environment variables with cf set-env, or the CF v3 API, by piping from a file outside any repository. Values are never written to the manifest or committed files, and secrets are never typed on a command line. They are read with a silent prompt (see below).

APP=qsap
read -rs SECRET_IN; echo     # paste the value; nothing is echoed or saved to shell history
cf set-env "$APP" SAP_CLIENT_SECRET "$SECRET_IN"; unset SECRET_IN
cf set-env "$APP" SAP_MODE live
cf set-env "$APP" SAP_BASE_URL "https://my123456-api.s4hana.cloud.sap/sap/opu/odata/sap"
cf set-env "$APP" PUBLIC_URL "https://qsap.yourcompany.com"
cf restage "$APP"

Audit storage must be persistent. The Cloud Foundry container disk is ephemeral: it is wiped on restart, restage or redeploy. Quantana configures the audit trail on persistent storage (an attached volume or database service) as part of deployment. Don't run production with AUDIT_DB on the container disk.

4.2 Option B: managed by Quantana

Quantana runs QSAP for you in a dedicated environment in an India region. You still own the SAP side (section 1) and identity (section 2). You give Quantana the communication user credentials and the IAS client secret through a secrets channel. Quantana operates updates, monitoring and audit storage, and can export the audit trail to you on request.

4.3 Network

• S/4HANA Cloud Public Edition: no SAP Cloud Connector is needed. QSAP calls the tenant's public API host over outbound HTTPS (443) only.
• Inbound: users' AI assistants reach QSAP over HTTPS at PUBLIC_URL. Hosted assistants such as claude.ai and ChatGPT connect from the vendor's cloud, so QSAP must be reachable from the internet. Access is still gated by SSO.
• If your S/4HANA tenant uses IP allow-listing for inbound API calls, allow QSAP's egress IPs. Quantana provides them for Option B. For Option A, use your BTP region's egress IPs.

5Connect users

Share your QSAP address, for example https://qsap.yourcompany.com/mcp, and the step-by-step page for each assistant: Connect your AI assistant to QSAP (Claude, Claude Code, ChatGPT, Gemini, Microsoft Copilot Studio). Users sign in with their normal work account the first time they connect.

6Verify (checklist)

• Health check: /healthz returns {"ok":true}.

curl -s https://qsap.yourcompany.com/healthz

• Technical test call: an admin asks the assistant "What's the stock of <material> in plant <plant>?" and gets a live answer. The audit row shows ok with an HTTP 200 SAP call to API_MATERIAL_STOCK_SRV.
• SSO login Rolling out: connecting from a fresh assistant opens your company login. After sign-in the connector shows Connected.
• Role test: a user in a single-plant group asks about another plant and is denied. The denial appears in the audit trail as denied.
• Per-user test Rolling out: two users with different SAP plant restrictions ask the same question and get different answers.
• Audit trail: /admin/audit lists every call above with user email, tool, SAP URL, status and latency, and shows "Chain verified (N records)".
• Admin portal: /portal opens for a QSAP_ADMIN user and is refused (403) for everyone else.
• No writes: filter the audit trail and confirm that every SAP call is a read of one of the four APIs.

7Operate

8Changes to SAP: human in the loop

QSAP never posts changes to SAP itself. When a user asks for a change, for example a purchase requisition or a delivery-date change, this is what happens:

1. The AI assistant prepares the change and shows a preview.
2. QSAP returns a link that opens the standard SAP Fiori app with the fields pre-filled, where the SAP app supports pre-filled navigation. Fiori apps are opened by intent (#SemanticObject-action?parameter=value). See SAP Help: Intent-Based Navigation. Which fields an app accepts as start-up parameters varies by app and release, and Quantana confirms each target app on your tenant.
3. The user reviews it and posts it in SAP, as themselves.

What this means for IT:

• No write scenarios to enable. The read-only communication arrangements from section 1 are enough.
• SAP's own validations, authorisations and workflows apply to every change (business rules, approvals, release strategies), because the change is made in the standard app.
• It is normal user activity under existing user licences. A named person approves and posts each change.
• QSAP audits the prepared change: who prepared it, what was prepared, and a hash of the preview. Where the SAP document number can be read back, QSAP links it in the audit trail.
• Direct API writes, with no human step, are out of scope. The exception is a customer request for a specific high-volume case where the customer's SAP account team confirms licensing in writing.

9FAQ for IT

Where is data processed and stored (data residency)?

In Option A, QSAP runs in your BTP subaccount, in the region you chose. In Option B, it runs in Quantana's managed environment in an India region. SAP data passes through QSAP in memory on its way to the user's AI assistant. The assistant vendor's own data terms apply to what the user's assistant receives. Choose an enterprise plan with the residency and retention terms you need.

What does QSAP store?

• Audit metadata: user email, tool, arguments, SAP URL (without secrets), HTTP status, latency, token sizes and the hash chain. These records are append-only.
• A short-lived in-memory cache of tool results, keyed per user and groups. It lasts 15 seconds for stock and shortages, 30–60 seconds for orders, and 1 hour for BOMs, and it is cleared on restart.
• Derived usage metrics (call counts, sizes) used for the savings dashboard.
• No AI chats. QSAP never sees the user's conversation, only the tool calls the assistant makes.

Is this allowed under SAP's API policy?

QSAP uses only SAP's released, documented APIs through standard communication arrangements, which is SAP's intended integration path. Read our stance in SAP API policy and third-party MCP servers (on our blog, coming soon). Confirm your own position with your SAP account team.

Do we need extra SAP licences?

QSAP works within your existing user licences and is read-only. Licensing questions, including indirect or digital access, are between you and SAP. Confirm them with your SAP account team. Future changes follow the "AI prepares, user posts in SAP" pattern (section 8): the user posts the document in SAP themselves, as normal user activity.

Will QSAP ever write to SAP?

Not directly. Changes are prepared by the AI and posted by a person in the standard SAP app (section 8). No write scenarios need enabling.

What happens if QSAP is compromised?

In technical mode, the blast radius is read access to the four APIs in the arrangements. In per-user mode, an attacker would also need a valid user session, and SAP still applies each user's roles. Every call is audited in a tamper-evident chain. Rotating the communication user password cuts access immediately.

Is QSAP SAP-endorsed?

No. See the footnote.

SAP, S/4HANA, SAP BTP, SAP Fiori and other SAP products mentioned are trademarks or registered trademarks of SAP SE. QSAP is an independent product by Quantana and is not affiliated with or endorsed by SAP SE. Microsoft Entra ID is a trademark of Microsoft; Okta is a trademark of Okta, Inc. SAP documentation is cited as it stood in October 2026 (S/4HANA Cloud Public Edition 2608). Check the links against your release.