The Ultimate Showdown: SAML 2.0 vs OpenID Connect in SAP Web Applications

Introduction

Welcome, tech enthusiasts and SAP security pros! Today, we're diving into the thrilling world of authentication protocols, pitting the seasoned SAML 2.0 against the modern challenger, OpenID Connect (OIDC). Both have their strengths and weaknesses, especially in the realm of SAP web applications and ICF services.

Two of the main authentication protocols in the cloud world are OpenID Connect (OIDC 1.0) and Security Access Markup Language (SAML 2.0). Key aspects of both are asserting a user's identity, providing standardized mechanisms and protocols, different authentication flows, and finally trust. Both provide a cross-domain and cross-vendor single sign-on (SSO) standard.

In this article, we'll break down how to implement OIDC-based SSO for ICF services like the Fiori Launchpad and the benefits you’ll reap from it.

Background

I debated for a long time whether to write this article, but ultimately, I think it's worth it. Many of you in this field may have already encountered OpenID Connect, especially as it becomes the de facto standard with SAP BTP. As a seasoned SAML veteran, you might wonder why not use OIDC as the SSO method for accessing ICF services. What are the pros and cons? Is it worth it?

Part of the motivation for this article is the usual lack of proper documentation. While there are fragments here and there, having everything collected in one place is typically more helpful.

Update 2024.06.20: A huge shoutout to Michael Engler & Tobias Lejczyk for their valuable inputs and corrections, which have been incorporated - Thanks ??

Even if you are familiar with SAML 2.0 you may have noticed, OIDC works differently. It supports different authentication flows and involved entities are different. In short, to understand and implement OpenID Connect, I recommend trying to first understand the underlying OAuth 2.0 framework as OIDC operates on top of it. That’s why I’ll also integrate some insights from our older blogs on connecting SAP IAS as a proxy to Azure AD using OpenID Connect.

It's crucial to familiarize yourself with the standards to build a foundational understanding and get to know the terminology and components, which are somewhat different from SAML.

You should start getting to know what a JSON Web Token is, dive into the OAuth2 framework as the basis for the OAuth 2.0 extension OpenID Connect, and internalize the OIDC Core Specification. Yes, this might involve reading some dry RFCs, which isn't fun, but it's sometimes necessary to gain insights.

Authentication Concepts

Authentication is a cornerstone of information security, ensuring the confidentiality, integrity, and availability of information flow.

On the ABAP platform (including SAP S/4HANA), authentication involves verifying the identity of a person or system before granting access the systems. You can use various client front-ends to access ABAP platform backend systems. The authentication mechanisms on the ABAP platform are specific to the communication channel used for data access. According to the system's client-server architecture, the authentication process is negotiated between the client front-end and the backend system. Here’s the scoop on available authentication mechanisms for interactive user logins with HTTP-based front-end clients like Web Dynpro or UI5 Launchpad.

Basic Functionality in a Nutshell

OpenID Connect for AS ABAP operates as a sophisticated, browser-based authentication framework. It empowers users to authenticate for the use of ICF services seamlessly. Acting as an OpenID Relying Party (RP), ABAP delegates user authentication to a distinct system known as the OpenID Provider (OP). In this configuration, SAP Cloud Identity Services - Identity Authentication fulfills the role of the OP.

The outcome of the end-user authentication at the OpenID Provider is communicated back to the ABAP system through an OpenID Connect ID token. This ID token adheres to the JSON Web Token (JWT) standard (RFC 7519), consisting of a digitally signed JSON structure containing various claims in its payload.

This article centers on the interactive code flow of OIDC and its integration within an S/4HANA system. Here, the SAP Cloud Identity Authentication Service (IAS) functions as the OP, and the SAP system serves as the RP.

Regardless of whether your login is delegated to any Identity Provider with IAS acting as a proxy (connected via SAML or OIDC), the initial process remains similar.

For deeper understanding, I recommend reading the mentioned blog and this one to establish a good grasp of Identity Federation and the role of the IdP to avoid unpleasant surprises.

