Secure Authentication and SSO for SAP

In this blog we will cover essential aspects and principles of SAP Single Sign-On (SSO) with special relation to SAP S/4HANA systems.

Introduction

Access to IT systems must be restricted and controlled. User identification and authentication is the first line of defense because it prevents unauthorized access. In this context, authentication is a core element of information security that is necessary for establishing user accountability. The principle of no authorization without prior authentication applies to SAP systems as well. Before a resource can decide whether someone has access, the identity of a user (or service) has to be validated and assigned to a specific user account on the system.

Authentication is linked closely to the life cycle of user identities in an organization. A centralized approach for user and authentication management guarantees compliance with access governance, security policies, and other compliance requirements, depending on the area an SAP company operates.

All users have to authenticate against a central system first to receive a security token required for accessing the requested target resources. Depending on the application type and communication protocol used such as DIAG/RFC or HTTP – various mechanisms for obtaining the required security tokens can take place and different systems are involved in the process of authenticating or verifying the users’ identity.

A securely established authentication infrastructure bundles identity information for your users in a central location which supports single sign-on (SSO) across devices, resources, and apps in the cloud and on-premises. Further advantages are centralization of user account management and control of identity and security for the whole SAP and Non-SAP application landscape.

This approach of delegated user authentication allows different primary authentication mechanisms including SSO and multi-factor authentication depending on various rules configured by the organization for a given application. The security token contains attributes required for user authentication and could also allow authorization by providing group membership information that are transferred as part of the security token. This way companies can add or remove access to applications based on group memberships. Depending on the SSO technology and target application, such authorization attributes could be passed to the target resources which in turn utilizes this information to allow dynamic role assignments of users.

Other important aspects are automated provisioning and de-provisioning of users and their authorizations. Just imagine being able to provide access to all required SAP systems and related applications for new employees based on their job role and fully automated and supported by workflows, with the help of an Identity Management system. In particular, imagine being able to prevent access to all your SAP systems and applications operated within your organization’s intranet or even your cloud services – without having to manually lock the respective user account in every single application.

It should now have become clear that a proper single sign-on implementation offers many advantages and convenience associated with it.

The need for secure authentication and SSO

User ID and password are the standard authentication mechanism supported by most applications and servers, including SAP NetWeaver systems and SAP S/4HANA. On top of that, modern SAP systems such as S/4HANA allow making use of many different mechanisms to support secure user authentication and single sign-on (SSO) capabilities. At first glance, authentication doesn’t sound like a big issue. Just enter username and password, and you are good to go. However, this standard procedure has some weaknesses mitigated with the help of SSO.

Without having SSO in place, users normally would first log in to an OS and subsequently into various applications. For each resource, a separate set of credentials is required to gain access. This often results in a situation where users’ ability to remember passwords is significantly reduced. It increases the chance that users will write them down somewhere. As a result, users are left alone concerning the secure handling of their dozens of passwords. And for sure, you do not want your business users to be prompted for passwords over and over again when accessing the various SAP systems and applications required throughout the normal workday.

To address this situation, the concept of SSO can help. It aims to determine which person is sitting in front of the device and guarantees the authenticity of the user identity and the SAP application server. Also, it allows protecting confidentiality and integrity during the whole authentication process. The use of secure communication between all components is an integral part as the aim is to implement end-to-end encryption and secure authentication of systems, interfaces, and users. Connections have to be encrypted when passwords, personal or sensitive data are transmitted. This principle applies to communication between SAP systems as well as client-to-server communication, for example, using the SAP GUI or the browser.

Following the basic principle of the client-server architecture, the authentication process is negotiated between the client front-end and the back-end SAP application server. However, with SSO in place, other components are involved in the overall authentication process. SSO allows outsourcing or delegating the authentication that normally would take place on every single application server, to a central system. That instance verifies the users’ identity and supports various primary authentication methods. As a result, user authentication is performed only once. An example of such authentication entities could be the central Active Directory or a SAML identity provider (IdP) that is linked to the corporate user store. This way, an organization keeps control of identity and security easier than protecting each single SAP system. After the so-called primary authentication, accessing all connected SAP systems and applications will be carried out automatically. All this is possible based on a security token that is issued by the central system.

