Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

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

former_member182046
Contributor
0 Kudos

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

1 ACCEPTED SOLUTION

WolfgangJanzen
Product and Topic Expert
Product and Topic Expert
0 Kudos

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.)

So, the RFC client is not a user agent (i.e. acting on behalf of a single individual human being) but a server component (i.e. serving multiple users). In such a server-to-server communication scenario you cannot use any mechanism (here: any SNC product) that identifies the communication partner (here: the RFC client = server component) for Single Sign-On purposes.

> 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?)

Sorry, but that's not possible.

In both cases proprietary tokens are used in combination with this proprietary protocol (RFC) - and external parties are not able to create those tokens.

The solution is: use standards - here: WS-Security (SAML Tokens).

The NetWeaver Application Server (NWAS) ABAP does support WS-Security as of release 7.0.

You might want to take a look on https://wiki.sdn.sap.com/wiki/display/Security/SingleSignonforWeb+Services for further details.

Regards, Wolfgang

21 REPLIES 21

gregorw
Active Contributor
0 Kudos

Hi Thorsten,

perhaps my Blogs:

Authenticate from PHP to a Web Service using X.509 Certificates

/people/gregor.wolf3/blog/2006/09/30/authenticate-from-php-to-a-web-service-using-x509-certificates

Setup data encryption between RFC Client and Web AS ABAP with SNC

/people/gregor.wolf3/blog/2006/09/29/setup-data-encryption-between-rfc-client-and-web-as-abap-with-snc

can be a guide into the right direction.

Is there a human User involved using a Web Application? Then another posibility to have Single Sign On could be Kerberos authentication to the Portal and then using the SAP Logon Ticket (SSO2Ticket) for the RFC Connection.

Best regards

Gregor

tim_alsop
Active Contributor
0 Kudos

Hi,

You can do this using a impersonation with SNC authentication/security. You can use any SNC mechanism you like, e.g. Kerberos or x.509. The approach used is same approach used by external ITS product when SSO is implemented on ITS server using a PAS module - in this case, the ITS server passes a userid (no password) over an SNC session to ABAP server, and since ABAP server considers SNC to be secure it trusts the connection and is able to issue an SSO2 ticket for the given userid. When the SSO2 ticket has been issued, this can be used to authetnicate the RFC connection.

Sorry if above is a big vague - I don't have time right now to search and remind myself of the exact details, but I know what you want can be acheived using the above approach. I hope it is helpful in some way.

Thanks,

Tim

0 Kudos

Thank you very much both, Gregor and Tim, for your quick and helpful responses.

Quick feedback: A quick sighting of your posts and blogs indicates that I at least get the puzzle pieces for my solution from them.

There is no web application involved and I don't need the connection between the non-SAP RFC client and the ABAP server to be encrypted. That's why I didn't think that SNC would be part of my scenario.

Now I understand that using an SNC connection with a single certificate is a way to make the ABAP server issue a Saplogon Ticket via RFC for any username. This means that I wouldn't need to create individual X.509 certificates for each user and map them to the ABAP users in the ABAP system, but I could have a one single certificate that allows the RFC client to establish an SNC connection to the ABAP server, pass a username, get a SAPlogon Ticket, and use this for further RFC connections which will run under that username?

Is my understanding correct here?

Also, suppose I trust my RFC client completely. This means that I don't want any external authority to check username/password combinations coming from the RFC client or even validating the individual usernames against any other database (such as a Windows domain). If there is an SNC authority, I want it to be as "dummy" as possible.

Am I thinking along the right lines here?

Best regards,

Thorsten

tim_alsop
Active Contributor
0 Kudos

>

> Is my understanding correct here?

Yes, your understanding is correct. Also, if you only need to make one RFC call for each Oracle user you can avoid the 'get SSO2 ticket' part and just use the SNC session (secured using a single Kerberos identity or x.509 cert) to run your RFC on ABAP server.

>

> Also, suppose I trust my RFC client completely. This means that I don't want any external authority to check username/password combinations coming from the RFC client or even validating the individual usernames against any other database (such as a Windows domain). If there is an SNC authority, I want it to be as "dummy" as possible.

I am not quite sure I understand what you are asking, but it might help to understand that SNC is an interface for secure connections and for authentication. The SNC interface requries a GSS-API v2 library, and since GSS-API is a standard you can use standard security mechanisms such as Kerberos or x.509. The security mechanism used by the GSS-API library must be same on both client and server. It is also recommended that you use a SAP certified library to benefit from a reliable and supported solution. There are a few vendors who provide such SNC libraries and they are described on SAP EcoHub.

>

> Am I thinking along the right lines here?

>

> Best regards,

