With the number and diversity of networked applications, systems, and devices in business environments continuing to grow, managing user authentication is a central priority for security administrators. SAP Single Sign-On addresses this challenge for SAP customers by enabling seamless, simple, and secure authentication to nearly all SAP and non-SAP systems across complex, heterogeneous IT landscapes, simultaneously reducing both risks and administrative costs associated with help desk calls and managing password policies.1
With SAP Single Sign-On, users authenticate once and are granted access to all connected applications — both in the cloud and on premise — securely and in line with corporate and regulatory compliance requirements. The encryption of data communication, the use of digital signatures, and FIPS 140-2 certification2 of security functions ensure comprehensive baseline security. Advanced features such as two-factor authentication along with interchangeable support for Kerberos, X.509 digital certificates, and the Security Assertion Markup Language (SAML) fulfill even the most complex customer requirements for landscape and usage scenarios.
Scheduled for release in July 2016, version 3.0 of SAP Single Sign-On builds on the solution’s solid foundation to meet the needs of modern IT landscapes. Version 3.0 makes implementation even easier through close integration with the SAP NetWeaver technology platform while extending security features to reflect updated protocols and delivering sophisticated administration tools. SAP Single Sign-On 3.0 also expands the existing coverage for mobile and cloud scenarios, and in particular modernizes the X.509 certificate-based scenario — a technology that many SAP customers have been rediscovering as a secure and reliable means for implementing single sign-on in highly heterogeneous system landscapes.
Before diving into the details of some of the new features included with version 3.0, it will be helpful to understand how SAP Single Sign-On implements X.509-based authentication.
Reliable, Secure Access with Certificate-Based Single Sign-On
Even in the rapidly changing world of technology, there are mainstays, proven products and features that remain valid and highly functional. One of these is digital certificates — in particular, digital certificates that comply with the X.509 public key infrastructure (PKI) standard for identity verification via public keys.
First issued as a standard in 1988, X.509 certificates continue to be a popular authentication mechanism, offering a high level of security. Many enterprise applications, including SAP business applications, natively support X.509 and require just a few configuration changes to enable certificate-based authentication, making X.509 ideal for use across heterogeneous environments. You can also easily tailor the mechanism to your needs — for example, by restricting the validity period of a public key or revoking a certificate to block unauthorized access.
Despite these benefits, X.509 certificates have a reputation of creating cumbersome administrative overhead, particularly around issuing and revoking certificates. SAP Single Sign-On offers a convenient alternative without sacrificing security. Users can authenticate to the Secure Login Server — a service included with SAP Single Sign-On that resides on SAP NetWeaver Application Server (SAP NetWeaver AS) Java — to retrieve a short-lived X.509 certificate. The validity of this certificate can be configured to meet corporate security as well as usability preferences, and can vary from several hours to days or even weeks. Specifying a short validity period makes high-maintenance certificate revocation procedures obsolete.
Figure 1 provides an overview of how X.509-based authentication works with SAP Single Sign-On. First, the user authenticates to the Secure Login Server on SAP NetWeaver AS Java (Step 1).3 Authentication can be automatic (using Kerberos, for example) or it can be manual, and can even be based on multiple factors, such as a combination of a password and a key generated on a token device. Next, the Secure Login Server returns an X.509 certificate that is valid for a specified amount of time, such as a working day (Step 2). The user then opens a connection by starting an SAP or third-party desktop or browser-based application (Step 3). Finally, the X.509 certificate is forwarded to the relevant system for authentication (Step 4):
- To SAP NetWeaver AS ABAP for SAP applications — via Remote Function Call (RFC), secured by the Secure Network Communication (SNC) protocol, for SAP GUI-based SAP applications, and via Secure Sockets Layer (SSL) or Transport Layer Security (TLS) for browser-based SAP applications
- To a third-party web server — via SSL or TLS — for browser-based third-party applications
Even the most resilient, proven technology needs to adapt to changing customer needs, however, and SAP Single Sign-On continues to evolve accordingly. Version 3.0 includes new features to meet these changing needs, including more efficient management of the certificate life cycle, expanded support for single sign-on from mobile devices, and new encryption and authentication options.
Let’s take a closer look at these key SAP Single Sign-On enhancements.
A New Feature for Streamlined Certificate Management
SAP Single Sign-On relieves security administrators from cumbersome administrative processes with the ability to generate short-lived X.509 end-user certificates that reduce, and even eliminate, time-consuming certificate revocation efforts. Version 3.0 extends this capability to include server certificates as well.
Managing these short-lived certificates securely and effectively is crucial for maintaining a high level of corporate IT and information security: X.509 certificates are not only used to enable secure user authentication and single sign-on, they are also the basis for the SSL/TLS security protocols that encrypt communication channels within the SAP NetWeaver technology platform.
SAP Single Sign-On 3.0 introduces a new feature into the Secure Login administration console (see Figure 2) — a browser-based tool included with SAP Single Sign-On for configuring authentication via the Secure Login Server — that simplifies the administration of server certificates. This tool helps administrators manage the certificate life cycle by automating renewals, significantly reducing manual effort, eliminating the risks of human errors, and preventing costly system downtime.
Let’s take a look at how this works (see Figure 3). First, in the Secure Login administration console, you register SAP NetWeaver AS ABAP with the Secure Login Server to establish a trust relationship between these two systems (Step 1). Next, you configure a server profile for each relevant certificate, which is required to facilitate the automated renewal of certificates (Step 2). Now, a scheduled ABAP report can check the local SAP NetWeaver AS ABAP for certificates that are about to expire (Step 3); retrieve the renewed certificate from the Secure Login Server (Step 4); and install it (Step 5). This new feature enables a completely automated process, backed up by a stable solution that is fully supported by SAP, and lowers the risk of unexpected downtime due to certificate issues.
While implementing the certificate lifecycle management feature is a simple and straightforward process, setting it up in every single relevant server component in your SAP landscape would be a tedious process. To prevent this, 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), such as SAP’s host agent or web dispatcher. This tool can be scheduled with operating systems tools, such as the cron utility for Unix systems, and does not mandate the rollout of an updated version of the server component itself, which reduces implementation and testing effort.
Support for Existing PKI Implementations
Customers already operating an enterprise PKI may not want to introduce the Secure Login Server as a second system for provisioning digital certificates. With SAP Single Sign-On 3.0, you do not have to reinvent the wheel — you can reuse your existing enterprise PKI.
To enable this reuse, SAP Single Sign-On 3.0 extends the Secure Login Server to act as a Registration Authority (RA) while the existing enterprise PKI acts as the Certificate Authority (CA), which stores, issues, and signs the digital certificates. With this approach, the RA (the Secure Login Server) verifies the identity of entities requesting that their digital certificates be stored in the CA (the existing enterprise PKI) — the RA does not sign or issue certificates. The PKI types supported by this remote CA feature of SAP Single Sign-On 3.0 include Microsoft Active Directory Certificate Services and products that comply with the Certificate Management over CMS (CMC) protocol (RFC 5272).4
Support for Global Trust Across System Landscapes
Another feature included with SAP Single Sign-On 3.0 is that the Secure Login Server can facilitate the process of rolling out trusted root certificates, a necessary step for customers moving away from self-signed certificates to a CA-based approach.
A major drawback of self-signed certificates is the lack of global trust. When using self-signed certificates, trust between two systems is established by explicitly exchanging certificates between them, a procedure that must be repeated for all system pairs in your landscape. With this approach, costs increase dramatically as landscapes increase in size.
In contrast, when using a PKI, trust between systems comes from the fact that all systems trust the same root of the PKI, a global approach that can be rolled out much more cost-effectively.
Expanded Single Sign-On Support for Mobile Devices
With SAP Single Sign-On, single sign-on with X.509 certificates is not limited to on-premise environments. You can extend the stability and security of this well-established technology to your organization’s mobile devices as well. SAP Single Sign-On offers three provisioning options for X.509 certificates in mobile scenarios:
- You can use the Simple Certificate Enrollment Protocol (SCEP), which is supported by iOS. Using this protocol, iOS client devices can enroll on the Secure Login Server, which can then issue medium- or long-lived certificates for those devices.5
- New with version 3.0, you can download the SAP Authenticator mobile app for iOS, which, in addition to generating time-based one-time passwords (TOTP), supports the provisioning of X.509 certificates to a mobile device.
- As of version 3.0, you can develop your own custom code for certificate enrollment using the REST API provided by the Secure Login Server.
SAP Single Sign-On 3.0 simplifies the integration of the Secure Login Server and SAP Mobile Platform for mobile single sign-on scenarios. This integration extends the existing SAP Mobile Platform experience — with its streamlined development, delivery, security, and management of mobile applications — by adding support for X.509-based single sign-on via the Secure Login Server. Version 3.0 also includes a Secure Login Server API that enables customers to easily handle certificate enrollment from their mobile apps, especially those based on the SAP Mobile Platform software development kit.
In addition, SAP plans to extend SAP Mobile Platform so that it can manage the initial certificate enrollment for devices while shielding the Secure Login Server from outside access. This is intended to allow end users to enable single sign-on on their mobile devices even from outside the corporate network, and ensures that they keep the service even when traveling for an extended period of time.
A New Encryption-Only Mode to Ensure Secure Communication
SAP Single Sign-On offers communication encryption upon login; the same authentication token that grants users access to their workplace IT environment also enables data encryption to prevent unauthorized eavesdropping on network traffic. But what happens, for example, if a user forgets an authorization token, such as a smart card, at home? Or what if the token is not yet available, because the system is still in the test or validation phase?
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. This allows customers to immediately protect data communication during an implementation project, before user-specific configuration is in place, and to ensure data privacy if the end user has lost the smart card holding the required digital certificate, for example. The encryption-only mode is enabled automatically whenever there is no security token available for SNC.
A New, Integrated Web Client for Seamless Authentication
SAP Single Sign-On 3.0 comes with a new version of the Secure Login Web Client, a component of the Secure Login Server that enables user authentication via an SAP GUI connection in a web browser. With a renovated architecture and improved integration, the new Secure Login Web Client enables customers using a SAML 2.0 identity provider or portal as their central authentication server to benefit from a more seamless single sign-on process. This capability facilitates single sign-on support in hybrid scenarios, enabling the integration of cloud-based and on-premise authentication technologies — a SAML 2.0 assertion provided by a cloud-based identity provider, such as SAP Cloud Identity software, can be used to enable seamless and secure authentication and data protection for traditional on-premise clients.
The Secure Login Web Client allows a web page to trigger and monitor the certificate enrollment for Secure Login Server profiles. With the help of the Secure Login Web Client, a business process running in a browser session — either in the cloud or on premise — can trigger seamless authentication for a native client on the user desktop. For example, the Secure Login Web Client can accept a SAML 2.0 assertion as a security token, and in return provision an X.509 certificate for single sign-on to a desktop application, such as SAP GUI.
The previous version of the Secure Login Web Client was based on a Java applet and, for some capabilities, an ActiveX control. As of SAP Single Sign-On 3.0, the Secure Login Web Client no longer depends on Java or ActiveX; instead, it uses capabilities of the Secure Login Client component. This eliminates previous limitations around browser support and significantly increases the number of supported browsers, broadening support for cloud-based applications.6
Looking Ahead: Extending Security to the Network Edge
Going forward, SAP plans to extend the SAP Single Sign-On security infrastructure to the network level. A planned new network edge authentication feature, based on SAP’s web dispatcher and SAP Single Sign-On, will provide integrated, simple, and secure web access control for SAP solutions by controlling access to on-premise systems from untrusted networks.
The feature intercepts all incoming requests and checks if they belong to an already authenticated session. If not, then the request is forwarded to the authentication service of SAP Single Sign-On, where advanced authentication options such as multi-factor or risk-based authentication can be implemented. Only when the session has been successfully authenticated will the web dispatcher allow it to access systems in the internal network, such as the SAP ERP system or other business applications. This significantly reduces the attack surface of internal systems while still making them available to legitimate users, even from outside the corporate network.
The combination of network edge authentication with the single sign-on and risk-based authentication functionality included with SAP Single Sign-On (see the sidebar “What Is Risk-Based Authentication?”) is aimed at meeting the critical needs of customers that are increasingly exposing their on-premise systems to the internet.
Make It Secure — and Keep It Simple
SAP Single Sign-On continues to offer the sophisticated security functionality customers are looking for while placing a strong emphasis on simplification and a sustainable return on investment. Customers benefit from a quick implementation, low operational costs, and the potential to achieve significant savings related to help desk and administration costs. The new features included with SAP Single Sign-On 3.0, such as automated certificate management and enhanced mobile capabilities, are aimed at preserving and extending these key advantages.
As SAP continues to invest in improving its security infrastructure, such as incorporating new cryptographic standards and introducing new risk-mitigation features, SAP Single Sign-On will continue to evolve to help customers adapt to the latest developments within the fast-paced cyber security world. Learn more at http://scn.sap.com/community/sso.
1 For more information on the features and functions of SAP Single Sign-On, see the SAPinsider articles “An Inside Look at the New Features and Functionality in SAP NetWeaver Single Sign-On 2.0” (April-June 2013) and “Simple and Secure User Authentication with SAP Single Sign-On 2.0” (July-September 2015) available at SAPinsiderOnline.com. [back]
2 The Federal Information Processing Standard (FIPS) 140 defines a set of security requirements for products that implement cryptography. Learn more about SAP’s FIPS certification from the SAPinsider article “Is Your Data Properly Protected?” in the January-March 2013 issue (SAPinsiderOnline.com) and the SCN blog “SAP’s Crypto Kernel Receives FIPS 140-2 Certificate” (http://bit.ly/26YfEhO). [back]
3 Note that the first two steps — authenticating to the Secure Login Server and retrieving an X.509 certificate — are not required if the user already has a certificate. [back]
4 Learn more at https://tools.ietf.org/html/rfc5272. [back]
5 More information on issuing certificates for iOS devices is available in the SAP Help Portal at http://bit.ly/1WcAmHG. [back]
6 For detailed information, check the Product Availability Matrix in the SAP Service Marketplace at http://bit.ly/29Pnouv. [back]