Entities in OIDC Authentication for ABAP

Here are the key entities involved in the OIDC authentication process within the ABAP environment:

User (via Browser): The user, usually accessing through a browser, interacts with the ABAP system in the role of the OIDC Relying Party (RP), specifically with the ICF service they want to access.

OpenID Provider (OP): Facilitates OIDC authentication for the RP ABAP. The main tasks of the OpenID Provider include:

• Authenticating the user through various mechanisms
• Logging authentication details, including the authenticated subject and the time of authentication.
• Issuing a standardized ID token to the relying party, containing authentication details and a set of standardized user profile information.

Relying Party (RP): The RP ABAP requires authentication to identify the requesting user. It relies on the OpenID Provider (OP) for user authentication and then uses the ID token provided by the OP.

So, the user kicks things off in their browser, the OP handles authentication, and the RP ABAP makes use of the ID token. Simple and efficient!

Endpoints for OpenID Provider in ABAP Implementation

OpenID Connect for AS ABAP relies on HTTP as its transport protocol. Therefore, both the OP and the RP offer a set of necessary HTTP endpoints. All communication with these endpoints must use TLS.

Authorization Endpoint: Handles user authentication. It receives an authentication request via an HTTP redirect from the user's browser, authenticates the user, and responds with an authentication response message containing an authorization code. This code is sent back to the Relying Party's (RP) redirect endpoint.

Token Endpoint: The token endpoint of the OpenID Provider is responsible for issuing access and ID tokens. It receives a token request from the Relying Party, authenticates the RP, and responds with a token response message containing the requested token.

Trust Relationship: An OpenID Provider requires a statically configured relationship with each RP. The client configuration endpoint allows an RP to view and modify its information at the OpenID Provider.

SSO Request Flow: OpenID Connect defines several standardized flows for interactions and protocol messages exchanged between involved parties. The main ones are the Authorization Code Flow, Implicit Flow, and Hybrid Flow.

The OIDC implementation in ABAP supports only the Authorization Code Flow, the interactive flow with user consent.

SLO with OIDC: OIDC can be used to implement a single logout mechanism for the ABAP platform. Actually, the latest SAP ABAP implementation of OIDC already has support for Single Logout, both via the Front-Channel as well as via Back-Channel. More information can be found here.

OpenID Connect Support for AS ABAP

OIDC authentication is available in the latest ABAP releases for ICF services, WebSocket RFC, and JCo. However, certain release and SP prerequisites need to be considered. Details on the supported OpenID Connect features can be found in SAP Note 3111813.

Initial support for OIDC authentication commenced in SAP BASIS 7.56 SP1 as described in SAP Note 3105025. Some advanced features, like extended trace analysis via TCode SOIDC_ANALYZER, might not be supported across all systems yet.

Nevertheless, SECTRACE can be used as an alternative. By setting the Redirect Endpoint as the trace target instead of the ICF service, you can inspect details about the ID token, including the sub claim, in the trace.

Tips for OIDC Configuration in SAP ABAP

To improve your experience with OIDC configuration in SAP ABAP, here are some practical tips that might be useful:

1. Use the F1 Help in Transaction SOIDC: Start by utilizing the F1 help in transaction SOIDC. Select your OIDC configuration in the list, click on an input field, and press F1 to access the help text, which is quite explanatory. This F1 help is available for every configuration field in transaction SOIDC.
2. Info Button in SOIDC: Check the Info Button text in transaction SOIDC for a general overview of OIDC configuration.
3. OIDC Troubleshooting Note: Typical problems with OIDC authentication are covered in the OIDC Troubleshooting Note SAP Note 3111813.
4. Official Documentation: Refer to the product's help documentation on help.sap.com for detailed instructions on configuring OIDC.
5. Proxies: In ABAP OIDC, because it involves direct communication between RP (Relying Party) and OP (OpenID Provider), unlike SAML2, you might also deal with forward proxies. As mentioned needs HTTP connections to the OpenID Provider for metadata and JWKS download, and for calling the Token Endpoint during interactive OIDC. If your ABAP system needs an HTTP proxy for outgoing connections, you can configure this in two ways depending on your release. For all OIDC-supported releases, use the Global Proxy Configuration in transaction SICF. This configuration is specific to each ABAP client (MANDT), so set it up in both the target ABAP client and client 000. For some releases, you can configure a Local Proxy in transaction SOIDC. Activate the local proxy by checking "Use Local Proxy" and provide the Proxy Host, Proxy Port, and optionally the Proxy User and Proxy Password.