>

> Thorsten

WolfgangJanzen
Product and Topic Expert
Product and Topic Expert
0 Kudos

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.)

So, the RFC client is not a user agent (i.e. acting on behalf of a single individual human being) but a server component (i.e. serving multiple users). In such a server-to-server communication scenario you cannot use any mechanism (here: any SNC product) that identifies the communication partner (here: the RFC client = server component) for Single Sign-On purposes.

> 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?)

Sorry, but that's not possible.

In both cases proprietary tokens are used in combination with this proprietary protocol (RFC) - and external parties are not able to create those tokens.

The solution is: use standards - here: WS-Security (SAML Tokens).

The NetWeaver Application Server (NWAS) ABAP does support WS-Security as of release 7.0.

You might want to take a look on https://wiki.sdn.sap.com/wiki/display/Security/SingleSignonforWeb+Services for further details.

Regards, Wolfgang

0 Kudos

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

0 Kudos

P.S.: @Wolfgang, I agree with you that this would be much easier if HTTP-based transport and especially SOAP Web Services with SAML were part of the scenario, but that is unfortunately currently out of the question as there is currently not the slightest chance of the other people involved even considering this option.

The only options are: RFC with a single hard-wired technical user or can I find a cheap & quick way that allows the RFCs in the ABAP system to run under individidual user ids?

0 Kudos

>

> 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

I am not clear why Wolfgang would suggest the approach does not work. I have seen it working - for example, recently I worked with a customer who was using a business objects application running on a windows server, and users authenticate to the web server using any method that is configured. The business objects code on web server then uses SNC with Kerberos to establish a secure tunnel with SAP ABAP AS, and uses this SNC session to logon as a particular user - the ABAP system sees the function module being executed by different users, even though the SNC session is secured using a single common identity.

Interestingly, the business objects documentation explains how to set this connection up - we just changed it to use Kerberos instead of x.509 certs. As I already mentioned, the actual SNC mechanism used doesn't change anything.

0 Kudos

I have also seen this before.

Actually, a BusinessObjects consultant recently explained to me that the system was issuing SAP Logon Tickets to integrate the BO system with the ABAP BW as backend so that the user could access data in their own context, and subject to their own backend roles.

Of course that makes sense, but under the hood in the code it is slightly different than on the surface in .ppt presentation...

I do agree with Wolfgang though that there are more secure and scalable ways of implementing such scenarios. Also, if someone gets hold of your system PSE then a layer of security is lost.

Cheers,

Julius

0 Kudos

Julius,

I don't understand your reference to PSE... When I set this up and got it working for one of our customers, we didn't use any PSEs.

I also cannot see what is 'not scalable' and 'less secure' about the approach I have expeirence of and I know works.

Thanks,

Tim

0 Kudos

I guess in your (product) case you are using the kerberos authentication of the user logged onto the workstation, so you are closing the loop again to the "real" user.

My understanding of this discussion is that the systems need to trust each other first (hence system PSE). Any other communication partner in the network with the same public key would potentially be able to participate in the communication as well? AFAIK you need system PSEs to issue valid SAP Logon Tickets - which was the direction the idea was going for.

Regarding scalability, I was refering to the WebServices possibility mentioned by Wolfgang (which is not an option here for whatever reasons) which would not be limited to security within one domain (or multiple subdomains) for the reuse of kerberos.

If the non-SAP application and the ABAP system are in the same network and used by the same domain, then I agree the scalability and trusted system peers considerations do not play a role, particularly if you don't have to map external IDs to internal ones (harmonized user ID naming conventions)

