Compared to other projects in the SAP security environment, SAP Single Sign-On can be introduced very quickly and achieves a significant effect that has an immediate impact on your users, your administrators and your SAP systems.
According to statistics, about 80% of all attacks on IT and SAP environments are
facilitated by unsecured SAP network communication, intercepted access data, or weak passwords. The protection of credentials is therefore a high priority.
SAP landscapes, consisting of various front-end and back-end components, are closely integrated with existing IT components and in the cloud, so hybrid SAP environments and mobile use have become standard. Due to its multi-system landscape and decentralized password management, an SAP landscape is an optimal candidate for usage of Single Sign-On (SSO) to significantly reduce the total number of passwords required for multiple system landscapes or to eliminate password logon completely.
With the introduction of the SAP Single Sign-On 3.0 security solution in your company, your SAP users can access your SAP systems and web applications securely and without passwords with just one logon. Through the transparent use of different authentication methods to verify users, extensive options are available, such as authentication using Kerberos, X.509 certificate, or Security Assertion Markup Language 2.0 (SAML 2.0). In addition, advanced scenarios – such as multi-factor authentication (MFA), RFID-based authentication, or the use of hardware-based security modules – can be implemented.
The concept of a real SSO is based on the idea of giving the user access to all applications via a single login. This should be as secure as possible. Usually, the Windows logon to the Active Directory is used. Based on the so-called primary authentication, SSO industry standards are used and thus passwords are ultimately replaced by security tokens. SSO reduces the number of passwords required by the user to a minimum. The SSO system with its components ensures that the user has identified himself or herself as a valid user and is then issued a certificate of trust.In principle, the SAP systems only check this proof, or the trusted security token, instead of authenticating the user themselves.
Depending on the operational environment, increased security requirements can be taken into account. If the risk of misuse is considered high, possibly for accessing sensitive or externally accessible SAP applications, a two-factor mechanism can be implemented. In such a case, authentication with username and password alone is no longer considered sufficient with regard to the risk classification. If you have SAP systems in which you do not use or do not want to allow Single Sign-On, it is possible to force additional authentication to a central authentication server, such as an SAP HCM, an LDAP directory, or the Active Directory. For example, if you access your SAP ESS/MSS portal, you must log on with your Active Directory credentials or even enter an additional one-time passcode (OTP). However, when accessing less critical SAP applications, an SSO is configured.
Answering this question is one of our tasks. The appropriate SSO procedures are determined in our workshop based on existing IT components and your requirements. Of course, we point out the respective advantages and disadvantages and orient ourselves on the KISS principle. In most cases, these standards are also used in parallel, though this also depends strongly on your specific requirements as well as the SAP and non-SAP applications that are to be integrated into the SSO system.