SAP Single Sign-On 3.0 helps organizations to reduce effort and risk
SAP Single Sign-On 3.0 has a lot of new features to help organizations reduce effort and risk involved in implementing and maintaining a secure single sign-on (SSO) solution for SAP. In this article, we will present you the three best features of this new release.
Table of Contents
Encryption-only mode to ensure secure communication, always
The Secure Network Communications (SNC) module was integrated into the network interface of all SAP components in 1997, and it is still an integral part of the standard. Besides Authentication (Single Sign-On), SNC offers data-in-transit encryption. Until the release of version 3.0, SAP Single Sign-On used the source to derive cryptographic keys used for user authentication and session encryption.
In the case of an issue with the user authentication mechanism, for example, caused by a lost or forgotten smart card or the unavailability of Secure Login Server (a critical component of SAP Single Sign-On), often the only workaround was to disable SNC altogether. Unfortunately, that also meant disabling encryption and potentially exposing data-in-transit.
The new encryption-only mode of SAP Single Sign-On 3.0 enables network encryption for the SNC protocol used for communication with SAP systems, even if a user-specific security token is temporarily unavailable or not yet configured. That allows customers to immediately protect data communication during an implementation project, before user-specific configuration (user mapping) is in place, and to ensure data privacy if the end-user has lost the smart card holding the required digital certificate. The encryption-only mode is enabled automatically whenever there is no security token available for SNC.
Data encryption for SAP Dynamic Information and Action Gateway (DIAG) or Remote Function Call (RFC) connections in 2016 must no longer be considered nice-to-have, but a must, and it is equally important as encrypting HTTP connections using TLS. That not only prevents eavesdropping on SAP network traffic but also protects user credentials sent over the network during SAP authentication, especially in those cases where no single sign-on is possible for whatever reasons and password-based authentications takes place.
With the latest SAP CommonCryptoLib in conjunction with the Secure Login Client 3.0, you can make use of that feature.
Support for existing PKI implementations
The Secure Login Server is part of SAP Single Sign-On and acts as a central service, which provides X.509 certificates to users and application servers (out-of-the-box PKI). So far, companies have used the Secure Login Server mostly in scenarios where no certification authority was available or if additional security and strong authentication – such as one-time passwords – were required to access critical SAP systems in the landscape.
As soon as organizations operate a dedicated PKI for wider use in the IT landscape, many aspects have to be taken into account. Processes are in place to control the registration, issuance, and lifecycle of the certificates. Central administration and provisioning of certificates and revocation lists, the operation of an OSCP responder, security of the private keys by using hardware security modules (HSMs) or the configuration of the certificate types to be issued, are only a few aspects. In addition to this, a large number of organizational issues and concepts for ensuring proper operation of the PKI, the processes as well as technical and non-technical guidelines known as Certificate Policies (CP) and Certificate Practice Statement (CPS) need to be applied, which often prohibits any other certificate issuer. As a result, customers already operating an enterprise PKI, normally do not want to introduce the Secure Login Server as a second system for provisioning digital certificates.
SAP Single Sign-On 3.0 introduced a new feature for the Secure Login Server (SLS) called Remote CA. By using this feature, the SLS no longer has to operate as a separate CA under an existing Corporate Root CA. It allows easy integration into an existing PKI. An SLS-Remote CA acts as a web service for an existing enterprise PKI solution, which allows client certificate requests to be signed by the PKI instance instead of SLS itself. The Secure Login Server only forwards the client requests and takes care of proper authentication while still providing robust authentication and name mapping features. With this approach, the SLS verifies the identity of entities requesting digital certificates, and if required offers risk-based authentication, multi-factor authentication as well as RADIUS, RSA SecurID, LDAP, and SPNEGO authentication.
With the latest service pack (SP01) of SAP Single Sign-On 3.0 released, SAP has further extended the Remote CA support. Now the Secure Login Server supports Simple CMC and Microsoft Active Directory Certificate Services (ADCS) with NDES and Web Enrollment. All of them are addressed by using HTTP destinations. Additionally, for ADCS the SLS now supports three types of certificate templates, thus allowing the SLS to issue not only user authentication certificates but also long-term SAP server authentication (TLS) certificates.
Lifecycle management
As soon as digital certificates are used on IT systems (including SAP), you need to take care of their lifecycle. When using Active Directory Certificate Services, you can make use of Autoenrollment and Autorenewal to automate the certificate provisioning and renewal for user and server certificates. That applies mainly to Microsoft Windows based machines. Until now, such a feature wasn’t available in the SAP world.
The process of automatically enrolling server certificates and taking care of their proper renewal, can now be implemented by registering all involved AS ABAP systems to your Secure Login Server. That is made possible by the so-called Certificate Lifecycle Management, part of the new SLS 3.0. You can use ABAP reports to setup and automate the certificate management for certificates that you previously managed via transaction STRUST. Moreover, the Secure Login Server can facilitate and automate the process of rolling out trusted root certificates to all systems that you registered for the lifecycle.
While implementing the certificate lifecycle management feature is a simple and straightforward process, setting it up for every instance in your SAP landscape would be a tiresome process. To mitigate that, SAP Single Sign-On 3.0 includes a command line tool that automates the certificate renewal for all server components in your landscape using a file-based personal security environment (PSE). The SAPSLSCLI allows you to fully script your certificate lifecycle. Beginning with the initial creation of your PSE files, the request of the registration agent certificate, the enrollment, and installation of your signed certificates as well as the distribution of trusted Root CA certificates and renewal of your server certificates, based on a defined grace period. This script could be scheduled with operating systems tools. The lifecycle management, of course, can be combined with the Remote CA feature previously mentioned.
SAP Single Sign-On 3.0
The features described above help administrators to manage the certificate lifecycle by automating creation, enrollment, renewals, thus significantly reducing manual effort, eliminating the risks of human errors, and preventing costly system downtime. With the latest features part of the new release 3.0 you can strengthen the security of your SAP landscape, simplify the administration and dramatically reduce efforts and costs as your SAP landscape increases in size.
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