The exchange of such security-sensitive information requires the security token itself to be protected against unauthorized access and modifications to ensure confidentiality and integrity. Furthermore, the applications have to trust the token issuer to validate the security token and thereby identify a user’s identity. Access to the respective SAP systems can be restricted to accept only security tokens such as X.509 client certificates, a Kerberos ticket, or a SAML assertion. In any case, the target application can be sure the user had to identify himself beforehand to get in possession of the SSO-token. In some circumstances and based on the security requirements, this may involve additional factors like when using multi-factor-authentication.

The implementation of SSO into the SAP landscape has no direct effects on the authorization. While the existing SAP roles and authorization concept stays valid, the default user authentication method is replaced by more secure standards. Using SSO offers many advantages, eliminates the password-related frustrations, and allows simpler administration of the SAP user accounts, as no passwords need to be distributed or maintained. The result is a higher acceptance of the end-users. SSO has a positive impact on productivity as the normal user-workflow is not disturbed by looking up for credentials and logging into individual applications manually each time.

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 that are running within such hybrid SAP environments are 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.

Authentication challenges related to SAP S/4HANA

While the system architecture of SAP S/4HANA is still based on the SAP NetWeaver Application Server ABAP technology, now S/4HANA applications may run on top of it, utilizing the SAP HANA database. Additional components that are part of a typical SAP S/4HANA infrastructure are the SAP Web Dispatcher and the SAP Gateway plus the SAP HANA database itself.

From a security perspective, the concepts related to authentication and SSO mostly remain unchanged with SAP S/4HANA. Yet it is important to understand, that SAP HANA is not just a new database, but on-top provides its own application server SAP HANA extended application services, advanced model, in short XSA. This development and runtime environment as part of S/4HANA allows certain applications to run natively on it with new security considerations for administration, user management, authentication, and authorizations.

All of this must be taken into account when securing the infrastructure, which in turn affects the management and provisioning of users and authorizations. In particular, various different authentication methods can be used, and since not all components support the same methods it is of vital importance to have a good understanding of the whole SAP S/4HANA infrastructure. As an SAP system administrator or security architect, you should incorporate all use-cases where authentication and SSO are required and get familiar with the different interfaces that are used to access the system components.

With SAP S/4HANA, browser-based HTTP access is a central element that takes place primarily through the SAP Fiori interface, which is based on SAPUI5 that is SAP’s HTML5-based development toolkit. Compared to traditional SAP R/3 or SAP ECC systems, with S/4HANA access to Fiori applications has become a prevalent use case. The increased usage of web-based access through HTML in addition offers completely new possibilities for providing access and exposing applications to the internet. Besides that, the access for DIAG and RFC applications like SAP GUI is still unchanged and related to the SAP NetWeaver application server and its existing interfaces.

If you plan the implementation of single sign-on for your SAP landscape, you should consider a smooth approach. It is recommended to configure your SAP systems in such a way that standard authentication with username and password as well as single sign-on are possible in parallel. This enables SSO to be implemented in a phased approach. In a later step, the use of encrypted communication protocols as well as SSO mechanisms can be enforced system-wide and even for specific applications and users.

Common scenarios to access SAP S/4HANA applications

SAP S/4HANA enables you to use several user authentication mechanisms that give you the flexibility to customize user authentication policies for your security needs with minimal configuration effort. S/4HANA offers various access layers requiring user authentication and supporting SSO, such as applications running on the HANA database. Here, we look at the two most important scenarios to access S/4HANA applications.

First, we look at authentication for web-based applications and provide information about recommended authentication mechanisms when using HTTP based front-end clients such as SAP Fiori, or ABAP Web Dynpro. Secondly, we cover SAP GUI and available authentication mechanisms for interactive user logon when using the SAP GUI as a front-end client.

HTTP-based applications (HTTP/TLS)

When deploying SAP Fiori apps, the UI components are being installed on the SAP Fiori front-end server (FES) as a hub or embedded deployment. The SAP Gateway component on the front-end server handles OData service calls to access business data on the back end. When implementing SAP S/4HANA on-premises, the embedded SAP FES deployment is the recommended scenario. It reduces complexity for upgrade operations and helps to avoid version dependencies between the SAP FES and the S/4 HANA backend. In SAP S/4HANA cloud deployments, the Software as a Service solution comes with built-in SAP Fiori experience and launchpad and thus follows the same recommendation.

