SSO Setup for SAP Hybrid Landscapes: How to Manage Identity Across Cloud and On-Prem Systems

Key Takeaway: Identity becomes more complex as SAP systems move into cloud and RISE environments, especially when authentication changes late in the project. A clear SSO strategy ensures users keep the same secure login behavior across SAP GUI, Fiori, and cloud-hosted apps.

SAP SSO for Hybrid Environments

SAP users expect access to work the moment they open their laptops. But identity doesn’t automatically keep pace when an SAP landscape becomes more complex — on-prem systems remain in place while new cloud services and SAP RISE come online. Suddenly the login experience becomes inconsistent. One password works here, another works there. A new authentication prompt appears that no one expected.

Password resets quickly pile up when users manage separate credentials for SAP GUI, Fiori, and cloud services. Gartner Peer Community polling shows many organizations see 20–30% of help desk requests tied to passwords or Multi-Factor Authentication (MFA). 

SSO brings those identities back under one secure login that works everywhere users engage SAP.

In this post, we break down:

• The biggest SSO challenges in SAP hybrid environments
• How SAP GUI and Fiori authentication differ — and why that matters
• Where identities break during cloud or SAP RISE transitions
• A practical checklist for rolling out hybrid SAP SSO
• Troubleshooting patterns that resolve most login failures
• The emerging shift toward SAP BTP Identity Services and OIDC

These recommendations come from hands-on experience helping global SAP customers deliver consistent access through major landscape changes.

Hybrid SAP Access Creates SSO Challenges

SAP landscapes rarely transform all at once. New SAP cloud services and SAP RISE deployments run alongside long-standing on-prem systems. Each environment comes with its own access path, identity owners, and infrastructure constraints.

When SSO is treated as a late-stage task, gaps show up exactly when the project team expects to start testing.

Example: A global manufacturer completes its SAP S/4HANA transition and opens quality testing to users on Monday. SAP GUI works, but Fiori prompts every user for a different password. IT scrambles to diagnose whether the problem lives in Active Directory, the SAP system copy, or Azure AD trust — and testing loses a week.

That situation stems from the same root causes we see repeatedly:

Challenge in hybrid SSO	What it creates
Multiple teams own pieces of authentication	Delays while roles and responsibilities are sorted out
No OS access on SAP RISE	Limited visibility for Kerberos troubleshooting
New identity systems (Azure AD, BTP IAS)	Skills gaps and slow testing cycles
Hostname + certificate changes during refreshes	SSO breaks post-copy if trust isn’t fully updated

The technical components are manageable. The coordination is the hard part. SSO planning must start early enough that identity is ready before new environments go live.

 

How SAP GUI and Browser Access Require Different SSO Paths

SAP access isn’t one thing anymore. Some users launch SAP GUI from a domain-joined laptop. Others open Fiori apps in a browser from any device. Each access path expects authentication to work differently — which is why hybrid SSO planning cannot rely on a single method.

Kerberos SSO for SAP GUI in Hybrid Landscapes

Kerberos ties SAP GUI access directly to the user’s Windows login. When authentication succeeds at the desktop level, users connect to SAP GUI automatically with no password prompt.

This method remains widely used because:

• It reduces password reset volume for SAP GUI users
• No new login screens or browser redirects appear
• Performance remains unchanged

However, Kerberos assumes:

• The workstation is domain-joined
• Active Directory can validate the user in real time
• SAP trusts the service account that represents the system

That trust relationship must be established and tested early. When SAP systems move to the cloud — especially SAP RISE, where OS-level access is limited — verifying Kerberos behavior becomes more complicated.

Kerberos stays extremely effective for SAP GUI, but it cannot cover every access scenario in a hybrid architecture.

SAML 2.0 SSO for SAP Fiori and Web Applications

Modern SAP workflows increasingly rely on browser-based access. Fiori tiles, Launchpad apps, and cloud extensions all run outside the SAP GUI — and many users launch them from personal devices or remote networks.

Where SAML 2.0 Fits

SAML 2.0 fills that gap by shifting authentication to an identity provider, most commonly:

