This wiki page describes implementing a single sign-on mechanism with SAML 2.0 in a network including an ABAP system which does not support SAML 2.0 authentication. Explanations are based on a sample real-life scenario.

In summary, you need the following products to try out this scenario:

• SAP NetWeaver Application Server Java 7.2/7.3 (the service provider in the scenario)
• An identity provider, such as SAP NetWeaver Identity Management 7.2 or SAP NetWeaver Single Sign-On or another vendor’s identity provider
• An ABAP system, such as SAP NetWeaver Application Server ABAP 7.0 or 6.40 or system which supports SAP logon tickets (MYSAPSSO2 Cookie, SSO2 Tickets).

Table of contents 

Scenario Description

Hosting company “Hosting4All” hosts products/applications for a number of customers – the companies A, B,… , Z. These applications run on an ABAP system. Each customer uses a separate ABAP client so that there is isolation between companies’ data.

Users from different companies have accounts at the ABAP system and can log in with username and password. However, “Hosting4All” would like to make the users’ life easier by introducing Single Sign-On to the ABAP system. This would prevent users from having to re-enter username and password for accessing each separate application.

“Hosting4All” decides to introduce SAML 2.0 authentication and in this way achieve single sign-on to the ABAP system. Each company A, B, …, Z already has a SAML 2.0  identity provider ready to authenticate the users from this company. Users from companies A, B, …, Z do not have accounts on the SAML 2.0 service provider system of “Hosting4All” and customer companies do not want to provision the accounts. Users from companies A, B, …, Z only have accounts on the ABAP system and identity provider is aware of these accounts. 

To achieve its goal, “Hosting4All” needs to have SAP NetWeaver Application Server Java 7.2/7.3 with the necessary configuration.

eLearnings Containing All the Steps

All the steps described in this wiki page are also available as video tutorials in the eLearning area:

Configuring the SAML 2.0 Service Provider
Configuring a SAML 2.0 Identity Provider
Configuring Trust on the Identity Provider Side
Configuring Trust on the Service Provider Side
Exporting the SAP Logon Ticket
Using Single Sign-On

Creating SAML 2.0 Service Provider on “Hosting4All”

Video tutorial with the steps: Configuring the SAML 2.0 Service Provider
The steps below describe the creation and initial configuration of SAML 2.0 service provider.

1. Open http(s)://<java server host>:<port>/nwa -> Configuration -> Authentication and Single Sign-On
2. Select “SAML 2.0” tab and click “Enable SAML 2.0 Support” pushbutton.
3. Enter service provider name and click "Next".
4. Change setting “Legacy Systems Support (Issue Logon Ticket)” to “On”
   Having legacy system support setting set to “On” means that service provider will issue SAP Logon ticket which could be consumed later by the ABAP system.
   More information can be found at help.sap.com .
5. Now you need a signing key pair for the local provider. It will be used as encryption key pair as well. To create service provider key pair, click the "Browse" button next to the "Signing Key Pair" field.
   
   The key storage opens.
   Here are the steps for creating the key pair:
   1. Click "Create".
      
   2. Enter a descriptive "Entry Name" and click "Next". (You may configure other settings here, if you find it necessary).
      
   3. Enter at least the commonName and countryName for the key pair. You may also add other fields, if necessary. Click "Finish".
      
      The details of the created key pair are displayed.
   4. Click "OK".
      
6. Click "Next" pushbutton to go to the next step of the wizard:
   
7. Change selection mode to “Automatic” and click “Finish” pushbutton:
   
   More information regarding identity provider discovery settings can be found at help.sap.com .
8. Download service provider metadata so that you can use it to setup the trust to the service provider at identity provider side.
9. Export the service provider signing certificate, necessary for metadata verification at identity provider side
10. Click “Export Entry” pushbutton. Select export format “PKCS#8 Key Pair” and download the certificate:
    More information regarding metadata access can be found at help.sap.com
    Send the identity provider both the metadata file and the exported certificate so that trust between identity provider and service provider can be configured.

Creating SAML 2.0 Identity Provider