The authentication concept for SAP Fiori comprises initial user authentication that terminates on the SAP Fiori front-end server (SAP FES) followed by authentication of all requests to back-end systems. With SAP S/4HANA, you must configure the desired single sign-on mechanisms for user initial user authentication on the SAP FES, which is the Gateway component. User authentication always terminates here, and a security session is established with the client (browser).

SAP S/4HANA supports the following most important authentication and single sign-on mechanisms for SAP Fiori apps: SAML 2.0, SPNEGO, X.509 certificates, or SAP Logon Tickets.

After initial authentication, the SAP Fiori launchpad can send subsequent requests to the ABAP back-end server where additional SSO mechanisms for authentication may be required depending on the type of applications. SAP Fiori Apps send OData requests towards the ABAP back-end servers communicated securely via trusted RFC allowing it to propagate the user. For requests from the client to the SAP HANA database, other mechanisms such as SPNEGO, X.509 certificates, or logon tickets may have to be set up.

SAP GUI (DIAG/SNC)

To log on to an SAP S/4HANA system for dialog access from SAP GUI, by default, users provide a user ID, password, and the SAP client number. That information is transferred through the network without encryption. To secure networks, SAP provides the Secure Network Communications (SNC) interface that enables encryption, transparent authentication, and SSO using security tokens.

Instead of using the traditional user ID and password-based authentication, any SAP company should make use of token-based authentication towards SAP. As a prerequisite, the target SAP system must use Secure Network Communications (SNC) and can validate the provided security token, which is either an X.509 client certificate or Kerberos ticket. Finally, a mapping is required to define which security token belongs to which SAP user and SAP client.

This way, the SAP user credentials are no longer saved locally or sent across the network for the connection between the SAP GUI and the SAP S/4HANA system. Thereby, authenticity, confidentiality, and integrity protection are guaranteed.

Core interfaces und technologies for SSO

Secure Network Communications (SNC) and Transport Layer Security (TLS)

In the SAP standard, the communication is not encrypted, this affects both the SAP GUI and communication between the browser and web-based UIs.

The SAP proprietary protocols DIAG and RFC do not cryptographically authenticate client and server, nor do they encrypt network communication. Passwords transmitted over the network can be eavesdropped on. Additionally, due to missing mutual authentication, rogue systems could intercept network traffic, manipulate content, and forward it to legitimate servers, which makes SAP vulnerable for man-in-the-middle attacks (MITM).

The communication between client and server and between SAP servers can be protected using a secure symmetric encryption algorithm. The basis for this technology is provided by the SAP interface Secure Network Communications (SNC) which makes it possible to establish a secure connection to the SAP system through encryption and providing mechanisms for SSO.

SNC provides cryptographically strong mutual authentication, integrity protection of transmitted data, and encryption of network traffic. It ensures the communication between the SAP GUI running on the user’s computer and the SAP system. Based on the GSS-API interface, a cryptographic library is used to encrypt the data at the Network Interface (NI) protocol level and to support either Kerberos or X.509 based authentication and single sign-on with an SAP system.

The same applies to transport layer security (TLS) that is required to guarantee transport security and supports additional authentication mechanisms for applications consumed via the HTTP protocol.

SSO using X.509 client certificates

SAP S/4HANA and the SAP NetWeaver platform supports the usage of client certificates for user authentication based on the well-known internet standards X.509 and Transport Layer Security (TLS). Authentication takes place using the underlying TLS protocol while no user intervention is necessary, which enables SSO for the end-user. When using CBA (certificate-based authentication) administrators can give their users access to SAP and non-SAP resources without having to enter credentials.

Users need to receive their client certificates from a certification authority (CA) as part of a public-key infrastructure (PKI). The company must take care of the secure provisioning and management of the whole certificate lifecycle. Compared to Kerberos tickets or SAML assertions, an X.509 certificate has a relatively long validity time. Therefore consider methods for securing private keys and to handle certificate revocation. Due to this fact, the use of certificates is usually more complex. As the client certificates are exchanged during the TLS handshake, a reverse proxy that may terminate the TLS in front of the SAP system must forward the certificates in some way, which adds additional layers of complexity.

Nevertheless, using certificates for user authentication, especially in heterogeneous and mixed environments, historically offered the best support, especially for older NetWeaver releases that you may encounter from time to time. It is important to consider two prerequisites when using CBA. First, the client certificate needs to be mapped to a user ID that exists in the SAP system, and second, the client certificate needs to be accepted in terms of trust.