ICF Logon Procedure

OIDC Logon exclusively supports interactive OIDC (through an interactive HTTP Redirect to the OP). This method has been incorporated into the ICF Standard Logon Order, positioned just below interactive SAML authentication.

BTW, even though AS ABAP only supports the Code Flow, it’s worth mentioning again that the Identity Authentication (IAS) OpenID Connect implementation supports all flows of the OpenID Connect Core 1.0 standard.

For?OIDC Logon, mechanisms are introduced which allow the caller to control whether to?skip?interactive OIDC authentication for certain HTTP calls. Similar control mechanisms exist for other authentication mechanisms, such as SAML 2.0 or SPNEGO, and that’s why ?|&oidc=disabled works here as well. So, make sure to either adjust your logon procedures or disable SAML to make use of OIDC.

When accessing an ICF service where OIDC Logon is applicable, the end-user's browser is redirected to the OpenID Provider's Authorization Endpoint. The end-user authenticates there, and the OP issues an Authorization Code, which is sent via an HTTP redirect to the ABAP system's public OIDC Redirection Endpoint (found at /sap/public/bc/sec/oidc/redirect). And this service node has to be enabled as well via TCode SICF ;-)

This short-lived Authorization Code is then exchanged for an OIDC ID Token via a direct HTTPS call to the OP's Token Endpoint.

A crucial point to understand is that the actual ID Token does not traverse through the user's browser as often the case with SAML responses when using front-channel communication. Typically, in tracing tools, only the Code Flow and Code/State Response are visible.

The ABAP system exchanges the Authorization Code received at the ABAP system's Redirection Endpoint for an OIDC ID Token through a direct call to the OpenID Provider's Token Endpoint. TLS is utilized, relying on the STRUST SSL Client Anonymous PSE 'ANONYM' as the SSL Trust Anchor. Hence, the certificate list of that PSE in the ABAP system must be updated to accept the OpenID Provider's TLS certificate (or the Root CA) as trustworthy.

The token undergoes validation (digital signature check, timeliness, token claim checks, etc.).

