Skip to Content

This blog provides you with a step-by-step instruction on how to quickly get started with a Single Sign-On configuration between SAP Cloud Platform and an ABAP backend using the SAPAssertionSSO authentication method.

As we can see in the official help page about SAPAssertionSSO, the aim of the SAPAssertionSSO destination is to generate such an assertion ticket in order to propagate the currently logged-on SAP Cloud Platform user to an SAP back-end system.

Prerequisites:

  1. One SAP Cloud Connector.
  2. One SAP Cloud Platform Account.
  3. The SAP Cloud Connector musts be up and running.
    Check if the initial configuration is performed, so your account on SAP Cloud Platform is properly synchronized with your SAP Cloud Connector.
  4. We are using the openssl toolkit to create the certificate.

Before we start it is important to state that the user names must be identical in the cloud and in the backend. In other words, there is no user mapping for this configuration.

Configuration Steps:

  1. Create a certificate
  2. Configure the SAP Cloud Connector
  3. Create a destination on SAP Cloud Platform
  4. Configure the ABAP System.

 

1 – Creating the certificate:

For this section, you can use any tool of your choice. The important is that the certificate itself must use DSA.

The certificate can be self-signed or signed by a trusted certificate authority.

In this example, we are using a self-signed certificate with the simplest DN name possible.

  1. Generating the certificate:
    1. Generate a key and create a keystore(change the values according to your needs):
      keytool -genkey -keyalg DSA -alias alias -keystore mycert_dsa.jks -dname "CN=SCP"

      After you type the command, you will be prompted to type a keystore password. Choose a mix of letters and numbers, for example: “abcd1234”.

    2. Export the certificate from the keystore:
      keytool -importkeystore -srckeystore mycert_dsa.jks -destkeystore mycert_dsa.p12 -srcstoretype jks -deststoretype pkcs12

      After you type the command, you will be prompted to type the destination keystore password. Choose a mix of letters and numbers (it can be the same password as before).
      Then, type the password from the source keystore (from the previous step)

    3. Export the certificate to base64 format:
      openssl pkcs12 -in mycert_dsa.p12 -nodes -out mycert_dsa.pem

       

  2. Now, you should have a file called mycert_dsa.pem created.
    The mycert_dsa.pem file contains both private and public certificates inside of it. So, we are going to create a copy of it to separate the public and private from each other.
    In order to do that, follow the steps below:

    1. Create a copy of the mycert_dsa.pem.
    2. Rename the original file to pub.crt.
    3. Rename the copied file to priv.pem.
    4. Open the pub.crt with a file editor.
    5. Remove all content and leave just the part of the public key. Save it:
    6. Open the priv.pem with a file editor.
    7. Remove all content and leave just the part of the private key. Save it.
    8. Make sure not to add any characters inside the files (spaces, line breaks, etc).

2 – Configure the SAP Cloud Connector

In the SAP Cloud Connector, we need to create a System Mapping to the ABAP Backend.

  1. Go to Cloud To On-Premise -> Access Control.
  2. Click on the Add button:
  3. Choose the Back-end Type you are going to use (in this case I’m selecting ABAP System):
  4. Select the Protocol:
  5. Set the Internal Host and the Internal port (if you don’t know, you can check it in your ABAP backend, going to the transaction SMICM, and pressing Shift+F1):
  6. Set the Virtual Host and Virtual port (these values must be identical to the URL that is going to be set in the destination on SAP Cloud Platform):
  7. Set the Principal Type as None:
  8. (Optional) Set a description to your mapping.
  9. Click on Finish.
  10. Select the Mapping that you just created, so the Resources Accessible options will appear in the bottom. Then, click on the Add button as can be seen in the following screenshot:
  11. Set the URL Path that your application needs to have access. In this case, the application is going to consume an OData that is reachable from the path /sap/opu/odata
    You can set Path only to enable just a specific path or you can choose the Path and all sub-paths option to enable the application to have access to all sub-paths needed.
  12. Click on Save.

 

