3.2    Single Sign-On and User Authentication

Now that we’ve covered some of the basic concepts of security in the SAP Fiori system, we can dive into some advanced security concepts of the authentication strategies that are supported in the SAP Fiori landscape. In this section, we’ll give you an overview of various advanced security-related system components based on Kerberos/SPNEGO, Security Assertion Markup Language (SAML) 2.0, SAP logon tickets, and X.509 certificate authentication configuration.

The SAP Fiori system needs to know the identity of a user. Knowing a user’s identity allows the SAP Fiori system to provide a customized experience and grant the user permissions to access the data from the back-end servers. The authentication concept for SAP Fiori apps includes initial user authentication on the ABAP front-end server, followed by the authentication of all requests to the back-end systems. Table 3.3 shows different types of SAP Fiori apps that support different authentication methods for SSO.

Authentication is a process in which the credentials provided by a user from the client/browser are compared to those on file in a database of authorized users. After the user is authenticated, system then creates a security session between the client and the SAP Gateway server for that specific user.

Authentication Method for SSO Transactional Apps Fact Sheet Apps Analytical Apps (via SAP HANA XS) Search (Fact Sheet) Apps
User name/password Yes Yes Yes Yes
SPNEGO/Kerberos (with SAP NetWeaver SSO) Yes Yes No No
SAML 2.0 Yes Yes No No
SAP logon tickets Yes Yes Yes Yes
X.509 Yes Yes Yes Yes

Table 3.3    Authentication for Requests in Front-End Server

Important!

Setting up security and authentication is a huge topic, so we recommend that you always refer to the documentation provided at http://help.sap.com for an in-depth understanding and the most up-to-date information on this topic.

3.2.1    Kerberos/SPNEGO

Kerberos/SPNEGO is a network authentication protocol developed by MIT, and it’s a robust protocol that protects from any form of attack. In a nutshell, Kerberos offers the following advantages:

If you’ve already implemented Kerberos/SPNEGO (e.g., Active Directory), then this authentication mode is recommended. You can enable Kerberos/SPNEGO authentication for the ABAP front-end server to access the SAP Fiori apps in your corporate network. Because the Active Directory system is typically located in your corporate network, Kerberos/SPNEGO authentication can’t be used outside your corporate network. To enable SSO outside your corporate network, you might have to set up a virtual private network (VPN) connection.

Configuring Kerberos/SPNEGO

The complete detailed steps for configuring Kerberos/SPNEGO authentication are documented in the IMG on the SAP Help Portal at http://help.sap.com/sapsso.

The following are some of the advantages of using Kerberos/SPNEGO authentication:

Important!

The configuration of the Kerberos/SPNEGO authentication requires significant involvement from your Active Directory administration team.

3.2.2    Security Assertion Markup Language 2.0

SAML is an XML-based standard for communicating identity information between organizations and service providers. It’s used for enabling the secure transmittal of authentication tokens and other user attributes across domains.

If you’ve already implemented SAML version 2.0 as the method of SSO, you can configure the ABAP front-end server for use with SAML 2.0 in conjunction with identity provider (IDP) software such as SAP IDP, Ping Federate, or Microsoft’s Active Directory Federation Services (ADFS). In comparison with Kerberos authentication, SAML 2.0 authentication is relatively easy to configure. To enable SSO outside your corporate network (Internet-facing), you must make sure that the SAML IDP is securely accessible from outside your corporate network.

The following are some of the advantages of using SAML 2.0:

Important!

In the SAP Fiori system landscape, SAML 2.0 is supported only for communication with the ABAP front-end server—not for SAP HANA.

Let’s take a closer look at SAML authentication flow. The most basic SAML architecture involves three main objects: a user, an IDP, and a service provider (see Figure 3.5). Users will need to authenticate themselves in a process known as service provider-based authentication.

SAML AuthenticationSAMLauthentication

Figure 3.5    SAML Authentication

