SMP 3 Security – SAPSSO2

SMP 3 Security – Configuration of SAPSSO2 Generator

Topics

• SAPSSO2 Process Flow with SMP
• SMP SAPSSO2 Configuration
  • Preparation
  • SMP Configuration
  • Backend Configuration
• Testing SAPSSO2 Scenario
• Troubleshooting

Changelog

2017-05-22

• Updated Certificate Creation (Usage of sapgenpse instead of OpenSSL)
• Information: As 2048 Bit DSA with SHA1 is not a valid combination, please use 1024 bit DSA with SHA1

Introduction

In Service Pack 8 of SMP 3 Server a new SSO mechanism got introduced. SMP is now able to directly use SAP Logon Tickets to authenticate against a backend system. SAP Logon Tickets (also named SAPSSO2 or MYSAPSSO2 cookies) are produced by SMP for an authenticated user and attached to requests going to backend systems.

The new Authentication Provider is called “SAPSSO2 Generator” and can only be used in combination with a “real” authentication provider, such as HTTP/HTTP Authentication, LDAP, SAML.

Unfortunately, there is no user mapping in SMP available. That means that the username which got authenticated in SMP must exist also in the backend system.

SAPSSO2 Process Flow with SMP

SMP will authenticate the user based on a “real” authentication provider. The second (or the last) authentication provider is the SAPSSO2 Generator which creates the MYSAPSSO2 cookie based on the name of the authenticated user. The SAP Logon Ticket will be attached as header to all subsequent requests to the backend system.

Description of Steps

1) The hybrid app or native app is sending a data request to SMP. The request has to contain the information that are required by SMP for proper authentication (e.g. user and password for basic authentication)

2) SMP is authenticating the user based on the chosen Authentication Provider.

3) Additionally, the authentication provider “SAPSSO2 Generator” is creating a SAPSSO2 credential based on a principal name (name of the authenticated user). This credential is stored inside SMP’s session context.

4) SMP will attach the stored credential as MYSAPSSO2 cookie to the request (because SSO2 has been chosen as SSO mechanism) and forward it to the backend system.

5) The backend system will validate the received MYSAPSSO2 cookie (Trust has to be defined between backend system and SMP). The backend system will establish a user session if the issuer (SMP) is trusted and if the user is existing in the user base.

6) The backend system is responding with the requested data.

7) SMP will forward the response (without the MYSAPSSO2 cookie) to the client.

SMP SAPSSO2 Configuration

In the following I will described how to use the SAPSSO2 Generator. I will use a SMP 3 SP08 Server and a Netweaver Gateway as backend system.

Preparation

Before we start configuring SMP we need to create a keypair that can be used later to sign SAP logon tickets. Very important here is the requirement that this key has to be a DSA (Digital Signature Algorithm) key (RSA will not work!).

In the following I will use the tool sapgenpse which is part of SAP’s CommonCryptoLib to create the necessary certificates.

If you do not have a commoncryptolib available somewhere (e.g. on a SAP system) you can download it from SAP’s software center:  https://launchpad.support.sap.com/#/softwarecenter/search/commoncryptolib

After downloading (in my case Commoncryptolib 8) you have to extract the SAR archive with SAPCAR (CMD: SAPCAR -xvf <your-SAR-file>). If you do not have the SAPCAR utility you can also download it from the same software center.

Open a command prompt and navigate to the folder where you extracted the commoncryptolib content. Inside you will find the tool sapgenpse.exe which we will be using.

1. Set environment variable to SECUDIR to specifiy default folder:

   set SECUDIR=C:\Tools

2. Execute the following command to create a new PSE with algorithm DSA and 1024 bit key size:

   sapgenpse gen_pse -a DSA -s 1024 -p smp_sso2.pse “CN=SMP, OU=MIT, O=SAP, C=DE”

   

3. Create/Export a keypair file (.p12) that is including private key and public certificate and that can be later imported and used inside SMP:

   sapgenpse export_p12 -p C:\Tools\smp_sso2.pse C:\Tools\smp_sso2.p12

   

4. Let us also export the public certificate that we can use later to import into the SAP Gateway system (receiver of SAPSSO2 token), so that “trust” can be established:

   sapgenpse export_own_cert -p C:\Tools\smp_sso2.pse -o C:\Tools\smp_sso2.cer

   

