NW RFC SDK: Non-SAP to ABAP with username (trust relationship)

Question

Hello,
I have a quite challenging non-SAP-to-ABAP RFC scenario with a trust relationship.
Hereu2019s the scenario:
An Oracle database server acts as an RFC client and calls RFC function modules in an ABAP server. (I assume the Oracle programmers are going to use NW RFC SDK 7.1 or JCo 3.0 on the Oracle server and call that from their PL/SQL based database application.)
The challenge is that I donu2019t want to use a single u201Ctechnical useru201D on the ABAP side because that would mean that all the users on the Oracle side would be mapped to one single ABAP user. Also, I donu2019t want to have to store individual ABAP passwords on the Oracle side.
Instead, I want the ABAP server to trust the RFC client the same way it might
a) trust a NetWeaver AS Java server after installing the Java serveru2019s certificate in transaction STRUSTSSO2 or
b) the way it might trust another ABAP server after configuring a trust relationship (transaction SMT1?)
The ABAP server should accept incoming RFC connections from the Oracle RFC client with just the user name and no password given and run the resulting processes in the ABAP system under the user id given in the RFC call.
I imagine the ideal solution somehow along the following lines (simplified scenario for a PC-based prototype):
- I download run a program that creates a certificate file (public key?) which I import into the ABAP system.
- The same program creates a matching file (private key?) for the RFC client.
- For reasons of simplicity, let us imagine the RFC client as a stand-alone Java SE application running on a PC.
- The Java SE application uses the JCo library to connect to the ABAP system.
- When opening the connection, it passes a username, but no password. Instead, it passes a Base64-encoded string that was generated by our key/certificate generator program.
- On the ABAP side, the function modules are run under the username used by the Java SE application when establishing the RFC connection.
Is that possible at all? How would you solve this?
Thank you very much in advance and best regards,
Thorsten

Answer 1

Hello,
Thanks a lot for your extremely high-quality replies. Iu2019ve been trying to work with them.
Frankly, just when (after Gregoru2019s and Timu2019s posts) I was hoping that working my way deeply enough into SNC, I would be able to solve my problem, Wolfgang comes along and tells me what Iu2019m aiming at wonu2019t work. Now Iu2019m confused.
The way I understand Wolfgang, the special trust an AS ABAP can put into another AS ABAP or an AS Java (u201Cremote RFC client, give me one certificate and I will accept every username if they come from youu201D) can not be put into a custom-made remote server software (such as the Oracle server application) acting as the RFC client, because when acting as RFC clients, the remote AS Java or AS ABAP use proprietary elements of the RFC protocol which are not available to me when I program my RFC client in the Oracle application.
@Wolfgang, is that correct?
Solution 1: Individual X.509 Certificates
Instead, I can establish X.509-based trust relationships at the level of individual usernames: create a certificate for each Oracle user, import them into the AS ABAP, map them to an ABAP user, and store the certificate on the Oracle side (Iu2019m still note sure about the different certificates and keys used publicly and privately here).
Solution 2: AS ABAP as User Management Engine for the Oracle Application
I can also see an alternative that would spare me the trouble of generating, importing, mapping and storing the certificates: delegate the user management to the AS ABAP and delete the (custom-built) logon and password-checking mechanism in the PL/SQL application:
Users are created centrally in CUA and distributed along with their passwords into (among others) the AS ABAP.
When a user logs on to the PL/SQL application, the username and password are sent for validation to an ABAP BAPI.
If authentication is successful, the AS ABAP returns a SAPLogon ticket which can be stored in the session context of the PL/SQL application and used in subsequent RFC calls. The password (a hash?) would only be transferred once during logon.
What do you think? Would both solutions work or am I still getting something wrong? Can you see a better alternative that would reduce
for solution 1 the administrative overhead for synchronization
for solution 2 the run-time dependency Oracle-ABAP and the change impact on the Oracle applicationu2019s user management concept?
Thanks a lot,
Thorsten