SMP 3 Security - SAPSSO2

marvin_hoffmann · ‎2015 Aug 09

SMP 3 Security - Configuration of SAPSSO2 Generator

Topics

SAPSSO2 Process Flow with SMP

SMP SAPSSO2 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 😎 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.

Set environment variable to SECUDIR to specifiy default folder:

set SECUDIR=C:\Tools

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"

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

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

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).

pvannest · ‎2015 Aug 18

Marvin, this blog is very much appreciated.

Former Member · ‎2015 Aug 21

detail info, thanks

NareshChittoor · ‎2015 Sep 30

Hi Marvin,

I have one query, Appreciate your suggestions.

1) we need to authenticate our mobile SMP mobile native app with AD user id and password to connect back end (NW and ECC) through SMP. in SMP cockpit we have maintained as "Basic authentication", please suggest your thoughts.

Regards

Naresh

marvin_hoffmann · ‎2015 Oct 01

Hi Naresh,

you can use the LDAP Authentication Module to authenticate the user (check user/pw against your AD), as a second auth provider include this SAPSSO2 auth provider which will generate the SAPLogon ticket which is used then to authenticate at Netweaver Gateway when sending requests.

Regards

Marvin

NareshChittoor · ‎2015 Oct 01

Hi Marvin,

Thanks for reply...At present we don't have SSO installed landscape. Is there any solution we can achieve connecting our SMP native app with AD.

Basic : We able to connect successfully, but issues is every time AD password changes, it asks to maintain the same password in NW server also...

Regards

Naresh

Former Member · ‎2015 Nov 11

Hi Marvin,

Is SAP SSO 2.0 licences required to implement what you described ?

Regards,

Nicolas

NareshChittoor · ‎2015 Nov 12

Hi Nicolas,

Nope, you don't need any license for SSO2.

Regards

Naresh

marvin_hoffmann · ‎2015 Nov 13

Naresh is correct, This SAPSSO2 Generator is a feature of SMP 3. A Netweaver Gateway is also able to understand SAPLogon tickets without the need for SSO2 add-on.

Regards

Marvin

Former Member · ‎2016 Jan 08

Hi marvin.hoffmann,

We are facing the issue mentioned in the troubleshooting. We are using SMP SP9. We have installed OpenSSL 1.0.2.

We are getting the error while we are trying to follow the steps. We got the error at step 2.

Could you please let us know if you have any idea on the resolution?

Regards,

Karthik

christian_schulzendorff · ‎2016 Feb 08

Hi Marvin,

what about Agentry apps? Does SAPSSO2 support Agentry, too? In your architecture picture, there are only Kapsel and native apps listed, but Agentry is also part of the SMP 3.0.

Regards

Christian

former_member182374 · ‎2016 Jun 26

Hi Marvin,