To enable certificate-based authentication, you have to add the certificate chain from the corresponding issuing certificate authority (CA) to your SAP systems’ trust store. This establishes a trust relationship that the system relies on to verify the authenticity of your users when they authenticate through CBA. After you configure CBA in your SAP system, you can use it as an authentication requirement for selected applications such as your Fiori Launchpad or the SAP GUI.

SSO using on Kerberos/SPNEGO

The Secure Login components provided with SAP Single Sign-On 3.0 offer a variety of possible use cases. The most adopted scenario is the Kerberos/SPNEGO authentication to SAP systems and applications. It utilizes the Windows process that authenticates users when they log onto their computers in a certain domain. Kerberos employs several systems in the landscape and uses cryptographic mechanisms for authentication, thereby overcoming the disadvantages of weaker authentication mechanisms such as user ID and password.

Through the integration of the SAP systems into the Active Directory Forest of an organization, applications like SAP GUI or the client-browser are enabled to request the required session tickets for downstream authentication to kerberized target services.

The SAP NetWeaver platform supports Kerberos with the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) through the SAP CommonCryptoLib, enabling authentication with web clients such as web browsers. SPNEGO is to be considered as a protocol to negotiate the best common GSS-API mechanism between two communication peers and is used for browser-based authentication scenarios.

The Kerberos authentication process relies on the exchange of session tickets between a client component like the SAP GUI or a web-browser and the SAP application server. Those session tickets are issued by a Kerberos Key Distribution Center (KDC) when the user attempts to connect to the SAP system from the SAP GUI or a browser. The KDC itself establishes and verifies the user identity eliminating the need for manual authentication with user ID and password against SAP systems. As the SAP authentication no longer requires passwords communicated over the network, the credential confidentiality, and integrity protection is guaranteed.

The Microsoft Active Directory is the central authentication system for all SAP users in this SSO scenario. The target SAP systems can validate these Kerberos tokens with their local (so-called) Kerberos Keytab. The SAP backend systems do not need to have a network connection to the Active Directory to verify the Kerberos Service Tickets. This scenario is supported even in architectures consisting of multiple domains and forests. To ensure a correct implementation make sure to understand the Active Directory landscape involved domains and forests and the trust-relationships between them.

SSO based on Kerberos tickets is a well-supported scenario by many SAP solutions which include most of the components part of the SAP S/4HANA system landscape. Kerberos is tied strongly to a company’s intranet and does not support most internet-facing deployment scenarios. For this reason, SAML is gaining in importance. Here both the authenticating instance and the application server can be operated externally, supporting more flexible user federation scenarios beyond the B2E use case.

SSO using SAML 2.0

Security Assertion Markup Language (SAML) and federated single sign-on is by far the most flexible and adopted SSO technology supporting on-premises and cloud applications. It is an XML-based authentication framework that is specified primarily for browser-based access. It uses a dynamic token model that works based on assertions.

It is essential to understand that SAML-enabled web applications delegate user authentication to a central instance. The identity provider (IdP) proves that a subject (user) has identified himself. Users authenticate to the IdP by different means, which in turn may involve various supported SSO methods or additional authentication factors. A successful authentication triggers the creation of a SAML assertion issued by the IdP that certifies a user’s identity against the target application, termed as the SAML service provider (SP). IdP and SP have to establish a mutual relationship of trust. That involves the exchange of so-called SAML metadata on both sides containing the required Entity IDs, protocol endpoints, and cryptographic keys.

In other words, the service providers are outsourcing the task of user authentication to the identity provider. The identity provider maintains a list of service providers to which the user has authenticated. If there is a valid session at the IdP, a single sign-on to further target applications is possible. The client that wants to access the resource must be HTTP-compliant, such as browser-based desktop applications or mobile devices.

SAML assertion contains one or more statements about the identity and authorizations of users. They are transferred from the IdP to the SP, usually through the client-browser. Each assertion must be checked and verified by the service provider, like the S/4HANA system, which guarantees the integrity and authenticity. After successful verification, the service provider analyzes the actual content and then decides as to whether and which access to grant the user.

Especially in the field of modern cloud applications provided on SAP’s Cloud Platform or S/4HANA Public Cloud Edition, the authentication of the users usually takes place upstream against a trusted Identity Provider. The Security Assertion Markup Language 2.0 (SAML) technology used here enables a user to be identified using various ID attributes like username or email address (authentication). In addition, the SAML standard may be used to provide information about existing group memberships from the IdP to the application. That enables the service provider to assign users to specific authorization roles dynamically (authorization).