On a lighter note, what about [Open ID|http://en.wikipedia.org/wiki/OpenID] as another option?

I guess there is some coding involved and support might be hard to find (I know from customers that yours is very good!) but for adventurous folks I thought it worth mentioning.

Cheers,

Julius

0 Kudos

Julius,

This conversation/thread is in danger of "going off subject" and so I want to bring it back to what Thorsten is looking for. My understanding is that he wants a user to authenticate to Oracle, and then the Oracle application needs to communicate with SAP using the same userid and preferably without having to store userid's for each SAP user or having to manage certificates for each SAP user. The approach I suggested and have used (with Business Objects products and other products) is where the server process which needs to access SAP and run a function uses an SNC secured session, and over the SNC session the code can tell SAP which SAP user it wants to use, and this can be done without a SAP user password because SAP can be configured to trust the SNC secure session.

So, there are no SSO2 ticket required, but SSO2 tickets can be used to avoid having to impersonate the user each time same user wants to authenticate to SAP. For example, if a user logs onto Oracle and then the Oracle applciation runs a SAP function module and finishes - there is no need to use SSO2 tickets because this is not a Single SignOn requirement. Instead, each time a user needs to authenticate, the single SNC session can be used to run the function module as a particular SAP user. The cases I have worked on, SSO2 tickets were not used, which means that PSE is not used.

Thanks,

Tim

0 Kudos

>

> >

> > 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

> I am not clear why Wolfgang would suggest the approach does not work. I have seen it working - for example, recently I worked with a customer who was using a business objects application running on a windows server, and users authenticate to the web server using any method that is configured. The business objects code on web server then uses SNC with Kerberos to establish a secure tunnel with SAP ABAP AS, and uses this SNC session to logon as a particular user - the ABAP system sees the function module being executed by different users, even though the SNC session is secured using a single common identity.

> Interestingly, the business objects documentation explains how to set this connection up - we just changed it to use Kerberos instead of x.509 certs. As I already mentioned, the actual SNC mechanism used doesn't change anything.

>

Well, in this case, the RFC client (Business Objects Server) would need to be capable of "impersonating" multiple users (in order to aquire their Kerberos credentials) - and at the same time being able to reliably tell them apart. Frankly speaking: I'm not familiar with the internals of the Business Objects Server, so I cannot tell you anything about their session management and the session isolation concept. But I know that if the sessions are not properly isolated then you'll run into problems (resulting in wrong assignment of backend sessions to Business Objects sessions).

0 Kudos

Thanks again to the three of you for providing your highly valuable input. I'm beginning to see a little clearer now.

I see three alternatives:

1) SNC ABAP trusts Non-ABAP

The SNC solution without SSO2 tickets would allow Oracle users to keep their Oracle passwords different from their SAP passwords, which would be good because I want the current solution to be minimal-invasive with regard to the user concept, user management processes, password standards, etc.

2) SSO2 tickets issues by Oracle

Get the Oracle server to issue SSO2 tickets based on Oracle passwords - would probably require some hacking but I would prefer it to the SNC solution. Minimal-invasive with regard to the user concept and user mgt process like 1) and I wouldn't have to learn much about SNC.

3) SSO2 tickets issued by ABAP

Have the Oracle server request SSO2 tickets from the ABAP server (or a portal or any other ABAP system) based on ABAP username/password. This is probably the most easily implemented solution but the one with the gravest side effects because the Oracle server would delegate its (application-specific, home-made) user management and password security to the ABAP system.

I will take some time today to look deeper into the clues you have provided and especially Gregor's blog (luckily, they are always very hands-on) to get an impression of which might be easier to implement without prior knowledge of SNC.

Also, I will have a look at the code of the function module Gregor recommends and also at the code of the ICF handler class that issues mysapsso2 tickets upon request to see if they provide any clues towards enabling the Oracle server to issue Saplogon tickets.

I'll come back with more questions.

Best regards,

Thorsten

0 Kudos

> Thanks again to the three of you for providing your highly valuable input. I'm beginning to see a little clearer now.

>

> I see three alternatives:

>

> 1) SNC ABAP trusts Non-ABAP

> The SNC solution without SSO2 tickets would allow Oracle users to keep their Oracle passwords different from their SAP passwords, which would be good because I want the current solution to be minimal-invasive with regard to the user concept, user management processes, password standards, etc.

Well, that's possible - based on the solution used by the (external) ITS for the PAS solution:

- it's mandatory to use SNC (to be able to identify the RFC client)

- SNCSYSACL needs to be maintained (using transaction SNC0): flags "RFC" and "Ext. ID" need to be set

- USREXTID needs to be maintained for the mapping (Oracle UserID -> ABAP UserID), if the mapping is regular, you might be able to use ABAP report RSUSREXTID to generate the USREXTID entries

Notice: you can use RfcOpenEx() with options EXTIDTYPE and EXTIDDATA to create an RFC connection using this authentication method. You do not need to call function module SUSR_CHECK_LOGON_DATA to request a Logon Ticket first and then use the Logon Ticket to call RfcOpenEx() - this is much too complicated (and also error-prone, see my comment below).

> 2) SSO2 tickets issues by Oracle

> Get the Oracle server to issue SSO2 tickets based on Oracle passwords - would probably require some hacking but I would prefer it to the SNC solution. Minimal-invasive with regard to the user concept and user mgt process like 1) and I wouldn't have to learn much about SNC.

SAP does not provide any coding to create Logon Tickets externally.

So this is not an option.

> 3) SSO2 tickets issued by ABAP

> Have the Oracle server request SSO2 tickets from the ABAP server (or a portal or any other ABAP system) based on ABAP username/password. This is probably the most easily implemented solution but the one with the gravest side effects because the Oracle server would delegate its (application-specific, home-made) user management and password security to the ABAP system.