I'm working with SMP3 and MBO and I couldn't find any information regarding SSO (SMP->ABAP) configuration (I'm using SOAP web services from ABAP stack).

The docs I found are about JCO...

Can you please direct me to docs/blog about this configuration? (it seems SMP with oData and SMP with MBO are two different installations and not one installation with two options).

Regards,

Omri

former_member219027 · ‎2016 Jul 29

Marvin,

This article is very comprehensive. It is lacking one detail though. The Netweaver system should be configured to accept SSO2 tickets to authenticate the user. Can you update the article with details about setting the profile parameter login/accept_sso2_ticket = 1.

Former Member · ‎2016 Nov 14

Hello Marvin.
Have you any information about possibility of users mapping in new versions of SMP? Our users have different names in Microsoft AD and SAP ERP. Also users in SAP ERP have not the password in SAP ERP. We can't make the authorization on SMP 3.0. May be you suggest me another type of authorization? In SAP ERP we use Kerberos authorization with Microsoft AD credentials.
Thanks in advance for information.
Best regards,
Alexey.

former_member272646 · ‎2016 Nov 17

Hello,

after configuring SSO2 ( SMP -> SAP Gateway ) according to Marvin's manual SingleSignOn did not work.

On the SAP Gateway we activated the security trace as described in SAP Note 495911 Logon problem trace analysis.
( sm50 ; tracelevel 2 for component security for all diaglog-wps).

In the Workprocess-Trace the following error could be found after a failed SingleSignOn from SMP to the SAP Gateway:

Got ticket (head) AjExMDACAAMwMDADAANTTVAQAANLREwPAAMxMDAB. Length = 632.
N *** ERROR => SsfVerify failed (see note 1055856). [ssoxxsgn.c   152]
N {root-id=0050560C00A11EE6AAF890620B5E0DC2}_{conn-id=0050560C00A11EE6AAF890620B5E2DC2}_1
N   SsfVerify returned 5 :: SSF_API_SIGNER_ERRORS :: Error during verify - signer error.
N MYSAPSSO2 ticket SSF error description: A signing operation could not be performed or failed .
N   SSF LIB returned 27 :: SSF_API_RECIPIENT_NOT_OK :: Operation not ok for recipient.
N   Signer   ID: <unknown>
N   Signer info: SigningTime= Wed Nov 16 06:18:03 2016 (UTCTime: 161116061803Z)
N *** ERROR => ValidateTicket failed with rc = 5 and ssf_rc = 27. [ssoxxapi.c   249]
N *** ERROR => Ticket validation failed with rc = 5 and ssf_rc = 27. [ssoxxkrn.c   958]
N dy_signi_ext: invalid ticket

This issue occurred due to the format of the self-signed-certificate.
If the E-Mail is specified it will be the first part of the certificate:

EMAIL=mobileITSolutions@zf.com, CN=SMP, OU=ZF, O=ZF Friedrichshafen AG, L=Friedrichshafen, SP=BW, C=DE

So the E-Mail has to be omitted in "3. Create a self signed certificate. The common name should match the SID of your system, e.g SMP"

The working certificate starts with CN=SMP :
CN=SMP, O="ZF ", L=Friedrichshafen, SP=Some-State, C=DE

Regards
Thomas

matas_denker · ‎2017 Jan 10

Hi. Nice blog. I am having invalid signer errors at the backend. I've created the SMP certificate using "SMP" as common name, but I really don't know which is my SMP SID. What do you mean with "The common name should match the SID of your system, e.g SMP"? Thanks

Former Member · ‎2017 Jan 26

Hi

when i creating the self sign

openssl req -x509 -new -key smp_sso2.pem -out smp_sso2.cer

im getting this error:

"

C:\SAP\MobilePlatform3\MR30\Servers\MessagingServer\Bin>openssl req -x509 -new -

key smp_sso2.pem -out smp_sso2.cer

Unable to load config info from c:/temp/openssl_output/ssl/openssl.cnf"

someone have a clue please?

thanks:-)

adren_dsouza · ‎2017 Mar 28

Hi Matias,

Were you able to resolve this ?

Regards,

Adren

former_member219027 · ‎2017 May 02

The SAPSSOGenerator provider uses SHA1 for signing the generated SAPSSO2 Ticket. The use of 2048 bit DSA keys with SHA1 is not a valid combination and some JVMs enforce the limitation (though eventually all JVM implementations will catchup and enforce it). So, one might encounter errors in Gateway Server w.r.t validating the SAPSSO2Token generated by the SAPSSO Generator provider when a 2048 bit DSA certificate is used. Following is the trace seen in the Gateway server:

N  *** ERROR => SsfVerify failed (see note 1055856). [ssoxxsgn.c   152]
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
N   SsfVerify returned 5 :: SSF_API_SIGNER_ERRORS :: Error during verify – signer error.
N  MYSAPSSO2 ticket SSF error description: A signing operation could not be performed or failed .
N   SSF LIB returned 27 :: SSF_API_RECIPIENT_NOT_OK :: Operation not ok for recipient.

The only known workaround for this issue currently is to switch to a 1024 bit DSA with SHA1.

marvin_hoffmann · ‎2017 May 22

Thanks, I updated the blog to reflect this.

matas_denker · ‎2017 Jul 26

Hi. Yes, I've solved it. The CN should be always "SMP" within the new certificate used to sign the SAP logon ticket. Then you need to import that certificate in STRUSTSSO2 on backend, in client 000 and then add the sid SMP client 000 combination in the ACL in both client 000 and logon client on backend. Depending on the SAP Crypto lib you are using on backend, you will be able to use more than 1024 bits, if not sure, use always 1024 and DSA, not RSA, and sha1 and not sha256. check note 2367419. Good luck

Former Member · ‎2017 Aug 29

Hi Marvin,

This is a very nice blog. We have created PSE,.P12,CER file using above command . but we are getting error while importing p12 certificate in to the SMP 3.0 from admin cockpit.PFA the error screenshots. Any help will be appreciated.