Most organizations have Active Directory in place for a long time, they are expanding this infrastructure towards the cloud by implementing Microsoft Azure Active Directory. It provides identity management capabilities including SAML IdP supporting multi-factor authentication, device management, and many more. Azure Active Directory easily enables SSO across cloud and on-premise applications with the use of SAML 2.0 authentication. This allows organizations to securely expose applications like the SAP Fiori Launchpad from the internet in different manners, whether if they are running S/4HANA on-premise or in the cloud.

S/4HANA and the SAP NetWeaver platform are supporting any SAML 2.0-compliant identity provider like the SAP Identity Authentication service, Microsoft ADFS, or Azure AD. This way, the IdP component can be seen as a central authentication hub for all SAML-enabled enterprise applications.

Benefits of single sign-on for SAP applications

A securely designed SAP single sign-on setup massively improves the entire security of user identities and SAP systems. In such the usage of encrypted communication protocols is mandatory from an end-user perspective. Potential attacks are made considerably more difficult because a security token is required for authentication against the SAP systems.

Basically, with SSO you have to differentiate between the primary authentication and a downstream token-based authentication against the target application. Where SSO is not wanted or in other words one-factor authentication is not sufficient from a security perspective – other methods of primary authentication could be enforced. This happens mainly by utilizing SAML and redirecting the users’ browser for user authentication against a central identity provider. This IdP in turn may support its own SSO procedures and risk-based authentication framework which enforces multi-factor authentication if required. After successful authentication, the appropriate token for downstream authentication is returned.

After the implementation of SSO, most end-user accounts within an SAP system no longer need to have passwords. All applications on the SAP systems being consumed via the DIAG, RFC, or HTTP protocols must be taken into account. The positive side effect, if the passwords were deactivated, their associated hashes in the database are removed too.

Recommendation: The use of token-based authentication (Kerberos, X.509, or SAML) should be favored (or enforced) when accessing traditional SAP NetWeaver as well as applications based on SAP S/4HANA (exceptions from SSO are possible). Furthermore, unencrypted connections to the systems should no longer be allowed. Finally, the target of a comprehensive SAP SSO design is to ensure confidentiality, integrity, and authenticity throughout the whole authentication process.

Conclusion

In principle, the complexity of the SSO solution does not necessarily depend on the size of the company or the number of SAP systems and users. Rather, all applications must be taken into account and integrated with regards to various criteria and individual security requirements. This could mean that several SSO procedures are used in parallel or even additional factors are required to get access to certain SAP applications.

To cover all SSO scenarios and use cases required within a complex and large SAP environment, it is highly recommended to make use of the SAP Single Sign-On product (SAP SSO). SAP Single Sign-On 3.0 centralizes and greatly simplifies the way users log on to systems and applications in your IT landscape. It includes mobile single sign-on with the SAP Authenticator app, risk-based authentication using access policies, or two-factor authentication. The solution provides strong encryption, secure communication, and single sign-on between a wide variety of SAP components. It covers SAP GUI on SAP NetWeaver platform with Secure Network Communications (SNC) as well as HTML-based user interfaces on SAP NetWeaver platform with Transport Layer Security (TLS) or even third-party application servers that make use of standard SSO technologies.

Find out more about the SAP SSO 3.0 solution:

Read more about our expertise related to SSO in on-premises and cloud environments:

With regards to the ongoing development of the SAP Single Sign-On solution and the possibility of using the core technologies X.509 certificates, Kerberos/SPNEGO, and SAML 2.0, it is ensured that companies are prepared to implement secure authentication for their SAP S/4HANA systems.

Besides, the SAP Business Technology Platform Identity Services are frequently used to support cloud related SSO use cases. SAP Single Sign-On and SAP Cloud Identity Services (Identity Authentication) both support secure authentication and single sign-on.

With the support of common industry standards and the interfaces available in today’s SAP S/4HANA landscapes, further SAP, or non-SAP applications and SSO components such as external identity providers or MFA solutions can be integrated into an overall single sign-on concept. 

Finally, keep in mind that SSO only is a part of an overall Identity Access Management (IAM) solution that supports access governance and provides required interfaces to interconnect with Identity Management systems (IDM) and other security components allowing managing the whole identity lifecycle, even within a hybrid SAP landscape.