5. You should now have a smp_sso2.pse, smp_sso2.cer and smp_sso2.p12 file into your folder. From the details of the certificate file you should be able to see the used signature algorithm information (DSA 1024 bit with SHA1).

   

SMP Configuration

0. Open SMP Management Cockpit, click on “Settings” then “Certificates” and choose “Import”. Import here the created p12 file as PKCS#12 file.

1. Open SMP configuration and create a new sample application (in my case com.sap.mit.sapsso2test)

2. In backend tab choose the end point. This should be a resource url on the backend which accepts SAP logon tickets. In my case this is a sample odata service on netweaver gateway.

3. Choose “SSO2” as SSO mechanism

4. Switch to tab Authentication and create a new authentication provider. In my case I will use a System Login for authenticating a user called “marvin”.

5. After that add “SAPSSO2 Generator” as second authentication provider.

• IssuerSID will be the SID of your SMP. It should match the common name of your certificate (in my case SMP).
• IssuerClient is part of the logon ticket, so we have to specify one, e.g. 000
• RecipientSID is the SID of our backendsystem (My Gateway has SID MH1)
• RecipientClient is the targetted client of backend system
• CertificateAlias is the alias of our DSA keypair that we want to use for signing our sap logon tickets

6. Click on “Test Settings” to validate the SAPSSO2 Generator settings. You should get the following message. If you get an error here, SSO cookie creation might fail later on…

7. Save all changes.

Backend Configuration

Please make sure that your backend system is configured to accept MYSAPSSO2 tokens (e.g. profile parameter login/accept_sso2_ticket = 1 is set).

We have to establish TRUST between the backend system and the SMP system, so that logon tickets issued by SMP are trusted by the backend system.

1. Open transaction STRUSTSSO2 and click on “Import Certificate” to import our certificate.

2. Choose the smp_sso2.cer certificate and add this certificate to the certificate list. And after that click on “Add to ACL”.

3. System ID has to match the value you provided inside the certificate as well as defined inside SMP SAPSSO2 Generator settings, in my case “SMP”.

Info: If you are accessing several clients on your netweaver you have to logon on each client and execute “Add to ACL” here.

4. Save all changes.

Testing SAPSSO2 Scenario

Now send a GET REST request to test if we can receive some data.

In my case I am sending a GET request to the base url of SMP (after a successful registration). The response HTTP 200 is ok and gateway is responding with the requested data through SMP.

If we trace requests on the backend, we can see that the MYSAPSSO2 cookie got attached

Because the MYSAPSSO2 cookie is base 64 encoded, you can decode the cookie to partly see the content. You can see that the provided values (like SID, client but also username and certificate information) are contained…

Troubleshooting

No matched SSO credentials is found for not allowAnonymousAccess endpoint

2015 08 09 01:56:22#+0200#ERROR#com.sap.mobile.platform.server.proxy.core.handler.DirectProxy##marvin#http-bio-8080-exec-6##b14f4cc4-1f50-443e-9e42-8641b5429b3f#com.sap.mit.sapsso2test#4f154ee6-a137-41b1-a585-3b9737bb0430#RequestResponse### Exception caught while trying to set  credentials for anonymous access com.sap.mobile.platform.server.proxy.core.handler.exception.AnonymousAccessException: No matched SSO credentials is found for not allowAnonymousAccess endpoint [com.sap.mit.sapsso2test].

This error is telling you that SMP was not able to produce a MYSAPSSO2 credential, that means that there is no credential available that could be attached by SMP. SMP will now block the request and respond with an HTTP 403 Fordbidden error.

I had some cases where this was related to the use of a wrong certificate type. Certificate needs to be DSA encrypted. If you increase the security logging component to DEBUG you can find this log entry:

2015 08 09 01:56:22#+0200#DEBUG#com.sap.mobile.platform.server.foundation.security.providers.sso2generation.SAPSSO2GenerationLoginModule###http-bio-8080-exec-6##b14f4cc4-1f50-443e-9e42-8641b5429b3f#com.sap.mit.sapsso2test#4f154ee6-a137-41b1-a585-3b9737bb0430#RequestResponse###The algorithm of private key must be DSA. |

Solution

Follow the steps as mentioned above to create a DSA keypair (1024 bit SHA1).