Well, you have to keep in mind that Logon Tickets have a fixed lifetime.

After exceeding the validity period Logon Tickets will no longer be accepted by the recipient system.

See also my comments on point 1.

Edited by: Frank Buchholz on Jul 6, 2009 11:23 AM: The reply seems to be to long, therefore I split it into two parts.

0 Kudos

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

Posted: Jul 6, 2009 10:53 AM Wolfgang Janzen response in response to: Thorsten Franz

> I will take some time today to look deeper into the clues you have provided and especially Gregor's blog (luckily, they are always very hands-on) to get an impression of which might be easier to implement without prior knowledge of SNC.

> Also, I will have a look at the code of the function module Gregor recommends and also at the code of the ICF handler class that issues mysapsso2 tickets upon request to see if they provide any clues towards enabling the Oracle server to issue Saplogon tickets.

>

> I'll come back with more questions.

Well, the main issue is: how to ensure that the external sessions (Oracle) are mapped properly to the the internal sessions (RFC -> ABAP) ...?! Special care is required to ensure that the RFC connection is closed when the external session is terminated ... - otherwise you'll very soon run out of backend sessions. That part you should not under-estimate.

0 Kudos

Hello again,

Thanks again for your invaluable input.

I'm currently going for option 1 (SNC: ABAP trusts non-ABAP):

- maintain SNCSYSACL and USREXTID

- create RFC connection with RfcOpenEx() with options EXTIDTYPE and EXTIDDATA

As a precondition, I have followed Gregor's blog and installed the SAP Cryptographic Library as well as set up SNC and SSL.

My next steps will be to follow Gregor's blog series further and establish a trust relationship and user mapping, then write an RFC client that connects to the ABAP system via SNC and logging on with a certificate. As a diversion from Gregor's blog, I plan to write the RFC client in Java instead of Ruby and use JCo as a connector.

I will keep you posted about the further development and the road blocks I might encounter.

Best regards,

Thorsten

0 Kudos

Please focus also on the session management issues ...

Those are often neglected - and later found out to be extremely relevant ...

0 Kudos

Hi Wolfgang,

Thank you for your advice. The message and the possible problems have arrived - the reason I'm currently not focusing on it is just because I do one thing after another, sort of building that bridge starting in the ABAP system, then building the connectivity layer, and an RFC client stub. Once I have a working prototype for a trusted RFC client I will pass it on to my Oracle colleagues who are going to connect the actual client application with the ABAP system.

I will make it clear that the connections have to be handled economically:

- use connection pooling on the client side

- handle RFC sessions with care; if necessary, use GUID-like session handles (in case PL/SQL cannot hold a reference to a Java object) to identify RFC sessions with a user context in the client application

- close sessions that are no longer needed

- overhead for establishing a new backend session may be "cheaper" than killing the backend

- strive for statelessness

- use load balancing to benefit from multiple application server instances

Is that what you had in mind?

Best regards,

Thorsten

0 Kudos

Well, I think you've got the point - and I'm sure you'll soon realize that you've to invest quite some effort to achieve a sound and robust solution.

Session (and Resource) Management is quite critical - with regards to security (i.e. to ensure not to "mix up" the sessions, assigning wrong backend connections) and robustness (i.e. to ensure that unused sessions are closed, releasing server resources - otherwise there will be a "resource leak" resulting in a system halt).

Conclusion: the more components are involved, the more effort needs to be invested to achieve a sound and robust system compound.

-> end-to-end communication is preferred over mediated communication (via numberous middleware components)

Don't get me wrong: I'm not promoting monolithic (ABAP) systems.

I just want to create some awareness that compounds of (inhomogenous) system components (Distributed Systems) introduce a new kind of challenges.

-> once you've managed to achieve SSO you are only halfway through (or even less)

-> you also have to keep track of the sessions you have created using SSO techniques

-> you have to provide SLO (single logoff) functionality, as well

Cheers, Wolfgang

gregorw
Active Contributor
0 Kudos

Hi Thorsten,

please check out my other Blog:

Single Sign On with External ID implemented in Ruby

I think that will lead you to the solution. In shot it uses SNC to establish a first RFC connection which is used to call the Function Module SUSR_CHECK_LOGON_DATA. The external Username has to be passed to this funciton module. The mapping of the external username to a SAP User has to be maintained in VUSREXTID. Then the Function Module will return a SSO2 Ticket that can be used to establish another RFC connection which then use the other users credentials.

At SAP RFC SNC Client to get a SAP Logon Ticket for External ID you find also a sample implementation using JCo.

Best regards

Gregor