SNC for server to server - interop question

[tim_alsop]

If SNC is used on a SAP system the snc/gssapi_lib param on the system is used to determine which SNC library to use, so if an RFC is submitted on one server to communicate with another and the session is secured using SNC the same snc/gssapi_lib library (or one which is interoperable) needs to be configured on both systems. e.g. They both need to communicate using the same protocols.

If above is not possible, e.g. for company to company communications one company might be using a Kerberos gss-api library for SSO purposes and the other company might be using the SAP supplied SAPSECULIB, or another vendor SNC library - in this case, how can we make the two servers communicate using SNC ?

My initial ideas are:

1. We could use a gss-api library that negotiates which protocol to use (using SPNEGO mechanism oid) and then it would be possible to use x.509 on one system and Kerberos on another. I am not aware of such a library existing, so perhaps this creates an opportunity for a vendor such as us to code and sell ???

2. I wondered if there was a way to setup an intermediate system, e.g. using SAP router so that RFCs can be run between systems using different SNC libraries. I am not familiar with SAP Router to know if this can be done, so if anybody can help me I would appreciate it.

3. Maybe SAP are planning to allow multiple snc/gssapi_lib parms so that multiple protocols can be supported by one system ? If this was the case we would not have any problem.

If anybody has any ideas or information to help me with this I would be very grateful.

Thanks,

Tim

[Former Member]

Hi Tim,

An idea to find more ideas: There used to be a solution called SAP Business Connector but it fell out of support about 2 years ago I think. If you search for threads / notes / documentation on the technologies which have replaced it and keep an eye out for SNC, then you might get a hit or two.

Cheers,

Julius

[tim_alsop]

Julius,

I did some quick research and found some references to SAP BC. It seems it is mostly replaced by SAP XI. I don't think XI does what we need - we are looking for a way to route RFC communications between SAP systems and do it using network security offerred by SNC interface.

I did get a msg from Wolfgang regarding this, but it was in emails we were exchanging. I wanted to keep the information in this SDN forum instead of in email in case it becomes useful to somebody else in future ...

Wolfgang said:

In general, two different companies will use two different SNC products.

In that case it will be impossible to establish an end-to-end SNC protected communication.

As you've already mentioned, only a partially SNC-protected communication link is possible:

using two SAProuters (one installed at each company) which both use the same SNC library (e.g. SAPcryptolib, provided by SAP, also in use for the service connection to SAP) it would be possible to establish an "SNC tunnel" - provided that the certificates (contained in the PSE, used by SAPcryptolib) have been mutually exchanged between the two communication peers.

However, there would be still a "gap": the communication between the ABAP application server and the SAProuter is then not SNC protected. From the application server's point of view the RFC connection is not SNC-protected; the fact that the SAProuter-to-SAProuter communication track is SNC-protected is transparent to the two ABAP systems.

Thanks,

Tim

[tim_alsop]

Wolfgang,

Regarding the gap you mentioned ? lets suppose we have :

SYSTEM A1 (SNC product A) --- internal network --- SYSTEM A2 --- public network / extranet protected using same SNC lib --- SYSTEM B2 --- internal network --- SYSTEM B1 (SNC product B)

With above, would it be possible to submit an RFC on SYSTEM A1 to communicate with SYSTEM B1 via SYSTEM A2 and B2 or would the communication have to involve RFC jobs on SYSTEM A2 and B2 which forward the session to the next system in the chain ? I am trying to understand whether the presence of A2 and B2 will be seamless to the RFC jobs run between A1 and B1 systems, and just involve configuration of the SAP routers to route the session through.

Yes, I agree that the session between A1 and A2 and between B1 and B2 will be unsecure, but this might have to be accepted in this case since there might not be any other way to do this. Of course company A can convince company B to use same product ?

Thanks,

Tim

Edited by: Tim Alsop on Jan 12, 2008 7:26 PM

[Former Member]

Hello Tim,

Network security is not my field of expertise (actually I am an accountant , but a question I would ask is whether both A1 and B1 can invoke communication?

If it is only invoked by B1 (at least for this RFC and there are no subsequent RFCs (possible)), then B1 is in a stronger position and I would think that A1 would want to request the security (A might be okay with A2 to A1 (and A1 to A2), but B1 to B2 is the risk, right?) Or is A2 to A1 a risk for B?

>

> Of course company A can convince company B to use same product ?

Does company A also have company C, D, E... n as customers using this RFC? In this case, I think that company A should invest in making the RFC itself secure, as n2 and A2 (to A1) might be "public" anyway.

In addition to performance, a possible loss of turnover did occur to me </bean counter>)...

On the other hand, if your product gained a critical mass in this area, then you could become buddies with Bill Gates

Cheers,

Julius

[WolfgangJanzen]

Such a communication (two systems communicating with each other "through" other systems) is not possible in a transparent way. With "system" I'm not referring to SAProuter; a SAProuter is only a communication endpoint for TCP/IP but not for the (SAP proprietary) protocols for which he acts as router.

Referring to your example, this would result in 3 different communication scenarios:

1st communication:

SYSTEM A1 (SNC product A) --- internal network --- SYSTEM A2

2nd communication:

SYSTEM A2 --- public network / extranet protected using same SNC lib --- SYSTEM B2

3rd communication:

SYSTEM B2 --- internal network --- SYSTEM B1 (SNC product B)

