Skip to main content
SAP Pentest Playbook
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage
  2. /
  3. SAP Business Technology Platform
  4. /
  5. Known Attack Vectors
  6. /
  7. BTP Identity & Trust Misconfiguration
Edit page

BTP Identity & Trust Misconfiguration

Description

BTP’s authentication story looks solid on paper - a corporate IdP wired into each subaccount, MFA, role collections gating access. In practice the trust model is softer than customers assume, because several of its controls default open and its matching logic is deliberately loose. This page collects the trust-configuration weaknesses that let a tester authenticate where they shouldn’t, pick a weaker authentication path, or collide with a privileged identity. It complements Identity Persistence (rogue trust configs, Universal-ID MFA, audit retention) and XSUAA Token Abuse (token-level attacks and role-collection over-assignment).

Each subaccount trusts one or more Identity Providers (the default SAP ID Service plus any corporate IdP via SAP Cloud Identity Services / IAS), and maps IdP groups/attributes to role collections. The weaknesses below live in how those trusts are configured and evaluated, not in the crypto.

Risk

An attacker who can authenticate as any valid identity - or steer authentication through a weaker IdP, or land on a shadow user, or collide with a privileged user’s identity - gets a foothold that bypasses the authentication strength the organization believes it enforces (notably MFA). Combined with loose role-collection mapping, that foothold can carry more privilege than intended. The impact is unauthorized access to BTP applications and, through destinations and Cloud Connector, to the on-prem systems they bridge to.

Options

  • Default SAP ID Service IdP left available for logon + shadow-user creation: the default IdP (sap.default, SAP ID Service) cannot be deleted, only configured, and stays a valid logon path unless the admin unchecks “Available for User Logon.” If “Create Shadow Users During Logon” is enabled for the SAP ID Service, any user with an SAP account can log on to the application - they only need the link, and a shadow user is provisioned on first login. Test: after enumerating the app-router URL, attempt logon via the default IdP with any valid S-user / SAP Universal ID. Authorization still depends on a role-collection assignment, but an authenticated, self-provisioned foothold is the result.
  • Client-selectable IdP (weakest-link authentication): when a subaccount trusts more than one IdP, the client can steer authentication to a chosen one. Via SAP Cloud Identity Services this is the /oauth2/authorize endpoint’s idp query parameter - the technical name(s) of the corporate IdP(s), comma-separated; the special value local overrides conditional authentication and authenticates against IAS itself. login_hint pre-fills the user identifier. If any trusted IdP is weaker (no MFA, a test IdP, a self-registration-enabled tenant), an attacker selects it and sidesteps the strong default. Test: enumerate configured IdP technical names and try ...&idp=<name> / ...&idp=local. (This is the current Cloud Foundry equivalent of the legacy Neo saml2idp= parameter.)
  • Cross-IdP identity collision: with multiple trusted IdPs, if the same username/email exists in two of them, role assignment can bind to the wrong identity - identities must be unique across all trusted IdPs or a privileged user’s roles can attach to a colliding lower-trust identity. Test where you can register/control a colliding identity (same email) in a lower-trust IdP - e.g. a partner IAS tenant with self-registration - matching a privileged user in the corporate IdP.
  • Loose role-collection mapping (“all users” → admin): role-collection mappings bind an IdP group/attribute value to a role collection, and the value match is case-insensitive and does not have to match the IdP value exactly. A broad or mistranslated group value (e.g. a localized “all users”) can grant a privileged collection - for example, the Subaccount Administrator collection mapped to every member of a broad group. Test (grey-box, needs cockpit read or influence over IdP group/attribute values): export the mappings and flag any broad value or admin collection mapped to a wide group; where you can join a broadly-named group or control a matching attribute, pull the collection. See also role-collection over-assignment in XSUAA Token Abuse.
  • IAS proxy - corporate MFA skippable: when IAS proxies a corporate IdP, “Forward All SSO Requests to Corporate IdP” is set to No by default, and Identity Federation decides whether user attributes come from the corporate assertion or from the IAS local user store. Left at No with a local IAS password for a user, that user (or an attacker holding the local password) can authenticate at IAS without ever hitting corporate MFA / conditional access. Test: attempt an IAS-local password logon for a user the organization believes is corporate-federated.
  • IAS “System” administrator secret = user-store control: IAS supports System administrator users that authenticate via client credentials to the SCIM REST API and can hold Manage Users, Manage Groups, Manage Corporate Identity Providers, and Manage Tenant Configuration (SAP defaults most of these on at creation). A leaked System-admin secret (hardcoded in an iFlow, in a service key, in a repo) lets an attacker enumerate/create users, create groups (feeding the mapping abuse above), or add a rogue corporate IdP to re-point federation. Test: locate any IAS System-admin credential in reachable config and check its granted roles.

Mitigation

  • On the default SAP ID Service IdP, uncheck “Available for User Logon” once the corporate/IAS IdP is verified, and never enable “Create Shadow Users During Logon” for the SAP ID Service.
  • Minimize the number of trusted IdPs per subaccount and enforce equivalent authentication strength (uniform MFA) across all of them; remove test/dev IdPs from productive subaccounts so idp-parameter selection can’t reach a weaker path.
  • Keep user namespaces disjoint across IdPs; use origin-key-qualified role assignments; disable self-registration on any IdP that shares a namespace with a privileged one.
  • Map only specific, immutable group IDs (GUIDs), never broad display names; never map high-privilege collections (Subaccount Administrator, Cloud Connector Admin) to broad groups.
  • Set “Forward All SSO Requests to Corporate IdP” = Yes; disable local-password authentication for federated users; enforce MFA at IAS as a backstop.
  • Minimize IAS System administrator users, give each only the specific role it needs, and rotate/scope their SCIM secrets.

Detection and Monitoring

  • Trust Management review per subaccount: is sap.default still available for logon? Is shadow-user creation on for it? How many application IdPs are trusted, and do all enforce MFA?
  • BTP / IAS audit logs: alert on shadow-user creation (origin sap.default), on authentications whose IdP origin ≠ the intended default, and - via IAS Audit & Change logs - on SCIM user/group creation and any corporate-IdP change. Ship IAS logs to a SIEM.
  • Role-collection mapping baseline: periodically export mappings and diff against a known-good baseline; flag broad values (“all”, “users”, “everyone”) and any admin-collection target.
  • Note the 90-day BTP Audit Log retention caveat governing how long this evidence survives.

References