3 – Create a destination on SAP Cloud Platform

  1. Open your SAP Cloud Platform account.
    You can use the following link: https://account.hana.ondemand.com.
  2. Click on Log On.
  3. Click on the Global Account you are going to use:
  4. Click on the subaccount you are going to configure (the same one you have synchronized with the SAP Cloud Connector):
  5. Inside your subaccount, go to Connectivity -> Destinations:
  6. Click on New Destination:
  7. Configure your New Destination Configurations:
    1. Name: you can set any name you want for your destination. Remember to use this name when calling the destination in your applications.
    2. Type: HTTP.
    3. URL: “http://myvirtualadress:8001”. Here you need to set the virtual host you have set in the SAP Cloud Connector. You start with the protocol (can be http or https) then the virtual host and in the end you set the port.
    4. Proxy Type: OnPremise.
    5. Authentication: SAPAssertionSSO.
    6. Issuer SID: “SCP”. You can set any value you want. You will need this value when setting the trust in the backend system.
    7. Issuer Client: “000”. Again, you can use any value you want. This value will be needed when setting the trust to the backend.
    8. Recipient SID: “N52”. The SID for the target host.
    9. Recipient Client: “001”. The client for the target host.
    10. Certificate: Here we import the value of the public certificate key we’ve created in the section 1 (the pub.crt file content).
    11. Signing key: Here we import the value of the private certificate key we’ve created in the section 1 (the priv.pem file content).
  8. Configure your New Destination – Additional Property:
    1. New Property:
      1. Choose sap-client.
      2. Set the same value you’ve set in the Recipient Client.
    2. New Property:
      1. Choose WebIDEEnabled.
      2. Set the value true.
    3. New Property:
      1. WebIDESystem.
      2. Choose the same value you’ve set in the Recipient SID.
    4. New Property:
      1. WebIDEUsage.
      2. Here you need to set the values you are going to need, regarding what you are going to use. For this example, we are setting odata_abap, odata_gen.
  9. Click on Save.
  10. You destination should look similar to the screen shot below:
  11. Click on the Check Connection button.
    1. With this test, you can validate if your destination is reachable.
    2. If the test fails, you need to double-check the destination URL and also the mapping in the SAP Cloud Connector (section 2).

4 – Configure the ABAP System:

  1. Log-in to your backend system.
  2. Go to the transaction RZ10:
    1. Select the Profile.
    2. Select the Extended maintenance checkbox.
    3. Click on Display.
    4. Check if the parameter login/accept_sso2_ticket has the value 1:
      1. If not, you need to set the parameter to 1, and then re-start the ICM.
  3. Go to the transaction STRUSTSSO2:
    1. Press Ctrl+F1 or click on the glasses button to change the screen to edit mode.
    2. Click on the Import Certificate Button.
    3. Select the public certificate you’ve created on Section 1:
    4. After adding the public certificate, you should be able to see it’s details in the Certificate section. Check if everything is ok, and click on Add to Certificate List button:
    5. Now you should see an entry in the Certificate List with the subject of the certificate you’ve imported. In this case, we are seeing an entry with the subject CN=SCP:
    6. Click in the Add to ACL button:
    7. Set the System ID with the value you’ve set in the Issuer SID (section 3, step 7.6).
    8. Set the Client with the value you’ve set in the Issuer Client (section 3, step 7.7):
    9. Now you should be able to see the following screen:
    10. Save.

Congratulations. You did it!

After all those steps, the SAPAssertionSSO configuration is done! Get yourself a beer and relax a little bit, you deserve it.

There is this youtube video which I’ve used as guide when writing this blog. If you have any problems with this configuration, I suggest you watch this video as well.

I will continue to write blog posts about different scenarios involving SAP Cloud Platform and ABAP Backend systems, using different protocols and authentication methods. So if you want to know when something new come up, click on Follow at the top of this page to get noticed.

Thanks,
Augusto Ferreira

To report this post you need to login first.

9 Comments

