SAP Fiori Authentication and SSO Basics: A Practical Trust Setup Guide

SAP Fiori authentication connects the browser, the Fiori launchpad, the ABAP front-end server, and an identity provider. A successful login proves who the user is; authorization then determines which applications, catalogs, spaces, pages, and backend actions the user can access.

This guide focuses on the operational sequence for a trust setup and the evidence to collect when single sign-on fails. For the broader user experience and application architecture, see SAP Fiori overview.

01Understand the Fiori SSO request path

A typical browser flow starts when a user opens the Fiori launchpad URL. The front-end server redirects the browser to the configured identity provider. After the user authenticates, the identity provider returns a signed assertion or token to the front-end server. The server validates the response, maps the external identity to an SAP user, creates the authenticated session, and serves the launchpad.

The main trust relationships are between the front-end server and identity provider and between the identity provider and user directory. TLS protects the network connections, while signing certificates protect the integrity of the authentication response.

Authentication does not assign business access. The mapped SAP user still needs the correct PFCG roles and launchpad content. Use SAP Fiori role and catalog assignment when the user can sign in but cannot see an application.

02Prepare the trust configuration

Collect the configuration values before changing either side of the trust:

• Fiori launchpad URL and the externally visible host name
• Front-end server host name and HTTPS port
• Identity provider issuer or entity ID
• Service provider entity ID
• Assertion consumer service URL
• Identity provider login URL
• Signing certificate and its expiration date
• User attribute used for mapping, such as an email address or corporate user ID
• Clock source and time zone on the participating systems

The public names used in the metadata and browser URL must describe the same reachable service. A reverse proxy or load balancer can change the externally visible host, protocol, or port, so include those values in the design rather than using only the internal application-server name.

Establish trust by exchanging metadata or by entering the required endpoints and certificate values on both sides. Validate the certificate chain, certificate purpose, issuer, and validity period. Record the certificate owner and renewal process before enabling production traffic.

For the surrounding launchpad administration sequence, see SAP Fiori Launchpad admin setup.

03Configure identity mapping

The identity provider must send an attribute that the front-end server can map deterministically to an SAP user. Common choices include a corporate user ID, email address, or a directory attribute maintained specifically for SAP access.

Choose one canonical value and use the same normalization rules everywhere. Decide how to handle case, spaces, domain suffixes, renamed users, and duplicate values. A successful identity-provider login with no matching SAP user produces an access failure after authentication, so test mapping with a real non-privileged user before testing administrative accounts.

Keep authentication attributes separate from authorization data. Groups or claims can support role-assignment processes, but the launchpad still depends on the SAP user and its assigned roles. Review the user and role design with SAP login and access SSO concept when the same identity is used across several SAP entry points.

04Validate the launchpad session

Test the complete browser path in a private browsing session after each major change. This avoids stale cookies and makes the redirect sequence easier to inspect.

1. Open the exact HTTPS launchpad URL.
2. Confirm that the browser redirects to the expected identity provider.
3. Complete authentication with a test user.
4. Confirm that the browser returns to the expected assertion consumer service URL.
5. Confirm that the launchpad creates a session.
6. Open an application assigned to the test user.
7. Execute a representative read and write action when the test scope permits it.
8. Sign out and verify that a new browser session requires the intended login behavior.

The test should cover both a user with valid launchpad content and a user whose authentication succeeds but whose application access is intentionally limited. This separates login success from authorization and application-startup behavior.

05Troubleshoot common SSO failures

Start with the point at which the flow stops:

Capture timestamps in UTC, the affected user ID, the launchpad host, the identity-provider event ID, and the browser correlation information. Avoid placing passwords, private keys, or complete authentication assertions in tickets or shared logs.

06Manage certificates and clock alignment

Certificate maintenance is part of normal SSO operations. Track the signing certificate expiration date, the certificate currently trusted by the front-end server, and the certificate published by the identity provider. Plan overlap where the trust configuration supports more than one valid certificate during renewal.

Check the system clocks on the browser-facing infrastructure, front-end server, identity provider, and directory services. SAML assertions contain time conditions, so a material clock difference can cause a valid-looking response to be rejected. Use a consistent time source and verify the result after daylight-saving or infrastructure changes.

After a certificate or endpoint change, test a new private browser session, an existing browser session, and the sign-out flow. Keep a rollback record containing the previous metadata and certificate fingerprints.

07Separate Fiori authentication from SAP GUI access

SAP GUI and SAP Fiori can use related users and identity sources while presenting different authentication paths. A transaction launched through SAP GUI does not prove that the browser-facing Fiori trust configuration is correct, and a successful Fiori login does not prove that every SAP GUI connection is configured identically.

Use the entry point that matches the work being tested. For Fiori, inspect the browser redirect, identity-provider event, front-end session, and launchpad content. For a GUI transaction, inspect the SAP GUI connection and its own login path. This distinction prevents a working GUI login from masking a Fiori trust or cookie problem.

08Use a controlled change sequence

Apply SSO changes in a non-production system first, then promote the tested metadata, certificates, endpoint values, and mapping rules through the normal change process.

A practical sequence is:

1. Export the current trust metadata and record certificate fingerprints.
2. Confirm the externally visible Fiori URL and proxy behavior.
3. Configure or update the identity-provider trust.
4. Configure the corresponding front-end trust and user mapping.
5. Test authentication with a restricted test user.
6. Test launchpad content and one representative application.
7. Test sign-out, session expiry, and a second user mapping.
8. Record evidence and the rollback procedure.

Keep emergency access available through a controlled administrative path while changing SSO. Protect that path with strong credentials, restricted network access, and monitoring. Review the launchpad configuration after upgrades, proxy changes, identity-provider changes, and certificate renewal.