In later releases a new ICF service flag, JavaScript-based redirect (URL fragment preservation) for interactive OIDC logon has been added to transaction SICF (found under the Logon Data tab). The ABAP OIDC implementation retains the original HTTP request sent to the ABAP server before redirection to the OP and restores it after successful OIDC authentication. However, the URL anchor fragment (e.g., https://my-sap.system.com/site#Shell-home) isn’t sent to the ABAP system and would be lost during traditional HTTP redirects. Activating this flag uses JavaScript for redirects, ensuring the URL anchor fragment is preserved during OIDC authentication and this way supports deep-links.

Enabling OIDC in the configuration necessitates specifying several HTTP endpoints (at both the OpenID Provider and the OIDC Relying Party ABAP) and configuring the Client Authentication Mechanism for the RP ABAP's authentication at the OpenID Provider during the Authorization Code to ID Token exchange.

The OIDC Configuration API (transaction SOIDC) allows downloading the OP's metadata via the OpenID Connect discovery endpoint to streamline the configuration. This populates the values for the JWKS URL, Authorization and Token Endpoint URLs, the mTLS Token Endpoint Alias, and the End Session Endpoint URL with the corresponding metadata values.

Update: In addition, there's a handy report you can schedule to automatically download the latest JWKS from the OpenID Provider and update the keys in your OIDC configuration. For more details, dive into sections 1.2 and 1.3 of SAP Note 3111813 - feature F12.

Among all OIDC configurations within one ABAP client (as this is client-specific like SAML), only one can support the Interactive OIDC Mode as the Default Interactive Configuration. This configuration is utilized during OIDC Logon to execute interactive OIDC for a particular ICF service.

User mapping mechanism

User mapping in OIDC is controlled by two fields.

1. First, the User Mapping Claim determines which claim in the OIDC ID Token is used for user mapping. Typically, this should be the 'sub' claim, as per OIDC standards. However, ABAP also supports 'email', 'oid', and 'user_name' claims, and even custom claims if needed. You can specify a custom scope to obtain these claims if necessary.
2. Second, the User Mapping Mechanism defines how to match the extracted claim value to an ABAP user attribute. For example, if the User Mapping Claim is set to 'sub' and the User Mapping Mechanism is set to E-Mail, the system will match the 'sub' claim value to the ABAP user's email address. It’s crucial that user mapping is consistent and unambiguous, so ensure the OpenID Provider correctly inserts the user's email into the 'sub' claim of the ID Token.

The user mapping is employed to match a single ABAP user to the ID Token claim configured as the User Mapping Claim. The mapping of the sub claim (or others) to a SU01 attribute can occur as follows:

Finally, the ABAP user is logged in, an HTTP Security Session cookie is issued, and an HTTP redirect to the originally requested ICF service is initiated from the Redirection Endpoint.

ID Token Example

Here's a brief look at an example token response, including an ID token, obtained from a tenant of SAP Cloud Identity Services - Identity Authentication acting as the OpenID Provider.

Example OIDC Token Response:

{
    "access_token": "eyJ...Kgo=",
    "refresh_token": "93039...",
    "id_token": "eyJ...Kgo=",
    "token_type": "Bearer",
    "expires_in": 3600
}        

The payload of the ID token decoded for illustration:

{
  "kid": "ygOrjjm3eu-tXDixxQYNf_dg6X4",
  "alg": "RS256"
}        

Payload:

{
  "aud": "bca99edc-a048-4e76-8076-ba0f7496a4ae",
  "sub": "[email protected]",
  "iss": "https://some-IAS-tenant.ondemand.com",
  "exp": 1613497834,
  "iat": 1613494234,
  "nonce": "5f29aa5da103a023a507a42df0edb0dbb7e017a8"
}        

Key Claims:

• aud (Audience): The intended audience for the token, typically an OAuth client ID for the RP.
• sub (Subject): Identifies the authenticated user at the OpenID Provider, here chosen as the user's email or SAP User Name
• iss (Issuer): The entity that issued the token (OpenID Provider), represented as an HTTPS URL.
• exp (Expiration Time): The UTC timestamp when the token expires.
• iat (Issued At): The UTC timestamp when the token was issued, to handle system clock drift.
• nonce: A value from the authentication request to prevent replay attacks.

Battle of Authentication Protocols: OpenID Connect vs. SAML 2.0

Round 1: The Technology Tango

In the left corner, we have OpenID Connect (OIDC), the agile newcomer leveraging the OAuth 2.0 protocol and utilizing JSON. OIDC moves gracefully within modern mobile apps and single-page applications (SPAs), thanks to its lightweight, HTTP-friendly nature.

In the right corner stands SAML 2.0, the heavyweight champion with its XML-based authentication framework. While SAML can be cumbersome in the nimble world of mobile apps, it boasts robust security and a well-established reputation.

Round 2: Implementation Artistry

OIDC is the developers' darling, shining with a straightforward client implementation. It's like piecing together a jigsaw puzzle where the pieces fit perfectly.

Conversely, SAML feels like solving a Rubik's cube blindfolded—powerful and flexible, but its setup can be daunting, requiring meticulous attention to detail, particularly in exchanging SAML metadata and establishing trust between Identity Providers (IdPs) and Service Providers (SPs).

A clear advantage of OIDC is the easy and quick configuration of trust between the RP (Relying Party) and OP (OpenID Provider). While Client ID and Secret are popular and convenient for password-based client authentication, the (perhaps more recommended) mTLS Client Authentication using Client Certificates is also an option. This flexibility can significantly reduce operational effort compared to the typical SAML metadata or SAML signature certificates.

Additionally, OIDC Discovery, as outlined in the OIDC Discovery Specification and supported in transaction SOIDC, is offering a simpler, more automated approach to discovering configuration information. This means OIDC can largely operate without certificates, thereby reducing the associated administrative burden.

Round 3: Performance Check

Speed (and scalability) matters! OIDC, with its JSON tokens, processes data faster than SAML's XML assertions. In high-traffic environments or on mobile devices, this speed boost can be crucial.

Round 4: Future-Proof Fireworks

OIDC dazzles with promises for the future. It's designed for modern, cloud-based, and mobile-centric applications, making it SAP's preferred standard for future SaaS applications on SAP BTP. SAML, however, remains a steadfast option, especially for infrastructures already built around it. Its age doesn't mean it's obsolete; it's the trusty old guard that's still got solid moves.

Final Verdict: Can There Be a Winner?

Alright, I admit it - if you know how to configure it correctly, OIDC is faster out of the gate than SAML, likely on both sides regarding configuration efforts. If you don't need IdP-initiated SSO, there's little reason not to choose OIDC, if your ABAP NW Basis release and SPs are up-2-date.

OIDC seamlessly integrates with existing OAuth 2.0 frameworks, making it highly compatible with modern cloud services. For instance, connecting a mobile app to a cloud-based backend using OIDC is straightforward. In contrast, SAML is well-suited for older, enterprise environments where legacy systems are prevalent, such as integrating with on-premises Active Directory for enterprise SSO solutions.

While SAML boasts robust security features like XML Signature and encryption, it has faced notable attacks in recent years, such as XML Signature Wrapping. In contrast, OIDC leverages JWTs, which have proven to be equally secure when properly managed. JWTs offer a streamlined approach to token handling, simplifying secure communication between services without compromising on security.

In summary, OIDC stands out with its simplicity, performance, and modern architecture, making it a strong contender for contemporary applications, especially those leveraging SAP Cloud Identity Services and mobile platforms. OIDC benefits from extensive developer support and a vibrant community, with numerous libraries available for various programming languages. This makes it easier for developers to find resources and troubleshoot issues. For example, integrating OIDC in a Node.js application is well-documented and supported.

SAML remains a robust and reliable option for established infrastructures and excels in IdP-initiated Single Sign-On (SSO), where the IdP initiates authentication without a prior request from the SP - a scenario not supported by OIDC.

The choice between SAML 2.0 and OIDC should align with your specific needs, technical environment, and future goals. Both protocols aim to provide secure and seamless authentication and authorization, ensuring your processes are secure and efficient.

Choose wisely, and may your authentication be ever secure and efficient!

Helpful Links and Information

Here is a summary of all the links referenced in this article with further information:

• JSON Web Token
• OAuth2 framework
• OIDC Core 1.0 Specification
• Connecting SAP IAS as a proxy to Azure AD using OpenID Connect: https://community.sap.com/t5/technology-blogs-by-members/connecting-sap-ias-as-a-proxy-to-azure-ad-using-openid-connect/ba-p/13534385
• Explained #1: SAP IAS Proxy Mode and ID Federation: https://xiting.com/en/explained-1-sap-ias-proxy-mode-and-id-federation
• Guide for configuring OIDC for ABAP: https://help.sap.com/docs/ABAP_PLATFORM_NEW/e815bb97839a4d83be6c4fca48ee5777/8d656ab408f1448e8af3f0da6800b72a.html
• Information about OIDC related to SAP IAS: https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/openid-connect
• Highly recommended SAP Note 3111813 for OIDC troubleshooting with a lot of useful additional information: https://me.sap.com/notes/3111813/E

Carsten Olt

Head of SAP IAM, Xiting