To setup the scenario, any SAML 2.0 identity provider can be used.
For more information how to setup SAP-vendored identity provider see video Configuring a SAML 2.0 Identity Provider

Configuring Trust on the SAML 2.0 Identity Provider Side

In this step, you need to configure the identity provider to trust the service provider. For SAP-vendored identity provider see video Configuring Trust on the Identity Provider Side

Configuring Trust on the SAML 2.0 Service Provider Side

Video tutorial with the steps: Configuring Trust on the Service Provider Side
The steps below describe the configuration between the SAML 2.0 service provider of “Hosting4All”, and the SAML 2.0 identity provider of a customer, for example company A.

1. Open http(s)://<java server host>:<port>/nwa -> Configuration -> Authentication and Single Sign-On. Select “SAML 2.0” tab and go to “Trusted Providers” link. Click “Add” pushbutton and choose “Uploading Metadata File”
2. Browse identity provider metadata file
3. As metadata is signed by a certificate that is self-signed, in order to verify it we need to select a copy of the certificate used to sign the metadata
4. Click “Next” pushbutton and you should see identity provider name
5. Just go through the wizard by leaving the default values. At the last step click "Finish" pushbutton and the new trusted identity provider will be created.
     
   More information on trusting an identity provider can be found at help.sap.com

Configuring Identity Federation on SAML 2.0 Service Provider of "Hosting4All"

Configuration of identity federation is actually information which tells service provider how to interpret SAML 2.0 data coming from identity provider. Steps below describe how this configuration is done.

As users who are already authenticated at the customers’ identity providers do not have accounts on the service provider, in-memory users can be used for SAML 2.0 authentication at service provider. In-memory users are just like ordinary users (can have groups and roles) except for the fact that they do not have permanent accounts. In-memory users are deleted as soon as their session is terminated.

The following steps describe how to configure “Transient” name ID format, default user attributes and assertion-based user attributes.

1. Select the identity provider and click “Edit” pushbutton. Go to “Identity Federation” tab. Click “Add” pushbutton of the “Supported NameID Formats” table. Choose “Transient” format and click “OK”.
   More information regarding transient name ID format can be found at help.sap.com.
   For users coming from different identity providers, SAP logon ticket that will be issued needs to contain different SAP client value. For example, for users coming from company A, SAP logon tickets that are issued need to contain SAP client value “009”. SAP client “009” is the corresponding application client that company A uses on the ABAP system. For company B, the application client will have a different value.
   We can achieve this by configuring default user attributes. They are stored at trusted identity provider level for transient name ID format and can be different for each trusted identity provider. Default user attributes are attributes whose values are assigned to each user coming from the configured identity provider.
2. Go to “Default User Attributes” tab and click “Add” pushbutton. Choose “SAP Client” user attribute from the drop-down. Drop-down list contains predefined user attributes and also attributes created by user.
   

3. Go to “Assertion-Based User Attributes” tab. Here we will configure how to interpret SAML 2.0 attributes from the assertion. In our case, we expect that identity provider knows what the account of the user in the ABAP system is and it sends it as SAML 2.0 attribute called “R3User” in the assertion.
   Click “Add” pushbutton and enter “R3User” as SAML2 attribute. Choose “SAP R/3 User” for user attribute and mark it as mandatory. Having done this, we have configured that we require that identity provider sends SAML2 attribute named “R3User” which will contain the username for access to the ABAP system. SAML 2.0 attribute “R3User” will be mapped to user attribute “SAP R/3 User”.
   User attribute “SAP R/3 User” will be used when issuing SAP logon ticket. The value of the attribute will be put as “R/3 User” in the ticket.
   

   Important

   In order to issue SAP logon tickets with necessary information, some additional configuration is needed. UME property user.usermapping.refsys.mapping.type should have value “attribute” as follows: “ume.usermapping.refsys.mapping.type=attribute”. Steps how to configure the property are described at help.sap.com

Configuring ABAP System to Trust SAML 2.0 Service Provider

