Authentication Options

[bensonrlee]

For a serverless environment, such as cloud native applications, what would be the best option for authentication to an on-premise SAP system? Is there an option to potentially use certificate based authentication like using a pfx / p12 file?

There are about 3 to 5 authentication options described here. Username and password is the least secure so probably not recommended, even if it is the easiest among the options.

The second option appears to depend on the snc_lib which likely requires cred_v2 file for opening the user pse and authenticating. This would not be readily available for a serverless environment.

The third option sounds promising but I am not clear how to setup this prerequisite: "The trusted relationship must be established between the ABAP backend system and the client system." Can anyone help with a link on how this can be done?

Also, it seems to depend on the SECUDIR environment variable. Is it possible to provide this value to the library without relying to the SECUDIR environment variable?

Thanks in advance for anyone who can help!

[Ulrich-Schmidt]

In fact, with Patch Level 8 of the NW RFC Lib, which has just been released, there are now features available for so-called "Websocket-RFC", which uses SSL/TLS (instead of SNC) and the standard SSL handshake with certificate logon. There are only two questions:

1. I'm not familiar with how node-rfc passes the logon parameters down to the NW RFC Lib, i.e. if the node application can just pass any arbitrary parameter, then your app can already pass the necessary parameters to the NW RFC lib (they are documented in section 4. of the sapnwrfc.ini file that comes with the NW RFC installation). However, if node-rfc accepts only a fixed set of parameters, then it first needs to be modified to also accept the new TLS_... parameters.
2. And the main question is, how new is your on-premise SAP system? This feature is also pretty new on SAP system side.

If both prerequisites are fulfilled, all you need to do is to convert your .p12 / .pfx file into .pse format (can be done with the sapgenpse tool), map the SSL client certificate to a SAP user (transaction CERTRULE or EXTID_DN -- never quite sure, which one works in which cases...) and feed the NW RFC lib with the required parameters.

[Ulrich-Schmidt]

Another question to think about is: how do you want to expose the on-premise backend system to the internet? RFC access (both, via the classic RFC protocol and via the Websocket RFC protocol) would require to open a port to the backend system from the outside world, something that is not necessarily desirable.

For situations like these, alternative solutions are available:

1. Install a SAP Business Connector in front of the backend system. (See https://support.sap.com/sbc-download ) This can even be done in a "reverse invoke" setup: one SBC is installed in the DMZ and a port from outside is opened to that instance, a second SBC is installed in the inner firewall next to the SAP system. The inner SBC opens a connection to the outer SBC "from the inside" (meaning no ports need to be opened to allow access to the inner network from the outside!) and then waits for requests that arrive on the outer SBC.

The entire data flow then looks like this: the node application sends an HTTP request to the outer SBC (which is visible in the internet), the outer SBC passes it to the inner SBC (via the open connection that was opened from the inside to the DMZ), the inner SBC then converts it to RFC and executes it on the backend system.
This approach has several advantages:

• the node application does not need to store any credentials to the on-premise SAP system.
• as already described, the SAP system does not need to be exposed to the internet. The only "attack surface" is the outer SBC (which also does not have any backend credentials).
• the inner SBC allows to execute only a fixed number of function modules. FMs not explicitly enabled, cannot be executed. (If you allow the node application direct RFC access to the backend, then potentially all FMs of the SAP system could be executed from outside. UCON could be used to mitigate this, but UCON would then also affect connections that come from internal clients -- which you may not want to restrict.)
• the SBC is very flexible and allows custom logic (via a graphical UI). So for example one HTTP request could be setup to trigger an entire chain of function module calls or IDocs into the SAP system.
• the SBC can be used to monitor the incoming requests, send mail alerts to an administrator, etc.

2. If the cloud native application is running on the SAP Cloud (BTP), then the SAP Cloud Connector can be used to establish an SSL tunnel between Cloud and backend system. However, this is more streamlined for Java applications using JCo for RFC communication.

[bsrdjan]

if node-rfc accepts only a fixed set of parameters, then it first needs to be modified to also accept the new TLS_... parameters.

All connection parameters are supported, including TLS_* and TypeScript interface is provided.

[bensonrlee]

I can see that websocket option is now available including the option to authenticate via client certificate:

Authentication with client certificate

DEFAULT
TLS_SAPCRYPTOLIB=/usr/local/sap/cryptolib/libsapcrypto.so

DEST=WS_ALX_CC
TLS_CLIENT_CERTIFICATE_LOGON=1
WSHOST=ldcialx.wdf.sap.corp
WSPORT=44318
CLIENT=000
LANG=EN
TLS_CLIENT_PSE=/Users/rfctest/sec/rfctest.pse

I noticed though that there is still reference to TLS_CLIENT_PSE. Does this mean that it still requires a cred_v2 file to authenticate?

[rstenet]

cred_v2 is only required if the PSE is PIN/Passphrase protected. As you are on Linux this doesn't add any security, so you can have the PSE without PIN.

[bsrdjan]

Please re-open if needed