• Azure AD
• A corporate enterprise IdP
• SAP BTP Identity Services in cloud-first environments

The SAP system provides its identity metadata, the IdP provides its metadata in return, and the two exchange trust certificates so a browser session can be authenticated securely.

Why SAP Teams Choose SAML

This approach:

• Supports multi-factor authentication and conditional access policies
• Enables unified identity for both cloud and on-prem SAP apps
• Avoids domain dependence (works from anywhere)

As SAP systems expand into cloud platforms and RISE environments, SAML provides the common identity foundation that keeps browser access consistent — and Kerberos continues to handle SAP GUI authentication for users on domain-joined devices.

Important takeaway for SAP Basis teams

SAP GUI and browser authentication aren’t interchangeable — every hybrid SSO design must support both, and testing must validate how they work together.

Step-by-Step: SSO Setup for SAP Hybrid Landscapes

Hybrid SSO succeeds when authentication is treated as its own mini-project. The rollout follows a predictable sequence that keeps SAP, identity, and cloud teams aligned.

1. Assess authentication requirements

Teams validate:

• Which SAP systems require SSO (SAP GUI vs. Fiori vs. cloud extensions)
• Where users will connect from (corporate devices vs. remote)
• Which identity providers already exist (Active Directory, Azure AD)

Early discovery prevents surprises later — especially during cloud or SAP RISE transitions.

2. Build trust between SAP and the identity source

The SAP Basis team enables secure identity in the SAP system. In parallel, IT configures a service account and identity metadata exchange in Active Directory or Azure AD. This is where the trust relationships begin to take shape.

3. Map users correctly

Validating identity for SAP GUI and Fiori requires different fields in SAP.

• Kerberos relies on a secure identity string associated with the AD account
• SAML 2.0 uses user attributes matched with SAP

Testing with real users ensures name formats and domain structures match expectations.

4. Prepare the endpoints

To make SSO automatic, client devices must get the correct settings:

• SAP GUI connections distributed centrally
• Kerberos libraries or Secure Login Client installed (if needed)
• Browser configuration documented for testing teams

SAP authentication feels effortless only when the client environment is updated consistently.

5. Test authentication flows early

Successful hybrid login testing confirms:

• SAP GUI accepts the Kerberos ticket
• The browser is redirected correctly to Azure AD or another IdP
• User attributes match in both directions

The first successful sign-in is the hardest part — the configuration becomes much steadier after that point.

6. Plan for refresh and change events

System copies, hostname changes, or new URLs will break SSO if identity metadata and certificates aren’t kept current.

A short checklist in cutover plans protects go-lives from Monday-morning login failures.

Cloud Adoption Changes Identity Requirements

Hybrid SAP landscapes don’t stay static. As systems move into public cloud or SAP RISE environments, authentication setups that worked for years need updates to keep working reliably.

Public Cloud: Mostly Familiar, If the Domain Remains Reachable

Organizations hosting SAP on Azure, AWS, or Google Cloud can often continue with their existing identity model:

• Kerberos still supports SAP GUI on domain-joined devices
• SAML 2.0 still handles browser-based access

Azure AD frequently becomes the single point of identity validation. This consistency reduces the complexity of hybrid authentication, as long as Active Directory remains authoritative for SAP users.

SAP RISE Introduces New Boundaries

In SAP RISE environments, infrastructure is managed by SAP — not the customer. That limits visibility and control at the OS level, which affects how Kerberos can be validated and tested.

Many organizations keep Kerberos for SAP GUI on on-prem systems while shifting RISE authentication to:

• X.509 certificate-based SSO
• SAP BTP Identity Services for browser and cloud access

Those technologies improve trust across managed environments and reduce support friction when new URLs, hostnames, or proxy layers appear.

OIDC Is Starting to Appear in Customer Plans

Some organizations are beginning to adopt OpenID Connect (OIDC) for SAP Fiori — especially where cloud-native identity modernization is underway. SAML 2.0 still dominates today, but OIDC is becoming a realistic planning item for platform teams who expect more transformation ahead.

