SapJCo3: SNC between Java application with multiple SAP ABAP application servers

[EElijah]

Hi everyone,

I am currently able to setup a functioning SNC between a Java application (through SAPJCo library) and a SAP/HANA system using these 2 scenarios according to the procedures described on this  SAP Note. On the server where the Java application runs, the PSE and cred_v2 files are located in same folder whose path is the value of the SECUDIR environment variable. However, this architecture does not seem workable when if another SAP system is to be SNC connected to same Java application. As far as I have tested, the cred_v2 file supports storing credentials for talking to only a single SAP system. How then can one SNC connect a single Java application to multiple SAP ABAP systems ?

I have searched online and have not found useful threads. One SAP Community thread mentions a link that offers no useful information. 

[Ryan-Crosby]

For the steps regarding the configuration of the JCo DestinationProvider you would need to use the parameters jco.client.mshost, jco.client.msserv, jco.client.group & jco.client.r3name instead of jco.client.ashost and jco.client.sysnr.  Unable to say with certainty if that requires any changes to the PSE configuration, however.

Regards,

Ryan Crosby

[EElijah]

Hi Ryan. Many thanks for the reply. There are 2 kinds of connection I can make to the SAP systems: a direction connection (using the SAP ABAP server host name and instance number) and a logon-balancing connection. For a start I am using direct connections, in which I am setting, among other parameters, jco.client.sysnr and jco.client.ashost. The SNC connections work as I explained so I don't think this is the issue. Your suggestion is important for logon-balancing connections.

Further details about my situation: Lets take the simpler scenario for SNC connection where no certificate from the Java app needs to be imported into the SAP system. We just need the PSE from latter to create the cred_v2 file on the side of the Java app. On the server where the Java application runs, SECUDIR environment variable has been defined. This is where the PSE and cred_v2 files will be located. The Java app is run by an operating system user say "foo". The cred_v2 file is created from the command

sapgenpse seclogin -p pse_file_name -O foo

Running this the first time for a SAP system creates the cred_v2 file. For the second SAP system, running same command with the right pse_file and user, I can see from the contents of the cred_v2 file there are now credentials for reading the 2 different PSE files. Now I test connection. The first SAP system I get a connection successful and can do more with the connection. For the second however, I get error: GSS-API(maj): Miscellaneous failure GSS-API(min): A2210223:Server does not trust my certificate path target="..." Drilling down to see the logs on the second SAP system. I notice that the certificate infos of the first SAP system is sent during the connection attempt, which ought not to be. For simplicity, I remove time stamps as every line represent an action in some time. I have checked to make sure from the Java app, the right connection details for the second are sent but it appears deep during the connection only the first entry in the cred_v2 file is always used.

Certificate verification result (failed)
 ----- BEGIN VERIFICATION RESULT -----
# --- Messages -----------
INFO: Verification time - Sun Sep 29 18:00:55 2024
ERROR: The verified certificate chain is complete but no certificate is trusted.
# --- Summary -----------
#01 Certificate (End Entity): VALID
Subject:                      CN=SAPSYSTEM1, O=Company, C=DE
Issuer:                       CN=SAPSYSTEM1, O=Company, C=DE
Fingerprint (SHA256):         6A:60:2B:7B:1B:82:46:81:25:9F:D0:9D:CF:73:C2:62:5A:D5:25:4B:DD:35:30:30:6F:36:54:BC:7F:BF:80:CD
Validity:                     Wed Sep 25 13:00:01 2024 / Fri Jan  1 01:00:01 2038
PKI validation:               FAILED
Trusted:                      ERROR: Untrusted - Complete Chain
# --- Results -----------
Certificate Result #01:       FAILED
Certificate (End Entity):     [6A:60:2B:7B] CN=SAPSYSTEM1, O=Company, C=DE
Trusted:                      ERROR: Untrusted - Complete Chain
Policy:                       Untested
Revocation:                   Untested
OCSP:                         Untested
Issuer:                       Untested
CRLs:                         Untested
# --- Environment -----------
Trust in PSE:
Token URI                      : tokpse:/usr/sap/SAPSYSTEM2/D00/sec/SAPSNCS.pse
Trusted certificate            : CN=SAPSYSTEM2, O=Company, C=DE
Trusted certificate            : CN=SAPSYSTEM2, O=Company, C=DE
----- END VERIFICATION RESULT -----
Srv-80000000: Peer certificate not trusted

This is the output from the "sapgenpse seclogin -l" command

PS C:\Path\to\secudir> sapgenpse seclogin -l
 running seclogin with USER="foo"

 0 (LPS:OFF): CN=SAPSYSTEM1, O=Company, C=DE
         (LPS:OFF): C:\Path\to\secudir\sap-system-1.pse

 1 (LPS:OFF): CN=SAPSYSTEM2, O=Company, C=DE
         (LPS:OFF): C:\Path\to\secudir\sap-system-2.pse

 2 readable SSO-Credentials available

[Ryan-Crosby]

@EElijah a completely separate SAP system or simply another application server amongst the same SAP environment? It would make no sense for an entirely separate SAP system to share secure credentials with another environment, but if you are referring to the load balancing scenario, then the message server is your way forward (only way).