SAP Single Sign-On Insider Tips – Volume #3
Welcome to a new article of our “Insider Tips” series. If you are a loyal reader of our blog, you already know the benefits of Single Sign-On for SAP. SAP’s standard login procedures are insecure and not user-friendly. In our previous articles, we talked about how to achieve secure DIAG, RFC, and HTTP communication by using state-of-the-art end-to-end encryption. On top of that, I recommended replacing the existing authentication method with a more secure and token-based approach. That is what SSO is all about.
SSO and the coexistence of passwords… or how to increase your SAP password security
In volume #3 we talk about what SSO means for your SAP passwords, and answer the following questions: Do you still need passwords after implementing SSO? Or can you get rid of them completely? What are the best ways for handling SAP passwords after introducing Single Sign-On?
Access to IT systems must be restricted and controlled. That is the reason why we have authorization concepts. But before authorizations kick in, users have to authenticate first. That can occur against the target system, or even better, against a central trust repository. One of the issues in today’s IT landscape is identity and authentication. And chances are, it will stay like that until quantum computers, artificial intelligence, and the blockchain rule the world 🙂
Protecting your identity and credentials is more significant nowadays than it ever was. That is especially true for SAP systems. Still, more than a half of all successful data breaches are caused by weak, default, leaked or stolen passwords.
SSO often relies on a central repository, such as Active Directory, for user authentication. As a result, users enjoy transparent access to all SAP applications, after having authenticated against Active Directory as part of the login to their computer. Gone are the days, when users had to memorize dozens of passwords for different systems or change them frequently. Gone are the days when SAP passwords were transmitted over the network in clear text. Instead, both user productivity and the overall security were improved, thanks to the reduced number of passwords.
An additional benefit of hooking SSO up to a central user repository is the ability to quickly lock users out of all SAP systems, for example, if the user leaves the company.
Hint: By removing passwords as part of a SSO implementation, previously vulnerable password hashes can no longer be used by attackers to gain unauthorized access to SAP systems. Instead, attackers would have to penetrate your Active Directory infrastructure, if that is the central user repository for SAP. That is often more difficult than attacking individual SAP systems.
Seven rules of increasing your password security while using Single Sign-On
- SAP passwords are still present, and they are not gone. You just don’t use them with SSO. Password rules stay active. For example, regular password changes are still required, although users log on to the system using single sign-on. You can configure your SAP system to ignore password changes, caused by existing password policies. That way, users can always log in and even if the password is “initial”.
- The golden rule is that SSO should be mandatory for regular SAP users and thus about 95% of all SAP users.
- You still will need to maintain passwords for the remaining 5% of your accounts such as standard accounts or RFC users. That must happen according to your corporate password policies, even if they don’t apply for some user types in SAP.
- You should avoid password-based login and configure your SAP applications to allow a password based login only in cases where it is required. Examples are the use of standard users or to allow developers and testers to log in with different users for some reason. The latter use case can also be addressed with SSO. That applies to SAP GUI as well as to any SAP web application.
- If SSO has been implemented SAP users should no longer need to worry about passwords at all. SSO needs to be implemented consistently across all applications and frontends. Once that is done, all passwords can be deactivated. If not, you may quickly run into issues. One of the biggest mistakes is to forget applications relying on existing passwords. One example that comes to my mind is SAP BusinessObjects. It offers the BI Launchpad (web interface) which can be configured for SSO based on SPNego. Once users are authenticated at the BI platform, they have to perform actions that require access to backend systems, such as BW systems. And if SSO was not implemented across all these components, this is a hindrance to disable passwords in the backend, as users still need to enter them to access information.
- SAP does not store user passwords in clear text but instead, it protects them using hash functions and salted hash values. Those values are stored in several tables of the SAP database such as USR02. Once you disable the passwords and enforce the use of SSO, the password hashes – such as the feared but for hackers popular BCODE or PASSCODE values – are wiped too. This, in turn, increases the overall security.
- In general, don’t forget password security and system hardening. Use latest password hashing mechanisms provided by the SAP platform. This is important e. g. for standard accounts or RFC users. Once you have ensured that, you can delete old and redundant password hashes from the corresponding tables. SAP provides cleanup reports to do that.
Stay tuned for volume #4 of Xiting’s Insider Tips for SAP Single Sign-On!
With a security-minded approach, Carsten has international project and IT security experience in many industries. He has been working in IT-Security since 2001, specializing in SAP security since 2010. He is a subject matter expert for SAP Single Sign-On 3.0 and a trainer for the WDESSO course. His current focus is on supporting customers in solving authentication and security challenges within hybrid SAP landscapes, as well as designing and implementing holistic authentication concepts. Carsten is an ISACA CISA and a former MCP and RHCE with an ISP background, and he looks at security from different angles. He also translates between SAP and IT security vocabulary.
Carsten has in-depth experience in multi-vendor architectures and MSFT/Azure components, dealing with all the requirements concerning SAML 2.0, OAuth, OpenID Connect, SCIM, X.509 CBA & PKI, MFA, SAP SSO, and Secure Network Communications, Kerberos/SPNEGO, data security and encryption, as well as digital signatures.
Carsten is experienced in SAP on-premises components such as S/4HANA, ABAP, and Java, as well as security solutions like SSO 3.0. Since 2019, he has focused on SAP-Cloudified environments, specifically the SAP Cloud Identity Services and SAP BTP, as well as SaaS integrations concerning IAM. He deals with hybrid SAP security in conjunction with Azure Active Directory, ADDS, ADFS, ADCS, Reverse Proxies/WAF, SAP Web Dispatcher, SAP Cloud Connector, third-party products, and infrastructure components.
- Cloud Integration Made Easy: Xiting Central Workflows (XCW) Meets SAP Cloud - 30. July 2024
- From Nostalgia to Excitement: The Impending End of SAP IDM - 15. March 2024
- 2024 SAP Cloud Identity Services & IAM Portfolio: What’s New? - 23. February 2024
