Tell us what you think

We want to create the best possible experience for our learners. Your feedback helps us to improve the experience for everyone.

Enabling Single Sign-On

Objective

After completing this lesson, you will be able to enable Single Sign-On

SSO Mechanisms

User Authentication and Single Sign-On (SSO)

The authentication concept for SAP Fiori apps comprises of initial user authentication on the ABAP front-end server, followed by authentication of all requests to back-end systems.

Initial Authentication

When a user launches an SAP Fiori app, the launch request is sent from the client to the ABAP front-end server by the SAP Fiori launchpad. During the launch, the ABAP front-end server authenticates the user by using one of the supported authentication and single sign-on (SSO) mechanisms. We recommend setting up SSO, thereby enabling users to start SAP Fiori apps using their single, existing credentials. As a fallback option, initial authentication can be based on the users' passwords on the ABAP front-end server. SAP provides a dedicated logon handler for form-based logon. After initial authentication on the ABAP front-end server, a security session is established between the client and the ABAP front-end server.

Authentication for Requests in the Back-End Systems

After initial authentication, a security session is established between the client and the ABAP front-end server. Transactional apps can then send OData requests through the ABAP front-end server towards the ABAP back-end server. OData requests towards the ABAP back-end server are then communicated securely by trusted RFC and no additional authentication is required.

For search in SAP Fiori launchpad, applications send InA search requests from the client to the SAP HANA database. These requests can be authenticated with Kerberos/SPNego, X.509 client certificates, or logon tickets. You can configure the ABAP front-end server to issue logon tickets after initial authentication, or you can use your existing portal to do so.

The following authentication and single sign-on (SSO) mechanisms are supported for SAP Fiori apps:

User ID and Password

The AS ABAP user ID and password authentication functions enable authorized users to access the AS ABAP by interactively providing a user ID and password. User ID and password authentication enables you to enforce access control to your AS ABAP systems with an authentication mechanism that offers basic access protection with relatively low complexity of security configuration tasks.

Using user ID and password authentication in complex system landscapes where users must log on to multiple systems, however, increases the user work load from the required multiple entries of user IDs and passwords for system access.

X.509 Client Certificates

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

Authentication with X.509 client certificates provides the following advantages:

It does not require an issuing system during logon, which means that it works well in Internet-facing scenarios.
It is also supported for logon to the SAP GUI. Using X.509 client certificates for both SAP GUI and HTTP access simplifies the Single Sign-On setup within your system landscape.

X.509 client certificates must be distributed to the workstations and devices that are used to access SAP Fiori apps. For mobile devices, this distribution can be performed centrally by a mobile device management software - for example, SAP Mobile Platform.

Kerberos/SPNego

If you access SAP Fiori apps from within your corporate network, you can enable Kerberos/SPNego authentication for the ABAP front-end server. This authentication is particularly recommended if you already have a Kerberos/SPNego infrastructure in place, for example, if you use Microsoft Active Directory.

Kerberos/SPNego authentication provides the following advantages:

It simplifies the logon process by reusing credentials that have already been provided, for example, during logon to the Microsoft Windows workstation. A separate logon to the ABAP front-end server is not required.
It is also supported for logon to the SAP GUI. Using Kerberos for both SAP GUI and HTTP access simplifies the Single Sign-On setup within your system landscape.
It is supported by a growing number of mobile device vendors.

During logon, Kerberos/SPNego authentication requires access to an issuing system (for example, Microsoft Active Directory). As this system is typically located within the corporate network, Kerberos/SPNego cannot be used for most Internet-facing deployment scenarios. To enable Single Sign-On with Kerberos/SPNego authentication from outside your corporate network, you might have to set up a VPN connection.

Kerberos/SPNego is available with the SAP Single Sign-On product, which also provides additional authentication mechanisms, such as X.509 client certificates or a SAML Identity Provider.

SAML 2.0

If you have implemented the security assertion markup language (SAML) version 2.0 as the method of single sign-on (SSO) within your organization, you can configure the ABAP front-end server for use with SAML 2.0.

This authentication method provides the following advantages:

It includes extensive federation capabilities, which means that it works well in scenarios with federated user domains, where trust configuration can be complicated.
It includes extensive user mapping capabilities that enable you to map SAP users based on identity attributes, such as the SAP user name attribute or a user's e-mail address. This means that SAML 2.0 works well for scenarios with multiple user domains.

