SAML SSO user context lost when accessing cash management forms through Fiori launchpad

ERP SAP S/4HANA
, , , , , , , ,
1

We’re experiencing authorization failures in our SAP S/4HANA 1909 cash management module when users access Fiori apps through SAML 2.0 SSO. The SAML authentication succeeds at the launchpad level, but when users navigate to cash management forms (specifically Bank Account Management and Cash Position apps), they encounter “User not authorized” errors.

The SAML assertion attributes aren’t properly propagating through the OData service layer to the backend. Here’s what we see in the trace:


SAML Assertion: Valid, User=JSMITH
OData Request: /sap/opu/odata/sap/FAP_BANK_ACCOUNT_SRV
Backend Authorization Check: User context empty
Result: HTTP 403 Forbidden

The issue seems related to SAML attribute mapping and token propagation between Fiori frontend and backend systems. Users can access other Fiori apps successfully, but cash management specifically fails. We’ve verified PFCG roles are assigned correctly.

Has anyone dealt with SAML attribute mapping issues affecting OData authorization context in Fiori-backend integration scenarios?

system 2

I’ve resolved this exact issue multiple times with cash management Fiori apps. The problem involves all four areas you mentioned: SAML attribute mapping, OData authorization context, token propagation, and Fiori-backend integration. Here’s the comprehensive solution:

1. SAML Attribute Mapping Configuration: In transaction SAML2, verify your attribute mapping for the cash management IdP:


Attribute Statement:
  NameID Format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
  Attribute Mapping:
    email -> SU01 Email
    uid -> User ID (case-sensitive)

Critical: The uid attribute must match SAP user ID exactly, including case. Cash management OData services perform case-sensitive authorization checks.

2. OData Authorization Context Setup: Configure the OData service in /IWFND/MAINT_SERVICE:

  • Service: FAP_BANK_ACCOUNT_SRV
  • System Alias: LOCAL
  • Authentication Method: “SAP Assertion Ticket” (not Technical User)
  • Enable “Principal Propagation”

This ensures the SAML user context flows through to backend authorization checks.

3. Token Propagation Configuration: Enable trusted system relationships for token propagation:

In transaction SMT1, add your Fiori frontend system:


Trusted System: <Frontend_SID>
Trust Type: RFC and HTTP

In transaction STRUST, import SAML IdP certificate to SSL Server Standard PSE and add to ACL list.

Verify Web Dispatcher parameter:


icm/trusted_reverse_proxy_0 = SUBJECT="CN=webdispatcher.company.com", ISSUER="CN=CompanyCA"

4. Fiori-Backend Integration Authentication Flow: Configure SICF service nodes for cash management apps:

Path: /sap/bc/ui5_ui5/sap/fap_bank_account

  • Logon Procedure: Standard
  • Security Requirements: SSL, Logon Data Required
  • Authentication: SAP Logon Ticket + User ID/Password

Path: /sap/opu/odata/sap/FAP_BANK_ACCOUNT_SRV

  • Enable “Principal Propagation”
  • Authentication Method: Ticket or User/Password

5. Authorization Object Assignment: Even with correct token propagation, users need specific authorizations. Assign via PFCG role:


Authorization Objects:
F_BANK_BUK: Activity 03 (Display), 02 (Change)
F_BNKA_INT: Bank Country *, Bank Key *
S_SERVICE: Service Type OData, Service Name FAP_BANK_ACCOUNT_SRV
S_RFC: Function Group SUGU, Activity 16

6. Validation and Testing: Test the complete authentication flow:

a) Enable SAML trace: Transaction SAML2 → Trace Level 3

b) User logs into Fiori launchpad → Check SAML assertion received

c) User opens cash management app → Verify OData call includes user context

d) Check backend authorization: Transaction ST01, filter by user ID

Look for successful authorization check entries for F_BANK_BUK and S_SERVICE.

7. Common Pitfalls to Avoid:

  • Using technical user for OData service (loses user context)
  • Missing trusted system configuration (breaks token propagation)
  • Expired or untrusted IdP certificate (SAML validation fails)
  • Case mismatch between SAML uid and SAP user ID (authorization fails)
  • Missing S_SERVICE authorization object (OData access denied)

Implementation Results: After applying this configuration, SAML user context propagates correctly through the entire stack: IdP → Web Dispatcher → Gateway → OData Service → Backend Authorization. Users access cash management Fiori apps seamlessly with their SAML credentials, and authorization checks execute in their user context rather than a generic technical user.

The key is ensuring consistent configuration across all layers - SAML attribute mapping must align with OData authorization context requirements, token propagation must be enabled at every hop, and Fiori-backend integration must preserve user identity throughout the authentication flow.

This draft is based on general SAP S/4HANA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

This is a classic token propagation issue. SAML assertions authenticate you at the Web Dispatcher/Gateway level, but the OData service needs to propagate that user context to the backend ABAP system.

Check your SAP Gateway OData service registration in transaction /IWFND/MAINT_SERVICE. The service needs to be configured with “SAP Logon Ticket” or “User ID/Password” as the authentication method for backend calls, not “Technical User”. If it’s using a technical user, your SAML user context gets lost.

5

Also verify your SAML attribute mapping configuration in transaction SAML2. You need to map SAML assertion attributes to SAP user attributes correctly:


SAML Attribute: NameID
SAP User Attribute: USER_ID
Mapping Rule: Direct mapping

If the mapping is incorrect or missing, the backend can’t identify the user even though SAML authentication succeeded at the frontend. This would explain why authorization checks fail - the system doesn’t know who to authorize.

7

I’ve seen this specifically with cash management OData services. The FAP_BANK_ACCOUNT_SRV service has stricter authorization requirements than other Fiori services. Even if user context propagates correctly, you need specific authorization objects:

  • F_BANK_BUK (Bank Account Authorization)
  • F_BNKA_INT (Bank Master Data)
  • S_SERVICE (Service Authorization for OData)

Run transaction SU53 immediately after the error occurs to see which authorization object is actually failing. My bet is the user context IS propagating, but specific authorizations are missing.

8

Have you checked whether your Fiori launchpad is configured for principal propagation? In transaction SICF, check the service /sap/bc/ui5_ui5/sap/fap_bank_account and verify that “Security Requirements” includes “Logon Data must be available”.

Also, review your SAP Web Dispatcher configuration. The profile parameter icm/trusted_reverse_proxy_0 must include your Web Dispatcher host, otherwise the backend won’t trust forwarded credentials.

9

The trace you posted shows “User context empty” at the backend, which confirms token propagation failure. This typically happens when the SAML ticket isn’t converted to an SAP logon ticket properly. Check transaction STRUST - your SAML IdP certificate must be imported into the SSL Server Standard PSE, and the certificate must be valid (not expired).