Errors SAP Basis Teams Face During Hybrid SSO Rollouts

SSO failures rarely appear when systems are quiet. Problems emerge during testing cycles or right after a system refresh — the moments when access must be predictable. The same login failures tend to show up across hybrid SAP projects, and each one points to a familiar cause.

Generic browser errors during Fiori login
→ The browser isn’t receiving a valid SAML assertion
→ Usually caused by outdated metadata or certificate trust

SAP GUI not accepting Kerberos authentication
→ The SAP server cannot validate the workstation’s identity
→ Often tied to incorrect service account mapping or missing domain settings

SSO works only on certain networks or VPNs
→ Identity routing isn’t consistent in hybrid environments
→ User authentication depends on where the ticket originates

Authentication fails after system refreshes
→ Component names, hostnames, or entity IDs changed without updating trust
→ A short checklist in refresh/cutover plans prevents repeat outages

These patterns are predictable after you’ve implemented hybrid SSO a few times. Success comes from catching configuration drift early — especially when SAP systems move between environments.

Recommended Hybrid SSO Architecture Patterns

Every SAP landscape evolves differently, but hybrid SSO designs tend to fall into recognizable patterns. The right approach depends on where identity is mastered and where SAP systems are running. The most effective designs minimize the number of trust relationships teams must maintain through upgrades, refreshes, and cloud transitions.

Common hybrid SSO architectures for SAP

Hybrid Landscape Type	SAP GUI Authentication	Fiori / Browser Authentication	Key Notes
On-prem SAP + Azure-hosted applications	Kerberos	SAML 2.0 using Azure AD	Domain trust remains consistent
SAP RISE mixed with on-prem	Kerberos for remaining on-prem systems. For RISE systems, X.509 certificate based SSO utilizing BTP services.	SAML 2.0 or OIDC based SSO utilizing BTP services.	OS-level restrictions influence design
Multi-cloud (Azure + AWS + GCP)	Kerberos where domain is reachable	SAML 2.0 using Azure AD	Unified IdP prevents identity sprawl

Why this table matters for rollout planning

• Reduces friction across different infrastructure providers
• Keeps one identity source authoritative
• Makes refreshes and cutovers safer
• Prevents authentication from blocking project timelines

Small design decisions early — such as naming, user attribute format, and hostname conventions — save significant troubleshooting later on.

How Expert Support Avoids Delays and User Impact

Hybrid SSO touches every SAP user, so authentication must be stable before training and go-live. We coordinate between SAP Basis, cloud identity, and Active Directory stakeholders — validating trust and confirming login behavior in all environments.

We also support refresh and cutover events with repeatable checks that keep identity handling consistent.

As more SAP systems shift to public cloud and SAP RISE, identity becomes the thread connecting legacy access to the cloud experience. We help SAP teams deliver a predictable login journey wherever users access SAP.

oXya supports SAP teams worldwide in delivering SSO where it’s needed — and keeping it reliable as landscape complexity grows. Contact us today to discuss your needs. 

FAQ: SSO Setup for SAP Hybrid Landscapes

Can Kerberos still be used when part of the environment moves to the cloud?

Yes — provided domain-joined devices can still reach Active Directory. Kerberos remains the preferred path for SAP GUI.

How does SAP RISE change authentication decisions?

SAP RISE limits OS access, so many organizations use X.509 or SAML through SAP BTP Identity Services for browser access.

What breaks SSO after refreshes?

Hostname and metadata changes must be updated in trust configurations after every system copy.

Is OIDC required yet for SAP?

No — SAML dominates current deployment patterns. OIDC is emerging for cloud-native identity modernization.

Who maintains SSO once it’s live?

SAP Basis owns trust inside SAP systems, and IT owns the identity provider. Monitoring requires occasional checks, not full-time support.

 

Read More

• Tips and Strategies for a Successful SAP S/4HANA Implementation
• GRC in SAP: Why Your Compliance Framework May Be Missing the Mark
• 2025 SAP Cloud Computing Trends: 10 Key Insights for Enterprise Leaders