Figure 3.5 illustrates the following steps for service provider-based authentication:

  1. First, the user attempts to access the application (i.e., the client sends a request to SAP Gateway server via a proxy server).
  2. The federated identity software running on the IDP kicks into action, and the SAML 2.0 IDP server validates the user credentials, allowing the user to be properly authenticated.
  3. The IDP then constructs and sends a specially formatted message containing information about that user (SAML artifact) back to the SAP Gateway server. SAP Gateway then determines that the message came from a known IDP and creates a session for that specific user in SAP Gateway, allowing the user direct access to that application.
Note

The whole process of the SAML message being created and the operation between the IDP and SAP Gateway is completely hidden to users. All they see is SAP Fiori launchpad after clicking on the URL or app.

The complete detailed steps for configuring SAML 2.0 authentication are documented in the IMG on the SAP Help Portal at http://help.sap.com/nw74. Once there, choose Application Help • Function-Oriented View • Security • User Authentication and Single Sign-On • Integration in Single Sign-On (SSO) Environments • Single Sign-On for Web-Based Access • Using SAML 2.0 • Configuring AS ABAP as a Service Provider.

3.2.3    SAP Logon Tickets

SAP logon tickets are the cookies of a session and are stored in the client’s browser. For SAP logon tickets, you have two options: Either use the existing system, such as a portal that already issues logon tickets, or configure the ABAP front-end server to issue logon tickets. You must also configure the required back-end systems (ABAP or SAP HANA) to accept logon tickets. SSO then provides access to the SAP HANA database (or any database) from any front-end application without needing to log in. The SAP HANA trust store contains the root CA used to sign the trusted certificates required for SSO authentication.

Important!

User mapping isn’t supported, so you must ensure that users in the ABAP system have the same user names as the database users in SAP HANA. If a customer uses all three types of SAP Fiori apps, make sure the user name complies with the stricter restriction rules from SAP HANA.

As we explained in Chapter 2, Section 2.6.5, from SAP NetWeaver 7.4 SP 06, you can even perform system configuration tasks automatically by using predefined task lists. You can use the SAP_SAP2GATEWAY_TRUSTED_CONFIG task list to create a trusted connection from an SAP system to an SAP Gateway system. Follow the process from Chapter 2, Section 2.6.5, and the system will guide you through the configuration of the tasks when you execute a task list (see Figure 3.6).

The complete detailed steps for configuring the SAP logon token authentication are documented in the IMG on the SAP Help Portal at http://help.sap.com/nw74. Once there, choose Application Help • Function-Oriented View • Security • User Authentication and Single Sign-On • Integration in Single Sign-On (SSO) Environments • Single Sign-On for Web-Based Access • Using Logon Tickets • Using Logon Tickets with AS ABAP • Configuring AS ABAP to Accept Logon Tickets.

Predefined Task ListTasklist

Figure 3.6    Predefined Task List

After the configuration is completed, the ABAP front-end server acts as a ticket-issuing system, and the ABAP back-end system acts as a ticket-accepting system. The following are the authentication flow steps between the ABAP front-end and ABAP back-end servers:

  1. The user logs in with his user name and password to the ABAP front-end server.
  2. The ABAP front-end verifies the user name and password. After the authentication is successful, the user is logged on to the system and issued a logon ticket.
  3. The user’s web browser then stores the logon ticket and uses that ticket for authentication on the ABAP back-end system.
  4. The web browser then sends the issued logon ticket with the user logon ticket to the ABAP back-end server.
  5. The ABAP back-end server verifies the tickets.
  6. If the tickets are valid, then the ABAP servers provide access to the user.
SAP Logon Tickets

SAP logon tickets are transferred as web browser cookies; therefore, you can only use this authentication if all the systems in your landscape are located within the same DSN.

3.2.4    X.509 Certificate

If your customer has implemented a public key infrastructure (PKI) for user authentication, you can use X.509 certificates by configuring the required back-end systems (ABAP or SAP HANA) to accept them.

The following are some advantages of using X.509 certificates:

To run SAP Fiori apps on desktops and mobile devices, X.509 certificates must be distributed to them. For mobile devices, X.509 certificates are distributed by mobile management software.

To minimize security risks, SAP recommends implementing a method to revoke X.509 certificates, because they remain valid for a relatively long time.