During the logon process, SAML 2.0 authentication requires access to an issuing system (Identity Provider). To enable single sign-on with SAML 2.0 in Internet-facing deployment scenarios that leverage its federation capabilities, you must ensure that the SAML Identity Provider is securely accessible from outside your corporate network.

SAP Logon Tickets

For logon tickets, you must configure the ABAP front-end server to issue logon tickets. Alternatively, you can use an existing system, such as a portal, in your landscape that already issues logon tickets. In addition, you must configure the required back-end systems (ABAP or SAP HANA) to accept logon tickets. You must also ensure that users in the ABAP system have the same user names as the database users in SAP HANA; user mapping is not supported. As logon tickets are transferred as browser cookies, you can only use this authentication mechanism if all systems in your system landscape are located within the same DNS domain.

SSO using X.509 Client Certificates

Authentication with X.509 client certificates uses a public-key infrastructure (PKI) to securely authenticate users. After users receive their X.509 client certificates from a certificate issuing Certification Authority (CA), they can use them to securely access SAP NetWeaver, as well as non-SAP systems. The SAP NetWeaver and the non-SAP system can authorize access requests, based on an established trust relationship with the CA. In addition, users can use their X.509 client certificates to authenticate their access to systems located on the Internet and within your company's Intranet. Thereby, you can use certificates for authentication in open environments such as the Internet.

In this training, we will use X.509 client certificates to enable SSO. In this case, we have to configure SAP Web Dispatcher to forward SSL certificates for X.509 authentication to the AS ABAP system.

The SAP Web Dispatcher usually terminates SSL connections and later re-encrypts the traffic to send it to the AS ABAP system. Due to the re-encryption, the HTTP request that has to be authenticated is received on an SSL connection that was initiated with the SAP Web Dispatcher’s client certificate.

As a consequence, the SAP Web Dispatcher has to forward the original client certificate (the browser certificate) to the AS ABAP system. This is achieved by putting the original client certificate into an HTTP request header field (by default SSL_CLIENT_CERT).

The AS ABAP system cannot simply take a client certificate from an HTTP request header, because otherwise attackers are able to use abducted certificates. Therefore the AS ABAP system is only allowed to accept client certificates that have been forwarded by a trusted intermediary.

The configuration of SSL certificate forwarding in the SAP Web Dispatcher consists of three parts:

The client (browser) has to send its certificate.
The SAP Web Dispatcher has to accept and forward the client’s certificate.
The AS ABAP system has to accept the forwarded certificate.

For details of the configuration, refer to the SAP Web Dispatcher SSL Certificate Forwarding document that is available at https://help.sap.com/docs/SUPPORT_CONTENT/si/3362959224.html.

Enable Single Sign-On using X.509 Client Certificates

Business Example

Note

In this exercise, when an object name or a value contains ##, replace ## with the number your trainer assigned to you.

Task 1: Sign the Key Pair for SSL – Client

Steps

