My wish list for SAP Single Sign-On 4.0

[Colt]

Hey community,

did you know 2027 is the end of all days for good old SAP SSO 3.0?

Rest in peace.

That would be in 6 years.

Okay, I am just kidding 🙂 here we only see the announced expiry date for the EoMM which is 31.12.2027.

Who knows, maybe until then, we already live in a world where everything runs on UI5 and we purely use our browsers or apps to access any SAP application. No more SAP GUI. A bit of a strange idea, right? Let’s see what the future brings.

Until then, a lot can happen, and because it's Xmas-time, here is my wish list. It contains ideas and features that I would love to see in generation 4.0 of the SAP SSO solution. I may add additional points to this list at any time.

It's also my pleasure to use this occasion to address some feature requests floating around in my head for a long time. Finally, some of my ideas outlined here are compiled and merged with feedback from project-fellows I have met in many authentication projects at a wide variety of companies in the last decade.

I hope you like the idea, and it would be great if some of you would take part and expand the list with additional concepts or required features. And if I am telling rude nonsense here, please tell me that too, can bear it. Let us support and maybe influence product management focusing on features that would bring real benefits and cover use-cases required and demanded from our customers.

In this sense wish you a wonderful holiday season.

Carsten

 

Moving SAP SSO 3.0 components to the cloud

SLS in the cloud? Will it come and does it make sense? Here is my view on it. As long as the SAP GUI exists, there will be a demand for client-side security components, that a future SSO 4.0 solution would have to provide. It probably consists of the SNC library and the component SAP Secure Login Client (SLC). The possible successor solution may allow using secure TLS protected API-based communication between the components and this way supports scenarios that are currently not possible or badly implemented. 

With SSO 3.0 there are a few components for which you had to provide a NetWeaver AS Java, to cover some interesting use cases. Features like TOTP-based MFA for SAP GUI, integration of different authentication systems, and Certificate Lifecycle Management. 

Those are the SAP Secure Login Server (SLS), the SSO TOTP Authentication Library together with the SAP Identity Provider. The last two have already been replaced by SAP Cloud Identity Authentication (IAS). SSO 4.0 could be an integrated part of the SAP Cloud Identity Services. A cloud service that runs within a multi-cloud environment operated within in a region and datacenter of choice orchestrated on the SAP BTP, howsoever.

A potential SLS 4.0 could bring support for policy-based SAP GUI MFA and provide temporary SSO certificates. It should also come up with updated Certificate Lifecycle Management (CLM) capabilities. Companies can still operate an internal PKI or integrate with existing PKI solutions. The implementation of the Automatic Certificate Management Environment would be great. ACME according to RFC8555 is a protocol that a CA and a certificate requestor can use to automate the process of verification and certificate issuance.

The SLAC would have been merged into the evolved Identity Services admin console. Profiles can be generated and provided for easy distribution towards the SLC. The cloud service handles incoming enrollment requests received based on specific profile IDs/applications created within the IAS.

Within each profile, you specify the CA used for certificate creation and parameters such as DN, SAN, lifetime, and the authentication method required to receive the certificate. This way the same rules apply as for other IAS applications, and companies may even forward the authentication to their Corporate IdP such as Azure to make use of Conditional Access, MFA, and other security features required to authenticate the user and ensure zero-trust.

In exchange for a SAML or ODIC token, the cloud token issuer (CA) generates and signs the short-lived X.509 certificate containing the Subject-DN and SAN attribute of choice. It is securely provided to the SLC, registered in the OS certificate store, and provided as an authentication token for the SNC layer.

Azure AD only environments and SAML triggered SAP GUI SSO

A growing number of companies increasingly rely on Azure and Intune. Windows Autopilot is a toolset for setting up new clients with company settings and software. The end-user can unpack his new device, log into the MSFT cloud, and the autopilot takes over the further setup. The local IT no longer must join the device to the AD domain. In connection with Azure AD (no hybrid mode), the clients or “devices” are no longer part of the internal Active Directory. The previous SAP GUI SSO solution based on Kerberos will no longer work in such environments.

Info: Companies that still rely on functions such as domain join, group policies, lightweight directory access protocol (LDAP), and Kerberos/NTLM authentication can deploy Azure AD Domain Services.

For SNC it's either Kerberos or X.509. SAML support is often asked in such modern workplace scenarios. No, it is not possible to use SAML 2.0 with SAP GUI connections, see here https://launchpad.support.sap.com/#/notes/0002564192

A future SLC and SLS 4.0 could provide a reliable and easy-to-use implementation of what I call “SAML triggered SAP GUI SSO”. One that securely integrates with the browser of choice. The current implementation with the Secure Login Server has always been a bit bumpy and makes no fun from a ux perspective.

This approach would bring several benefits, it allows making use of various authentication methods including biometrics and MFA (FIDO2) to authorize the enrollment of SLS 4.0 certificates. This way an alternative for operating an own certificate infrastructure can be provided, that can be implemented quickly and yet provide features such as biometric integration for certificate enrollment out of the box. Also, for many possible reasons often companies do not want to enroll and manage the lifecycle of user certificates. 

What else? 

One thing that regularly comes up is the request for a user selection screen when consuming SAP ICF services where one SNC name is assigned to multiple users in the same client. Any other ideas or requests like this? Please add a Comment!