We all know it can be a pain remembering passwords, keeping them safe and typing them in. In client/server scenarios, where data is exchanged storing technical usernames and passwords is mostly regarded as not being best practice. In such a scenario - but not only! - the usage of certificates is a good practice.
In this blog I want to guide you how to:
While all information is around somewhere I wasn't able to find it all in one place so hopefully it will be of use to you! It's supposed to be a practicioners guide and below I give credit to the sources which I have used.
The use case looks like the following outline, we want to be able to call an OData service in an SAP S/4 System from a node.js module running inside SAP HANA XSA.
We will need to have a certificate of the CA (Certificate Authority) in the SAP Netweaver Server to establish a trust relation for the certificate(s) that we upload to being able to identify and authenticate the client. This certificate holds the public key of the client. Lastly, we have the client certificate in the SAP HANA Node.js module including the private key of the client.
When working with webservices, SAP Netweaver offers in principle four options: No authentication required (user is pre-set in the backend system) for the according service, user-based authentication with basic login (standard or SSL), Identity Provider-based (SAML), and SSL certificate based. We will focus on the last option only, so we define the service in transaction SICF as shown above.
In this blog we will create the set of certificates on our own. For that we install OpenSSL in the environment of your choice. In my case it's Linux - you will find many good tutorials how to install it, so we skip the installation procedure. Let's get straight to certificate creation.
First, we need the CA certificate, because all other certificates build on it. For that we use a CA configuration file which you can -and should! - adapt to your needs. The CN (Common Name) plays an important role and it is required that the CN of the CA certificate is not identical with the CN of the client certificate which we will create later.
We create the CA certificate with the following command:
ca-crt.pem is the certificate which we will use later. Next, we create a private key for the server. While we don't need it in our scenario, we need it to sign the client certificates.
We now create the signing request with the help of the server certificate config template, which you should adopt to your needs accordingly.
Now we sign the request:
If you have chosen a different password than "password" ? then please adopt above command. We have CA and Server certificates at hand now.
Finally we create the client certificates:
...and finalize them with the help of the last template:
And we sign them by:
And we should verify if they are valid by:
you should see a message saying "client-crt.pem: OK". If the message states: "error 18 at 0 depth lookup: self signed certificate. error client-crt.pem: verification failed" then it is likely that you didn't choose a different CN for CA and Client.
In principle we are good to go now for our node.js test - but if we want to test it from Chrome (on Windows) please read the next paragraph, otherwise get straight to SAP configuration.
If you want to ping into SAP Netweaver from Chrome (or another browser) the certificates we forged are good - but not good enough! We need to combine the client-crt.pem with client-key.pem into one certificate so that the private key is part of the certificate store. This is realized with the help of PKCS 12 - a format to bundle both and with the file extension .pfx. We generate it by:
In Chrome we upload it in Settings⇒More⇒Manage Certificates:
Import the client certificate into "Personal" store, the CA certificate into the "Trusted Root Certification Authorities". You will get a warning, because our self-signed CA is not trusted.
Note: Windows needs a combined personal certificate containing both private and public key. To achieve that use the following command:
Now you are set!
I assume that the system is already set up to work with SSL/HTTPS in principle. So we just add the missing part for certificate authentication. We need visit 2 transactions, STRUST and CERTRULE.
In STRUST we import our CA certificate - otherwise the client certificate which refers to the CA as the issuer won't be trusted.
In the artwork above you see the steps. The certificate that we import is the ca-crt.pem that we created before. Now we save and leave.
You might have had the question: How does SAP Netweaver know that this certificate has these and that authorizations? You will see it in the final step, certificates are mapped to users in SAP! And CERTRULE can help to do that mapping.
In CERTRULE we upload the client certificate client-crt.pem we made. That is done in the Configuration⇒Upload menu path. Then we come to the mapping: We need to tell which certificate attribute specifies the username by pressing the Rule button. In my case I put in exactly the username as it exists in SAP Netweaver into the CN attribute.
If you can't derive it by a rule, you can push the button Explicit Mapping which then assign it in a one to one relationship.
When you push the Save button, the red traffic light in the upper right corner of the screen must turn green, indicating that the automatic user mapping was successful. Marvin explains this process very nicely in the blog which you find in the credits and it was very helpful for me.
We're good to go for a test from our Browser! Let's call a URL which is exposed by the SAP Netweaver system (the service we have configured for certificates in the first step of this post).
Now the browser will show a certificate pop-up and when you confirm the OData Service will show the according metadata. Yay!?
Of course we can use the same mechanism now for client/server scenarios for example from a SAP HANA XSA application. So the Javascript code snippet is like that:
because it is self-signed, we need "rejectUnauthorized : false" in here. In my use case I pass the response to a UI5 instance which handles the OData so I can work on https-level here.
We have learnt how to set up certificate handling for the purpose of user authentication to SAP Netweaver in order to simplify and secure the process for users or clients. Like or comment if useful!
Credits:
Content
In this blog I want to guide you how to:
- Explain the mechanism of certificate authentication
- Create the set of certificates required to set it up
- Set up Chrome Browser to test for a working setup
- Set up SAP S/4HANA or SAP ECC to accept certificate-based authentication
- Lastly show how you can use it with node.js to call an SAP S/4HANA-based OData service from HANA XSA.
While all information is around somewhere I wasn't able to find it all in one place so hopefully it will be of use to you! It's supposed to be a practicioners guide and below I give credit to the sources which I have used.
Certificate authentication
The use case looks like the following outline, we want to be able to call an OData service in an SAP S/4 System from a node.js module running inside SAP HANA XSA.
We will need to have a certificate of the CA (Certificate Authority) in the SAP Netweaver Server to establish a trust relation for the certificate(s) that we upload to being able to identify and authenticate the client. This certificate holds the public key of the client. Lastly, we have the client certificate in the SAP HANA Node.js module including the private key of the client.
When working with webservices, SAP Netweaver offers in principle four options: No authentication required (user is pre-set in the backend system) for the according service, user-based authentication with basic login (standard or SSL), Identity Provider-based (SAML), and SSL certificate based. We will focus on the last option only, so we define the service in transaction SICF as shown above.
Self-signed certificate creation
In this blog we will create the set of certificates on our own. For that we install OpenSSL in the environment of your choice. In my case it's Linux - you will find many good tutorials how to install it, so we skip the installation procedure. Let's get straight to certificate creation.
First, we need the CA certificate, because all other certificates build on it. For that we use a CA configuration file which you can -and should! - adapt to your needs. The CN (Common Name) plays an important role and it is required that the CN of the CA certificate is not identical with the CN of the client certificate which we will create later.
We create the CA certificate with the following command:
openssl req -new -x509 -days 9999 -config ca.config -keyout ca-key.pem -out ca-crt.pemca-crt.pem is the certificate which we will use later. Next, we create a private key for the server. While we don't need it in our scenario, we need it to sign the client certificates.
openssl genrsa -out server-key.pem 4096We now create the signing request with the help of the server certificate config template, which you should adopt to your needs accordingly.
openssl req -new -config server.config -key server-key.pem -out server-csr.pemNow we sign the request:
openssl x509 -req -extfile server.config -days 365 -passin "pass:password" -in server-csr.pem -CA ca-crt.pem -CAkey ca-key.pem -CAcreateserial -out server-crt.pemIf you have chosen a different password than "password" ? then please adopt above command. We have CA and Server certificates at hand now.
Finally we create the client certificates:
openssl genrsa -out client-key.pem 4096...and finalize them with the help of the last template:
openssl req -new -config client.config -key client-key.pem -out client-csr.pemAnd we sign them by:
openssl x509 -req -extfile client.config -days 365 -passin "pass:password" -in client-csr.pem -CA ca-crt.pem -CAkey ca-key.pem -CAcreateserial -out client-crt.pemAnd we should verify if they are valid by:
openssl verify -CAfile ca-crt.pem client-crt.pemyou should see a message saying "client-crt.pem: OK". If the message states: "error 18 at 0 depth lookup: self signed certificate. error client-crt.pem: verification failed" then it is likely that you didn't choose a different CN for CA and Client.
In principle we are good to go now for our node.js test - but if we want to test it from Chrome (on Windows) please read the next paragraph, otherwise get straight to SAP configuration.
Set up Chrome Browser to test for a working setup
If you want to ping into SAP Netweaver from Chrome (or another browser) the certificates we forged are good - but not good enough! We need to combine the client-crt.pem with client-key.pem into one certificate so that the private key is part of the certificate store. This is realized with the help of PKCS 12 - a format to bundle both and with the file extension .pfx. We generate it by:
openssl pkcs12 -inkey client-key.pem -in client-crt.pem -export -out client-crt.pfxIn Chrome we upload it in Settings⇒More⇒Manage Certificates:
Import the client certificate into "Personal" store, the CA certificate into the "Trusted Root Certification Authorities". You will get a warning, because our self-signed CA is not trusted.
Note: Windows needs a combined personal certificate containing both private and public key. To achieve that use the following command:
openssl pkcs12 -export -out mypersonalcert.pfx -inkey client-key.pem -in client-crt.pemNow you are set!
Set up SAP S/4HANA or SAP ECC to accept certificate-based authentication
I assume that the system is already set up to work with SSL/HTTPS in principle. So we just add the missing part for certificate authentication. We need visit 2 transactions, STRUST and CERTRULE.
In STRUST we import our CA certificate - otherwise the client certificate which refers to the CA as the issuer won't be trusted.
In the artwork above you see the steps. The certificate that we import is the ca-crt.pem that we created before. Now we save and leave.
You might have had the question: How does SAP Netweaver know that this certificate has these and that authorizations? You will see it in the final step, certificates are mapped to users in SAP! And CERTRULE can help to do that mapping.
In CERTRULE we upload the client certificate client-crt.pem we made. That is done in the Configuration⇒Upload menu path. Then we come to the mapping: We need to tell which certificate attribute specifies the username by pressing the Rule button. In my case I put in exactly the username as it exists in SAP Netweaver into the CN attribute.
If you can't derive it by a rule, you can push the button Explicit Mapping which then assign it in a one to one relationship.
When you push the Save button, the red traffic light in the upper right corner of the screen must turn green, indicating that the automatic user mapping was successful. Marvin explains this process very nicely in the blog which you find in the credits and it was very helpful for me.
We're good to go for a test from our Browser! Let's call a URL which is exposed by the SAP Netweaver system (the service we have configured for certificates in the first step of this post).
Now the browser will show a certificate pop-up and when you confirm the OData Service will show the according metadata. Yay!?
Calling with certificate from SAP HANA XSA by a node.js module
Of course we can use the same mechanism now for client/server scenarios for example from a SAP HANA XSA application. So the Javascript code snippet is like that:
const https = require("https");
const fs = require("fs");
const requestParams = {
hostname: "<my SAP Netweaver hostname>",
port: 44300,
key: fs.readFileSync("./resources/client-key.pem"),
cert: fs.readFileSync("./resources/client-crt.pem"),
ca: fs.readFileSync("./resources/ca-crt.pem"),
rejectUnauthorized : false,
path: "<the OData URL>",
method: "<GET/POST/DELETE etc>"
};
const httpsReq = https.request(requestParams, httpsRes => {
// Handle the response here
});
httpsReq.end();
because it is self-signed, we need "rejectUnauthorized : false" in here. In my use case I pass the response to a UI5 instance which handles the OData so I can work on https-level here.
Summary
We have learnt how to set up certificate handling for the purpose of user authentication to SAP Netweaver in order to simplify and secure the process for users or clients. Like or comment if useful!
Credits:
HTTPS Authorized Certs with Node.js
Configuring Client Certificate Authentication (mutual https) on SAP Gateway
X.509 on Wikipedia
- SAP Managed Tags:
9 Comments
