
Dear community,
Many of you still rely heavily on the legacy SAP interface RFC. In my world that often means customers connecting their third-party services to SAP backends (AS ABAP). Securing a protocol such as SAP Remote Function Call (RFC) requires network layer protection.
Often Kerberos is discussed on this topic, because it allows the mapping of Windows-Known identities to SAP backend users. However, this post is about apps and technical connections using X.509 certs – not people. They complain less – and boringly but reliably behave the same way once configured properly😉 Meet SAP Secure Network Communications (SNC).
By the way: In case you want user-based flows and focus on SAP Principal Propagation have a look at this series by my beloved colleague Martin Raepple.
SAP SNC integration architecture overview
In light of zero-trust efforts customers want to secure their technical connections to SAP RFCs too. In that space certificate-based authentication mechanisms are king. SNC is a prominent choice.
There are libraries for languages like Java, DotNet, C/C++, Python, and NodeJS that support SNC for RFC. Python and NodeJS were recently archived and will no longer be maintained. In case you get stuck, consider generating SOAP services for your SAP RFCs to uplevel the communication stack to layer 7 for use with TLS instead.
Source: SAP Help
Below I will show a simple setup with self-signed certificates. This way you can get started with a working setup and elevate towards more sophisticated as you go. Troubleshooting SNC errors can be cumbersome, so starting small with less variables and less room for error is a good idea.
Be aware of latest crypto library guidance (SAPCryptoLib vs, CommonCryptoLib) published by @JoeGoerlich in this post. My post still refers to SAPCryptoLib as it still widely applicable. Consider CommonCryptoLib if you can. |
SAP products like the SAP Cloud Connector support apps (and people) on the SAP Business Technology Platform to connect to private instances of AS ABAP systems (behind firewall, in RISE, on-premises, or on a protected hyperscaler environment) and bring the required RFC execution environment.
Third-party apps must overcome the same challenges. Typically, that means you will be provided with a piece of software to act as reverse invoke proxy (same as the SAP Cloud Connector) besides the “line of sight” through connected private networks from that proxy. See step 0 in the overview drawing for reference.
It establishes connection to your third-party app inside out, so that no inbound firewall rules or the likes need to be touched.
For instance, Microsoft apps like Azure Data Factory, Azure Synapse, Microsoft Purview, Microsoft Fabric, and Microsoft Power BI have dedicated means to connect. These components are called Self-hosted Integration Runtime (SHIR) or On-Premises Data Gateway. Find the downloads on the individual product pages.
Be aware that services like Azure Functions or Azure LogicApps have a second approach beyond the Microsoft On-premises Data Gateway. They can bring the means to execute RFC calls, provide SNC configuration, and create line-of-sight to the private network through injection capability in a single deployment. This way you don't need the reverse invoke proxy.
Each of the described solutions have individual guides on the SAP RFC setup and how to expose the configuration for SAP SNC.
Can highly recommend my colleague Taylor Brazelton’s blog for SNC from Power Platform and On-premises Data Gateway.
Find below an SAP SNC config sequence with self-signed certificates generated by OpenSSL. Through this setup AS ABAP accepts requests protected by SNC via the SHIR.
I assume you have already installed the SHIR on a suitable windows machine and taken care of required installations like SAP Java Connector (JCo), SAP Connector for Microsoft .NET (NCo), and .NET Framework. My samples and script commands are Windows specific. However, Linux works the same way with slightly different commands.
.\SAPCAR_1200-70007719.EXE -xvf .\SAPCRYPTOLIBP_8553-20011729.SAR -R .\..\libs\sapcryptolib
mkdir sapsecudir
cd .\sapsecudir
[Environment]::SetEnvironmentVariable("SECUDIR", "C:\sapsecudir", "Machine") # Sets the variable permentaly on the system.
$env:SECUDIR = "C:\sapsecudir" # Updates the current powershell session as there currently does not exist a function to reload.
openssl genpkey -algorithm RSA -out rootCA/ca.key.pem -pkeyopt rsa_keygen_bits:2048
openssl req -x509 -new -key rootCA/ca.key.pem -days 7305 -sha256 -extensions v3_ca -out rootCA/ca.cert.pem -subj "/O=Contoso/CN=Root CA"
openssl genrsa -out sncCert/snc.key.pem 2048
openssl req -key sncCert/snc.key.pem -new -sha256 -out sncCert/snc.csr.pem -subj "/O=Contoso/CN=SNC"
openssl x509 -req -in sncCert/snc.csr.pem -days 3650 -CA rootCA/ca.cert.pem -CAkey rootCA/ca.key.pem -CAcreateserial -out sncCert/snc.cert.pem
openssl pkcs12 -export -out snc.p12 -inkey sncCert\snc.key.pem -in sncCert\snc.cert.pem -certfile rootCA\ca.cert.pem
.\sapgenpse.exe import_p12 -p SAPSNCSKERB.pse C:\Users\shir-admin\Documents\snc.p12
One way of doing that is using transaction RZ10 and browsing the parameters prefixed with SNC. See this SAP document on the required “SNC Parameters for X.509 Configuration” settings and their implications.
If there is no configuration yet execute the transaction SNCWIZARD and maintain settings for X.509 credentials. Take note of the SNC private key subject. The CN will be required later.
Add your SNC client (I named mine PRV for Microsoft Purview) to the SAP Access Control List (ACL) using transaction SNC0 and allow RFC and CPIC connections.
sapgenpse.exe maintain_pk -p SAPSNCSKERB.pse -v -a C:\sap\contoso-public-key.crt
Now your SAP trusts connections coming from your SHIR.
.\sapgenpse.exe seclogin -p C:\sapsecudir\SAPSNCSKERB.pse -x your-pse-pin -O "NT SERVICE\DIAHostService"
Verify credentials like so
.\sapgenpse.exe seclogin -l -O "NT SERVICE\DIAHostService"
You can delete them like this:
.\sapgenpse.exe seclogin -d -O " NT SERVICE\DIAHostService "
Use the -h parameter to get help with the sapgenpse command line tool or check the command reference here.
Navigate to your client application and supply the SNC configuration you have prepared. Some apps require an SAP user and password in addition even though providing a client certificate would be enough for a technical connection (remember: no user mapping or SSO).
This gives you the option to further trim down access. Use transaction SU01 and the SNC tab or the maintenance view “VUSREXTID” from transaction SM30 to configure the SNC external ID (CN) to your SAP user name.
See below sample taken from the connection configuration fly-out pane on the Azure portal UI. It can be applied, however, to any SNC client configuration. See further samples here and here.
Trigger “Test connection” and marvel at the SNC secured communication test from Microsoft Purview to AS ABAP😊
Or go even a step further and call your first RFC. RFC_PING or STFC_CONNECTION might be a suitable one in case your target is not yet operational or not identified yet.
That’s a wrap 🌯. You learned today how to secure your technical RFC connections from third party apps to AS ABAP systems using SNC. The guide keeps it simple so you can establish a stable setup base from which to iterate on more complex setups confidently 😊Generate SOAP services for your RFCs and use TLS in case SNC is not an option.
By the way: When introducing an API Management solution between your 3rd party app and the SOAP service on AS ABAP you may use OAuth2, or OpenID Connect on the client. You still need to translate on the API Management layer to an auth mechanism that AS ABAP supports. Either way a step forward in securing your SAP connections.
Happy integrating with SAP!
#Kudos again to Savas Akgol, @MartinRaepple, and @Frank_Buchholz for helping with some of the hard parts 🙏
Cheers
Martin
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
3 | |
3 | |
2 | |
2 | |
2 | |
2 | |
2 | |
2 | |
2 | |
2 |