Search
Close this search box.
Jobs

SAP Single Sign-On Insider Tips – Volume #6

SAP Single Sign-On Carsten Olt

Welcome to a new article of our “Insider Tips” series and my first blog about secure authentication and Single Sign-On in this year. Why did it take so long? Well, I was busy building-up a secure SSO infrastructure for many companies and still, I am. ??

It is true, SAP’s standard login procedures are insecure and not user-friendly. I some of our last blogs we already talked about the benefits of SSO or about how to enforce encryption for your SAP connections. Encryption comes first, always. On top of that, you replace the existing authentication method with a more secure and token-based approach, that is what SSO is all about.

In general, handling your dozens of login credentials in today’s IT world is an issue in itself and subject to many awareness campaigns out there. In this blog, we would like to provide you a few approaches that may help to operate your SAP landscape even more secure whilst keeping the needs of your users and system administrators in mind.

Foreword

Passwords are seen as the key to our information and should, therefore, be selected and handled with care. They accompany us in everyday life and are often used when accessing the operating system or when logging on to company applications such as SAP.

For good reasons, securing access data is very important from an IT security perspective because credentials are seen as the primary gateway for most kinds of threads leading to compromised systems.

In their day-to-day work, users are faced with more and more accounts for different systems and applications. For each application, it is best to remember a secure and complex password and to renew it regularly.

This cannot work, overwhelms many users and has no advantages from an IT security perspective, this ball usually goes backward and weakens overall security.

Single Sign-On (SSO) has the potential to solve many of the problems associated with passwords. But still, there are lots of companies not using SSO at all.

Bad idea. And there are some still using passwords despite SSO and consequently never deactivated the passwords for their SSO-enabled users. Possible, but also a bad idea. This principle also applies in the SAP environment: “Avoid passwords whenever possible and use SSO”.

Definition: Single Sign-On (SSO) is a centralized session and user authentication service in which one set of login credentials can be used to access multiple applications. With one set of credentials, (single or multi-factor authentication) you can enable and disable user access to multiple systems, applications, and resources.

Meanwhile, SAP landscapes have become significantly more complex than one decade ago. They consist of a wide variety of different systems that interlink closely with existing IT components and extend into the cloud. Applications running within this hybrid SAP environments are made to be consumed from anywhere and on any device.

And this requires authentication. Due to its multi-system landscape and decentralized password management, the SAP landscape is an ideal environment for  SSO, helping to significantly reduce the total number of passwords required for several systems and to eliminate password logons.

Using SSO outsources authentication to a central system that verifies your identity and based on that issues a security token. Once you got that you can access your various SAP applications. Such a central system can be secured much better than each SAP system itself.

Access to the respective SAP system is then only possible using security tokens such as X.509 certificates, a Kerberos ticket or a SAML assertion. This meant that the user had to identify himself beforehand once, which in some circumstances may require the use of multi-factor-authentication.

The security tokens themselves are cryptographically protected and of course, do not contain any credentials such as passwords.

With SSO gone are the days when users had to remember dozens of passwords for different systems or had to change them frequently. An additional advantage is the ability to quickly lock out certain users like when an employee leaves the company.

In the best-case scenario, no access to the Active Directory (central system) also means that access to on-premise SAP applications and integrated cloud applications such as SAP Ariba or SuccessFactors is no longer possible. 

Besides the efforts and costs related to password-reset-calls, there are also security issues. Nobody wants to be a victim of phishing emails. And nobody intentionally uses a very simple password so that hackers have a particularly easy game using a dictionary or brute-force attack.

Most users are familiar with the current regulations and recommendations for secure passwords yet using passwords still is a prone process. However, if the company does not provide an SSO solution, the secure handling of access data ultimately remains with the user, and yeah!

Correct handling of passwords after implementing SSO for all SAP systems and applications

In our view, the goal of a complete SAP Single Sign-On implementation is to increase security by confidentiality, integrity, and authenticity. No unencrypted connections are allowed to that system (exceptions possible) and there are only a few accounts left having a password at all and permission for password-based access. 

Unfortunately, this does not happen in many cases and so passwords continue to exist in the SAP systems and are forgotten soon. SSO doesn’t care about the password status of an SAP user.

If it still exists and SNC+SSO is not enforced, users and adversaries can easily bypass security and perform direct system logons. Password policies, therefore, remain active and regular password changes are also required. While performing the transition from POC to pilot and introducing SSO to a larger group of users, we recommend keeping the passwords enabled (despite SSO) for various reasons. 

The transition to a password-free user can then be carried out automatically and planned by the SAP system over a certain period. Alternatively, users can be involved in the process and delete their password using a kind of self-service procedure.

The user is asked to change or deactivate his password. This setting is achieved via the profile parameter login/password_change_for_SSO = 1. The SAP system then brings up the following dialog when logging on with SNC+SSO:

