SAML SSO and those lovely exceptions!

[Colt]

Hey there, fiends of the well-groomed SSO world!

So, here I am, fancying myself quite the expert on the subject, but hey, who says there's no room for a little community chitchat, right? This time it's about SAML and its implications on an SAP system. All of this in connection with those scenarios that are not in the sense of "user opens the launchpad".

Had a classic case at a client's place today. Just after introducing SAML, bam! Developers screaming bloody murder, their test scripts getting served up a delicious 401 error from the development environment.

We're talking about accesses from specific user groups on the system who:

• Need to do a bit of coding (cue the /sap/opu),
• For whatever reason, must, want, or should work with passwords (who knew we'd still need those, right?),
• Require login with test user credentials, like your friendly neighborhood power users and app testers,

...and whatever else you can think of!

Question: So, how do you folks tackle configuring your ICF services or defining exceptions for these situations?

Give the info below a quick read, and let's dish out some helpful, tried-and-true advice. Oh, and a lively exchange of ideas wouldn't hurt either, if that's still a thing around here!

Here's the backstory

All SAP systems (ABAP, essentially meaning S/4HANA, possibly residing on ECS) at CUSTOMER have been configured to utilize SAML. This configuration is applied system-wide (and per client) and impacts every ICF service. This setup achieves Single Sign-On for HTTP access. Authentication is no longer handled by the S/4HANA system itself (Basic Password Authentication), but instead, it is forwarded via SAML to SAP Cloud Identity Services (IAS), which delegates authentication to the Entra ID at CUSTOMER.

This facilitates seamless and secure access to web-based applications such as SAP Fiori Launchpad, WEBGUI, SOAMANAGER, NWBC, and others, without users needing their SAP password anymore. Instead, employees simply authenticate with their CUSTOMER account, and their identity is federated to the user in the SAP system (SU01 email address) via their email address.

There are also other scenarios, such as developers accessing specific services with hardcoded user credentials, using test scripts, or other cases where an exception is needed. In such instances, SAML can be selectively disabled to no longer delegate authentication to the Identity Provider via HTTP redirect/post for that specific service.

To address these requirements, the following measures can be implemented:

• If individual ICF services need to be accessed without SAML authentication, for instance, in the context of test scripts during development, developers can append the URL-parameter ?|&saml2=disabled when making the call. This bypasses the SAML authentication process for that ICF node, switching to Basic Password Authentication, enabling normal login with user credentials in the SAP backend. Note: This approach might not work as expected in a BTP/Cloud Connector scenario.
• If certain services don't require SAML authentication at all, this can be achieved through SICF configuration. SAML authentication can be disabled in the login procedures to ensure these services can be used without the SAML protocol.

Oh, and if you're eager for more bedtime stories, check out these links:

https://community.sap.com/t5/technology-q-a/ui5-app-in-scp-how-to-disable-saml/qaq-p/12301269

https://me.sap.com/notes/0002577263

I stumbled upon this one yesterday: The requirement is that all web-based logins should be compelled to use SAML, and anyone attempting to use 'saml2=disabled' should be denied or How to enforce all web-based logins to use SAML2 in an ABAP system: https://me.sap.com/notes/0003280746

Thx & Cheers
Carsten