Video tutorial with the steps: Exporting the SAP Logon Ticket
With the following steps we will configure ABAP system to trust SAP logon tickets issued by SAML 2.0 service provider.

1. To export SAP Logon ticket certificate, open http(s)://<java server host>:<port>/nwa -> Configuration -> Security -> Certificates and Keys. Search for “TicketKeystore” view and select “SAPLogonTicketKeypair-cert” and click “Export Entry” pushbutton.
   
   Java system on which SAML 2.0 service provider is running will issue SAP Logon tickets which contain system ID of the issuing system, client of the issuing system and logon ID of the user (logon ID used to access the ABAP system).
2. Login to the ABAP system using SAP Logon on application client which will receive SAP logon tickets(application client is "009" in our scenario). Start transaction “STRUSTSSO2”. Use the transaction to import the previously exported SAPLogonTicketKeypair certificate and adjust the ACL list. More information regarding SAP logon tickets configuration can be found at help.sap.com . Information on how to use transaction "STRUST" can be found at Using Transaction STRUSTSSO2 in SAP System >= 4.6C .

Configuring an Application to Require SAML 2.0 Authentication

With all the steps above we have configured:

• SAML 2.0 service provider of “Hosting4All”
• SAML 2.0 trust between service provider of “Hosting4All” and identity provider
• Service provider of “Hosting4All” to issue SAP logon tickets
• Legacy ABAP system to accept the SAP logon tickets issued by the SAML 2.0 service provider

However, we still need a way to trigger SAML 2.0 authentication from the ABAP system, perform SAML 2.0 authentication and return back to the originally accessed ABAP application. For this purpose, we will use one custom Java application that will trigger SAML 2.0 authentication and redirect back to ABAP application. This application will be referred as “proxy” application.  

Before the single sign-on solution is implemented, all users coming from companies A, B and Z, used to login with username and password directly on the ABAP system. In order to preserve the current entry point of the scenario, we will also modify ABAP system logon screen to have a link pointing to the proxy application. Another possibility is that end-users are given the link pointing directly to the proxy application.

Here are the steps how to achieve this:

1. Create simple application which will act as a proxy between the ABAP system and identity provider. This application will be deployed on “Hosting4All” service provider system. You can find a sample application and information how to use it in SAP Note 2434765 .
2. Configure the simple application to require SAML 2.0 authentication. To do this follow the steps:
   
   1. Open http(s)://<java server host of “Hosting4All”>:<port>/nwa -> Configuration
      -> Authentication and Single Sign-On
   2. Search for the following policy configuration name: “sap.com/cpgdemo.proxy.app*cpgdemo_saml2”
   3. Configure the application to have authentication stack with login modules as shown in the picture:
      So we have configured that application sap.com/cpgdemo.proxy.app*cpgdemo_saml2 will have SAML 2.0 authentication. More information on protecting resources with SAML 2.0 can be found at help.sap.com
3. Add a link in the ABAP system logon screen which points to the simple application
   

Testing the Scenario

Let us explain what happens when end-user wants to use the single sign-on feature.

1. Users from company A access an application on the ABAP system and as usual they see the logon screen. In addition, they also see a link which points to the proxy application – for example “Single Sign-On Authentication”.
2. Users click “Single Sign-On Authentication” link and they are redirected to the proxy application hosted on the service provider system of “Hosting4All”.
3. As they do not have a session yet, they are redirected to the identity provider of company A for authentication.
4. After authenticating at the identity provider, SAML 2.0 response is sent to proxy application which evaluates it, authenticates the user, creates SAP logon ticket and redirects back to the originally accessed application on the ABAP system. ABAP system evaluates the SAP logon ticket and authenticates the user. User has access to the application.
   Video with the steps: Using Single Sign-On

Important Features Used in the Scenario

• NetWeaver AS Java 7.2/7.3 can be a broker between SAML 2.0 and SAP SSO2, e.g. to accept SAML 2.0 Assertions and to issue SAP logon tickets.
• By using SAML 2.0, NetWeaver AS Java 7.2/7.3 can work with temporary in-memory users and there is no need of user provisioning and maintenance.