Well, if SYSTEM A1 and SYSTEM A2 shall be able to use SNC for communication, then this has to be the same SNC product. Same for SYSTEM B2 and SYSTEM B1. However, SYSTEM A2 and SYSTEM B2 are using different SNC products so they cannot establish an end-to-end SNC communication. But it's possible to establish a "SNC tunnel":

SYSTEM A2 -(w/o SNC)- SAPROUTER A -(SNC)- SAPROUTER B -(w/o SNC)- SYSTEM B2

Notice: the "gap" is the communication between SYSTEM A2 and SAPROUTER A respectivelty the communication between SAPROUTER B and SYSTEM B2. However, that communication usually takes place in a dedicated server network.

Best regards,

Wolfgang

Edited by: Wolfgang Janzen on Jan 13, 2008 5:19 PM

[tim_alsop]

Wolfgang,

Thankyou for your answer. It is very helpful.

Do you have any knowledge of any product from SAP (e.g. something related to XI ?) which might help in this situation ?

I am begining to think that the end-to-end solution using SNC would be best done using a multi-mechanism GSS library which uses SPNEGO mech oid to negotiate a protocol which both systems support and then use that mechanism to exchange keys for security purposes.

Thanks

Tim

[WolfgangJanzen]

> Do you have any knowledge of any product from SAP (e.g. something related to XI ?) which might help in this situation ?

Well, XI is acting as message hub - not as reverse proxy.

Furthermore, might the Integration Server also modify the content of the message (performing data transformations). So, using XI is something entirely different from using a direct end-to-end communication. Regarding SNC XI might be only helpful if using so-called XI adapters (with different SNC products). However, in such a scenario the organization operating the XI component would have to purchase and operate multiple SNC products. I don't think that this can be achieved in real life. It is more likely that all communication peers would agree to use the same SNC product.

> I am begining to think that the end-to-end solution using SNC would be best done using a multi-mechanism GSS library which uses SPNEGO mech oid to negotiate a protocol which both systems support and then use that mechanism to exchange keys for security purposes.

Well, it would be nice if that would be possible. But I'm afraid that GSS (Generic Security Services) is too generic. I doubt that you'll be able to negotiate a mechanism which is common to two different products in general. We all know that even using two Kerberos-based products does not ensure the absense of interoperability issues. That's why the SNC certification only covers same-product scenarios (no interoperatibility tests between different SNC products).

Regards, Wolfgang

Edited by: Wolfgang Janzen on Jan 13, 2008 6:23 PM

[tim_alsop]

Wolfgang,

Actually the "generic" part of GSS mostly covers the interface (e.g. the calls which the SAP SNC adapter makes to the library), not what happens at the lower mechanism level... What I have suggested is possible to code and implement, and in fact, we have already coded something similar. My idea is that we can deliver product functionality which would allow the SNC session between systems to negotiate the mechanism to use depending on which library is configured on the remote system. It will then be possible to use our SNC Kerberos library internally within the company, but between companies the system to system communication can be secured using x.509 certs if the other companies system only support this, or SNC Kerberos if both systems have our SNC library installed.

Anyway, I am still discussing the options with the customer, and have a much better understanding of options which involve SAP router now. Thanks again.

Thanks,

Tim

[WolfgangJanzen]

Well, it will remain a challenge to guarantee this interoperability.

Definetly you'll have to declare which products have been tested for interoperability - and which did not have been tested. In order to perform such interoperability tests you require to install other vendor's products - is your company willing to purchase the products of competitors in order to perform such interoperability tests (at own costs) ...?!

That's why I say: it's not just a technical issue. Usually it's much harder to resolve those non-technical issues than to resolve the technical ones ...

Cheers, Wolfgang

[tim_alsop]

Wolfgang,

I think you missunderstand the scope of what I am suggesting. We are NOT planning or thinking of building a solution which will work with ANY gss library, since for obvious reasons this would not be practical.

Effectively what I am suggesting is that we build a gss wrapper library which calls SAPSECULIB library when required and also makes calls to our own Kerberos SNC library when Kerberos auth is used.

We would only support SAPSECULIB and not other vendors products. We will fully support the product we ship if/when we code this functionality. Also, if customers find this functionality works well, and other vendors want to work with us, then the gss wrapper that we code can also support their libraries as well, but I doubt that will be required.

Regards,

Tim

[WolfgangJanzen]

O.k. - now I understand.

Regards, Wolfgang

PS: I assume you are referring to SAPCRYPTOLIB (since SAPSECULIB cannot serve as SNC library).

[tim_alsop]

Wolfgang,

Thanks for correcting me on the library name, yes, SAPCRYPTOLIB is the one I meant. This is the OEM'd Secude library (old version of their product). My understanding is that many customers who use SNC between systems use this library. If they then decide to purchase an SNC product for other needs (e.g. SAP GUI SSO) they use the other product instead - I doubt we will be able to cater for this situation unless both companies use our own library.

Thanks,

Tim

[tim_alsop]

Hello,

I don't have any need to discuss this anymore so I am marking the thread as answered and have awarded points. The customer who needs this functionality is satisfied with the options I have given them. My gut feeling is that they will use same SNC product on both ends, but it was good to explore other options so we were able to present some alternatives to them.

Thanks to everybody who helped.

Regards,

Tim