Open and log on to the Web Admin UI of your SAP Web Dispatcher.
1. On the WTS, start a web browser.
2. Enter the URL of the Web Admin UI of your SAP Web Dispatcher (https://<full qualified SAP Web Dispatcher hostname>:443$$/sap/wdisp/admin).
  - Q team: https://fsqhost.wdf.sap.corp:44320/sap/wdisp/admin
  - P team: https://fsphost.wdf.sap.corp:44330/sap/wdisp/admin
  Note
  You may also use the browser favorite/bookmark prepared at
  Q team: 20 Quality Assurance → fsqhost → 20 WDQ SAP Web Dispatcher Administration
  P team: 30 Production → fsphost → 30 WDP SAP Web Dispatcher Administration
3. At the SAP Web Dispatcher logon screen, provide the following: Usernamewebadm, and your master Password (which should be SAPWebDisp##).
Create a CA request for the SAP Web Dispatcher client PSE (view SAPSSLC.pse), sign it using the SAP Secure Login Server hosted on the SMJ system, and import the response.
Here are some hints on the SAP Secure Login Server acting as CA in this training:
- SAP Secure Login Administration Console (SLAC) URL: https://smhost.wdf.sap.corp:59101/slac
- Path Certificate Management → Sign certificate requests
- Certificate Template: SSL Client Template
- Issuer: SAP Training SSL Sub CA
- Certificate Response Type: PKCS#7
1. In the Web Admin UI, navigate to SSL and Trust Configuration → PSE Management.
2. Ensure that at Manage PSE the option SAPSSLC.pse is selected.
  Caution
  Do not change anything for SAPSSLS.pse!
3. Choose Create CA Request.
4. Mark the complete CA Request (including the lines with the ----- signs) and save it in your clipboard.
5. In a new web browser window/tab, launch the Secure Login Administration Console (SLAC) using the URL https://smhost.wdf.sap.corp:59101/slac.
  Note
  You may also use the browser favorite/bookmark prepared at 80 Application Lifecycle Management → smhost → 90 SMJ Secure Login Administration Console.
6. When asked for credentials, provide the logon data of your train-## user (in client 100 of system SMA, to which the UME of system SMJ is connected to).
7. Within the SLAC, navigate to Certificate Management → Sign certificate requests.
8. Paste the CA Request (content of your clipboard) into the Encoded Certificate Request field.
9. Choose Show Certificate Request.
10. Adjust the following settings:
  - End Validity: increase the suggested value (for example to one year from today)
  - Certificate Template: choose SSL Client Template
  - Issuer: choose SAP Training SSL Sub CA
  - Certificate Response Type: choose PKCS#7
11. When done, choose Sign Certificate.
12. Mark the complete CA Response (including the lines with the ----- signs) and save it in your clipboard.
13. Paste the complete CA Response into the Import CA Response into PSE SAPSSLC.pse field (in the Web Admin UI of SAP Web Dispatcher) and choose Import.
  Caution
  Double-check that SAPSSLC.pse is displayed (left to the Import button). Do not change anything for SAPSSLS.pse!
14. Note that the certificate issuer changed to CN=Secure Login SSL CA, O=SAP Training, C=DE.

Task 2: Add your SAP Web Dispatcher Client PSE to the List of Trusted Reverse Proxies in your SAP S/4HANA System

Steps

Open the extended maintenance mode for the default profile of your SAP S/4HANA system.
1. Log on to your SAP system using the train-## user.
2. Start transaction RZ10.
3. At the Profile field, choose the DEFAULT (using the F4 help).
4. Select Extended maintenance and choose Change.
Note the already prepared parameter icm/trusted_reverse_proxy_0. Create a new parameter icm/trusted_reverse_proxy_1 with the corresponding settings for your SAP Web Dispatcher system.
1. Choose Parameter → Create(L) (F5) from the menu (or button Parameter Create (F5), alternatively) to create a new parameter.
  Hint
  The new parameter is inserted above the cursor position. For optical reasons, you may select the line below the prepared parameter icm/trusted_reverse_proxy_0before creating the new parameter icm/trusted_reverse_proxy_1.
2. As Parameter Name, enter icm/trusted_reverse_proxy_1.
3. As Parameter Value, enter SUBJECT="<Subject>", ISSUER="CN=Secure Login SSL CA, O=SAP Training, C=DE" and replace <Subject> with the string you have determined in the previous step.
  - Q team: SUBJECT="CN=WDQ, OU=SSL CLIENT",ISSUER="CN=Secure Login SSL CA, O=SAP Training, C=DE"
  - P team: SUBJECT="CN=WDP, OU=SSL CLIENT",ISSUER="CN=Secure Login SSL CA, O=SAP Training, C=DE"
  Caution
  Make sure to enter both the parameter name and value correctly (including upper- and lowercase).
4. Choose Copy.
5. Choose Back (F3).
6. Choose Yes in the Save changes? popup.
7. Choose Copy.
8. Choose Back (F3).
9. Choose Save.
10. In the Save Profile – Errors detected in parameter values. Display values? popup, choose No.
11. In the Activate Profile – Do you want to activate the profile? popup, choose Yes.
12. Choose Continue (twice).
Restart all ICM processes of your SAP system.
In productive environments, you should not restart the ICM process this way (see SAP Note 2367439Avoid manual restart of ICM process).
1. Continue working in your SAP system.
2. Enter transaction SMICM.
3. In the menu, choose Administration → ICM → Exit Soft → Global.
4. In the popup Are you sure you want to restart all ICM processes in the system?, choose Yes.
5. After the ICM restart, check if the parameter icm/trusted_reverse_proxy_1 shows up with the correct value at Goto → Parameters.
  Hint
  You will have to scroll down; the list of parameters is sorted alphabetically.

Result

Your SAP system trusts your SAP Web Dispatcher. For details on Multiple Trusted Reverse Proxies, see SAP Note 2052899.

Continue to quiz