SAP Change Password Request

Insider Tip: If all users are enabled for SSO on all required SAP systems and there are no other reasons against it, the users’ password can be deactivated in this system. All applications on this system, consumed via the DIAG, RFC or HTTP protocols are taken into account and configured accordingly. In this case, it is recommended to configure the profile parameter login/password_change_for_SSO = 3 (the password is deactivated without a message). Users no longer see a password change screen. A positive side effect – if the passwords are deactivated, there are no password hashes in the database.

No rules without exceptions!

Even with the use of SAP Single Sign-On, you cannot avoid passwords at all. In addition to the dialog users, there may be a whole range of communication, service and system users. Passwords will continue to be assigned to these accounts according to your company’s policies.

All the more important is the correct technical and organizational handling of these user types & passwords and to make use of the most secure hash method possible in your SAP system.

Insider Tip: The SAP systems should not generate backward compatible hash values (BCODE, PASSCODE). It is recommended to configure the systems only using Code Version H (PWDSALTESHASH). This is implemented using the profile parameter  login/password_downwards_compatibility = 0. An obstacle implementing this is often the operation of a CUA in an SAP landscape that is highly heterogeneous from an NW release point of view.

Logon profile parameter

Goodbye to regular password changes says BSI

The German Federal Office for Security (BSI – Bundesamt für Sicherheit in der Informationstechnik) 

is publishing the IT-Grundschutz Catalogues annually each February. It is a compendium that covers technical, organizational, infrastructural and personnel aspects and is to be seen as a systematic approach to information security (ISO/IEC 27001 compatible). Many of the recommendations and guidelines outlined there are influencing the SAP world as well. 

In its current edition of the “BSI Grundschutz Compendium Feb 2020”, there is a section which is now advising against regular password changes. A forced regular change of passwords is therefore outdated. Unfortunately, the 2020 edition is not yet available in English.

Better to set a separate and secure password for each (!) application or SAP system. This is perfectly fine and still best protects against so-called credential stuffing or password spraying and also “brute force” attacks.

An increase in user awareness of the subject “passwords” can be supported by the use of SSO. The number of required passwords is reduced to a minimum, making IT systems easier to use again.

With over 800 pages, the BSI work is not an easy meal. It contains security requirements for SAP systems as well. Like in APP.4.2.A31 in that a securely configured single sign-on is recommended or APP.4.2.A18 in which it is advised to switch off any unsafe communication and enforce the use of SNC and TLS and thereby enables the use of various SSO methods.

Conclusion

The use of single sign-on offers many advantages such as increased productivity and security and creates greater acceptance by end-users and system operators. If the risk of abuse in the SSO environment is classified as high, SSO is no longer considered sufficient for the risk classification. In these cases, multi-factor authentication can be used.

Different MFA methods in the form of hardware and software tokens are supported both in the environment of various identity providers and with the SAP Single Sign-On 3.0 solution.

If an adversary gets in possession of access data, the gates are open for further attacks based on that credential pair or the password-schema. They will then try it for other accounts or systems as well. Thanks to AI & machine learning, there are very complex algorithms that already predict future passwords, the keyword is “Password-Guessing Machines”.

Insider Tip: If the past has shown us one thing, it is that we cannot rely on the fact (or wish) our credentials on various IT systems are secured in the best possible way. Hence, it is best not to work with passwords at all. Use a well-secured SSO system whenever possible. Especially when working on cloud applications, no passwords should be used for authentication. Instead take advantage of SAML 2.0 and outsource the authentication to a central and trustworthy identity provider, which in turn is operated using SSO or MFA.

In this context, finally, a few rules:

  • Use passwords only if there is no way to set up a more secure authentication method.
  • Always use encrypted connections to your SAP systems (SNC+TLS). Make sure the procedures and algorithms are state-of-the-art.
  • Use a different and strong password for each system.
  • Create long and complex passwords using a generator.
  • Use a password manager (…and write down the master password on a piece of paper).
  • Use two-factor authentication for critical systems or privileged accounts.

Check out the other articles in our blog series „SAP Single Sign-On Insider Tips“:

In the next blog Hardening SNC and TLS with SAP CommonCryptoLib we talk about how SNC and TLS are configured the best way and how the CCL can be hardened using profile parameters. Is there a topic in the area of secure authentication and SSO you are particularly interested in? 

Let me know!

Carsten Olt
Latest posts by Carsten Olt (see all)
Contact

Get in touch with us!

Do you have questions about our products?

+41 43 422 8803
[email protected]
+49 7656 8999 002
[email protected]
+1 855 594 84 64
[email protected]
+44 1454 838 785
[email protected]
Contact
Webinars

Attend our live webinars and learn more from our experts about SAP authorizations, XAMS, SAP IDM and many other topics in the context of SAP security.

Register now