You must be Logged on to comment or reply to a post.

  1. Phil Cooley

    Thanks Augusto Ferreira  for this. I have alot of questions! 🙂

    I’ve been on a lot of projects where I’ve had to set up Principal Propagation and I’ve not carried out this method previously. I’ve always used the System Certificate from the SAP Cloud Connector that is signed to then load into backend systems. This also includes the CA certificate and short-lived if applicable.

    • Using this method does this mean there is no System Certificate or CA Certificate loaded in the SAP Cloud Connector and does it also mean there is no System Certificate loaded into the backend system?
    • The certificate that you load in – which area do you load it into? I know the System Certificate is normally loaded in the SSL Server Standard so just interested where this certificate is loaded.
    • When you say SAP Cloud Platform user does this mean the S number or P number? Does this method also cover if Trust settings authenticate against an on-premise IDP or SAP Cloud Identity Authentication?
    • Once you load the certificate in do you also need to use CERTRULE or the EXTID_DN mapping table or do these not apply.

    Sorry for bombarding you with this but just interested as an alternative to the main way I set up Principal Propagation.

    Thanks & Kind Regards

    Phil Cooley

    (1) 
    1. Augusto Ferreira
      Post author

      Hi Phil

      I’m glad to see that people are going through this blog and learning more about our cloud scenarios 🙂

      About your questions, consider the following:

      1. Yes. The Cloud Connector in this scenario is transparent. It just connects the SCP to the ABAP System. You don’t need to configure any trust between the cloud connector to the ABAP System (as the assertion ticket is created in the cloud and veryfied in the ABAP backend) and the communication protocol is HTTP.

      2. In the ABAP side, you will load the public certificate you created using the transaction STRUSTSSO2 and importing it under “System PSE” (as you can see in section 4 step 3.2). The SSL Server Standard you will configure for HTTPS communications (like the principal propagation scenario).

      3. When I say SCP user, I mean the user logged in on the cloud application. If you have a third party IDP, and you are usgin this third party to authenticate in your cloud application, then this logon information of this user will be the one propagated to the backend. If you are using SAP IDP, then will be a S-User.

      4. As mentioned in the prerequisites, for this scenario, there is no user mapping. The user authenticated in the cloud must be the same user in the backend. For example, if the user logged in is S000001, in the ABAP Backend must exist the same S000001. The system will not look for a user mapping in the certrule or in the EXTID_DN, because it expects that the user already exists exactly the same as in the ticket. (this is not a principal propagation scenario).

      And feel free to ask, I’m glad to help 😀

      I will ask for my colleague Geferson Hess to better answer you about these security questions.

      Kind Regards,
      Augusto Ferreira

      (1) 
    2. Geferson Hess

      Hello Phil,

      The correct place to add the certificate is the PSE configured to handle Logon/Assertion tickets in the back-end system.
      By default, it will be the System PSE.

      It is possible to change it (not recommended) by following SAP Note 2420548.

      Regards,
      Geferson Hess

      (1) 
      1. Phil Cooley

        Hi Geferson

        Most clients I work with want Principal Propagation working in their environment so still not sure that this method will entirely meet this requirement. SSO vs PP – would be good to know what is different here. I’ve used the System Certificate load into backend systems from the SCC heaps of times and it always works.

        Not sure what would happen if I used this method with a login user of an email address as the userid obviously cannot be this in SAP. Much easier obviously if it is a userid such as S00001 that can be duplicated but other types of userids not as easy.

        The biggest question is the scenarios I would use this in, as opposed to what I am used to using. If this can be answered that would be great – just improves my understand of the security concepts.

        Thanks & Kind Regards

        Phil Cooley

        (0) 
        1. Geferson Hess

          Hi Phil,

          It really depends on what you prefer. There is no wrong choice.

          Assertion/Logon Tickets are used in scenarios where an user exist in both systems, like a NW Java connection to an NW ABAP, using Iviews for example.

          If you try to use this method with users that doesn’t match, it won’t work. In this case, the recommendation is the use of Principal Propagation.

          Regards,
          Geferson Hess

           

          (1) 

Leave a Reply