Technical Articles
How to Guide – Single Sign-On with SAPAssertionSSO between SCP and ABAP
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:
- One SAP Cloud Connector.
- One SAP Cloud Platform Account.
- 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. - 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:
- Create a certificate
- Configure the SAP Cloud Connector
- Create a destination on SAP Cloud Platform
- 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.
- Generating the certificate:
- 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”.
Note that the expiry date for this certificate will be 90 days.
So if you need to have a higher expiry date, check the -validity parameter on the keytool documentation.
Example of a command generating the certificate with 365 days of validity:keytool -genkey -keyalg DSA -alias alias -keystore mycert_dsa.jks -dname "CN=SCP" -validity 365
- 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) - Export the certificate to base64 format:
openssl pkcs12 -in mycert_dsa.p12 -nodes -out mycert_dsa.pem
- Generate a key and create a keystore(change the values according to your needs):
- 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:- Create a copy of the mycert_dsa.pem.
- Rename the original file to pub.crt.
- Rename the copied file to priv.pem.
- Open the pub.crt with a file editor.
- Remove all content and leave just the part of the public key. Save it:
- Open the priv.pem with a file editor.
- Remove all content and leave just the part of the private key. Save it.
- 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.
- Go to Cloud To On-Premise -> Access Control.
- Click on the Add button:
- Choose the Back-end Type you are going to use (in this case I’m selecting ABAP System):
- Select the Protocol:
- 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):
- 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):
- Set the Principal Type as None:
- (Optional) Set a description to your mapping.
- Click on Finish.
- 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:
- 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. - Click on Save.
3 – Create a destination on SAP Cloud Platform
- Open your SAP Cloud Platform account.
You can use the following link: https://account.hana.ondemand.com. - Click on Log On.
- Click on the Global Account you are going to use:
- Click on the subaccount you are going to configure (the same one you have synchronized with the SAP Cloud Connector):
- Inside your subaccount, go to Connectivity -> Destinations:
- Click on New Destination:
- Configure your New Destination Configurations:
- Name: you can set any name you want for your destination. Remember to use this name when calling the destination in your applications.
- Type: HTTP.
- 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.
- Proxy Type: OnPremise.
- Authentication: SAPAssertionSSO.
- Issuer SID: “SCP”. You can set any value you want. You will need this value when setting the trust in the backend system.
- Issuer Client: “000”. Again, you can use any value you want. This value will be needed when setting the trust to the backend.
- Recipient SID: “N52”. The SID for the target host.
- Recipient Client: “001”. The client for the target host.
- Certificate: Here we import the value of the public certificate key we’ve created in the section 1 (the pub.crt file content).
- Signing key: Here we import the value of the private certificate key we’ve created in the section 1 (the priv.pem file content).
- Configure your New Destination – Additional Property:
- New Property:
- Choose sap-client.
- Set the same value you’ve set in the Recipient Client.
- New Property:
- Choose WebIDEEnabled.
- Set the value true.
- New Property:
- WebIDESystem.
- Choose the same value you’ve set in the Recipient SID.
- New Property:
- WebIDEUsage.
- 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.
- New Property:
- Click on Save.
- You destination should look similar to the screen shot below:
- Click on the Check Connection button.
- With this test, you can validate if your destination is reachable.
- 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:
- Log-in to your backend system.
- Go to the transaction RZ10:
- Select the Profile.
- Select the Extended maintenance checkbox.
- Click on Display.
- Check if the parameter login/accept_sso2_ticket has the value 1:
- If not, you need to set the parameter to 1, and then re-start the ICM.
- Go to the transaction STRUSTSSO2:
- Press Ctrl+F1 or click on the glasses button to change the screen to edit mode.
- Click on the Import Certificate Button.
- Select the public certificate you’ve created on Section 1:
- 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:
- 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:
- Click in the Add to ACL button:
- Set the System ID with the value you’ve set in the Issuer SID (section 3, step 7.6).
- Set the Client with the value you’ve set in the Issuer Client (section 3, step 7.7):
- Now you should be able to see the following screen:
- 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
Great blog, Augusto, very useful!
Thanks Bernd.
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.
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
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
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
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
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
Why does this require a DSA key instead of an RSA Key?
Hi Jerrod
Thank you for your questions.
The usage of DSA is because it is what the SAP Systems use by default.
Thanks,
Augusto
Augusto,
Great blog. Very informative/useful. Do you have a “How to Guide: Secure Login Server (SSO) with C/4HANA”? I would think it would be something like: "How to Guide: Single Sign-On with SAPAssertionSSO between SCP and Secure Login Server"
Thank you.
Francis
Thank you Augusto Ferreira for this excellent post. I think it worth mentioning that for this scenario to work correctly the Logon Procedure must include SAP Logon/Assertion Ticket. Setting only SAP Assertion Ticket does not work:
Hi Gregor
Thank you for the update!
I'll adjust the blog, including this warning.
Best Regards,
Augusto
Hi Augusto,
i have tried with above aproach. Still it is asking backend system logins . is there an specific
initial setup required in backend system. Please let us know .
Thanks,
Mohan.
Dear Augusto Ferreira,
thanks for sharing your insights on this.
Unfortunately, we were struggling in creation of a certificate that is signed by an official authority.
The main issue relates to the fact that by default, only 1024 bit DSA certificates that use SHA1 as the signature algorithm are supported. The use of 2048 bit DSA keys with SHA256 or the use of RSA certificates is not supported. But there is this SAP Note which provides a workaround for that: 2420548 - Change Hash algorithm for SAP tickets and decouple them from System PSE.
As a result we've ended up with a self-signed certificate based on your guide.
From a security perspective we didn't detect a major downside as the connection is tunneled by the Cloud Connector anyway.
Best regards,
Sebastian