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: 

GETSSO2 connection param is not supported when using NW RFC SDK?

srinivas_cheruku
Explorer
0 Kudos

Hi All,

I was using Classic RFC SDK and that used to get the SAP Logon Ticket using GETSSO2=1 when calling RfcOpenEx() and later calling RfcGetTicket(). This is described http://scn.sap.com/thread/125144

But now I am trying to port the code to use NW RFC SDK and I found the following in the sapnwrfc.ini shipped with the NW RFC SDK.

# GETSSO2   : Set this to 1, if the backend should generate an SSO2 ticket for your user.

                              If RfcOpenConnection() succeeds, you can retrieve the ticket with

                              RfcGetPartnerSSOTicket() and use it for further logons to systems supporting

                              the same user base.

                    !!! Note: No longer supported! SAP systems shall no longer issue tickets during user logon!!!

Can anyone let me know what the Note: means? Do this mean that GETSSO2 will not supported any more?

But the NW RFC SDK Guide found at https://websmp101.sap-ag.de/~sapidb/011000358700000869672007E/NW_RFC_SDK_Guide.pdf specifies GETSSO2 but doesn't have any "Note:" as found in sapnwrfc.ini file.

I need to create the SAP Logon Ticket and so do I need to worry about the "Note:" as found in sapnwrfc.ini?

Many Thanks,

Srini

18 REPLIES 18

Former Member
0 Kudos

Can you first describe your requirement? Why do you need the logon ticket? For repeated logons without using credentials? I think SAP has disabled the possibility to request the backend to generate a logon ticket programmatically because it has to be controlled by landscape configuration. If you want to enable SSO via RFC, you could look into using SNC together with the SAP Cryptographic Library and X.509 certificates. Other commercially available options include NWSSO and 3rd party products.

0 Kudos

Thank you for your help so far. I am using an SNC connection to authenticate to AS ABAP and then need an SSO2 ticket to be created for the user, so that I can then use this SSO2 ticket for a HTTP session.

My code has been working well for many years using Classic RFC SDK, and I am updating it to use NW RFC SDK, and found the reference to the GETSSO2=1 that I mentioned in my first post. I need to know why the Note says that GETSSO2=1 is no longer supported. If it is no longer supported, how are you supposed to get an SSO2 ticket after authenticating using SNC ?

Thanks,

Srini

0 Kudos

Enable SSO for HTTP(S) independent of the RFC. If the RFC is run with a system user, you will not be able to access the backend with the same system user since SSO is not possible with system users. I would have to understand your landscape, current implementation and requirement in more detail in order to be able to suggest a solution.

0 Kudos

Semuli,

Srini is not online at the moment, and I am also familiar with this requirement so I will respond for him.

The code being discussed in this thread is working very well at the moment, and it is using Classic SAP RFC SDK, not SAP NW RFC SDK. The RFC is run as a normal user, not as a system user. So, the SSO2 ticket is being created because of GETSSO2=1 option in the RFC connections string, and the SSO2 ticket is then used for HTTP communications.

What Srini is asking for is to understand why the SAP NW RFC SDK documentation is saying that GETSSO2= param is not supported, when it clearly is supported in Classic SDK. If it is not supported in SAP NW RFC SDK then what should be used instead of this param ?

Thanks,

Tim

0 Kudos

The SAP developers involved in the change are probably the only ones capable of answering that question. Unless one or more of them are active here on SCN, I suggest you create a customer message to SAP support. The only contribution I have to this discussion thread is trying to understand why the change was made and suggest alternative options. My guess is that the change was made in order to avoid customers reusing accounts meaning there should always be a 1:1 mapping between the user and the user account in the backend. Without the restriction it is possible to always logon to the backend with userA and open a browser to access the backend with the credentials of userA even if userB is the one who initiated the connection. The other reason might be related to security, more specifically to HTTP security sessions.

0 Kudos

Maybe can comment?

0 Kudos

There is a function module which can be run which generates an SSO2 ticket for the authenticated user, so this can be used instead of GETSSO2=1 so we are not actually looking for an alternative - the alternative is and always has been widely used. What we are trying to understand is why the documentation included with the NW RFC SDK says this param is not supported. Actually, we later checked the NW RFC SDK header files and found that this param is included and supported, so maybe it is a mistake in the doc supplied with the new NW SDK ?

We were thinking that somebody on SCN might have found the same, and seen this thread. It takes too long to get response if we open a message, so we thought this might be the right place to ask a quick question and get a quick answer from somebody who has used GETSSO2=1 and knows about the changes in the new NW RFC SDK versions compared to the classic SDK.

0 Kudos

In the latest NW RFC SDK in the demo folder you have a file called sso2sample.c containing the following:

/* Currently the only way to obtain an SSO2 (or assertion) ticket is, if the

SAP backend gives you one... Therefore this program works as follows:

1. The program starts an RFC server on the given RFC destination. Make sure that in

    SM59 in the "Security/Logon" tab you activate the check box "Send SAP Logon Ticket".

2. The program starts to listen for a call from the backend. Go to SE37, enter the

    function module STFC_CONNECTION, enter the correct RFC destination and execute the

    function module.

3. In the implementing server function for STFC_CONNECTION, the program reads the SSO2

    or assertion ticket from the backend system and uses it to log into that system.

If everything works correctly, you get a success message.

This program handles only one single function call and then exits.*/

0 Kudos

Yes, but an SAP system must issue the SSO2 ticket, so you must first get the user's own context onto the inside or make a trusted call if the user themself does not authenticate. In that case you anyway need an SAP system to trust or a real SSO.

SSO2 is actually just a trust chain to everything which SAP supports. Not a real SSO from an identity provider. So for SSO2 tickets you must always find a way to get into the inside first - the SAP portal is the most popular candidate.

Looking at the requirements of this thread, I think that SAML is a better option, particularly if you have non-SAP systems involved.

Finally: is strong authentication really required against the non-SAP system? If you hardwire that and take care of security in ABAP then you should also be ok? Or is access critical there that it cannot be a system service?

Cheers,

Julius

0 Kudos

This sample is for a different use case - in our case, there is no RFC destination configured in sm59. The ABAP system is the target and is issuing an SSO2 ticket when we connect using RFC SDK. It works with classic SDK and we are migrating to SAP NW SDK but wondered why the SAP NW RFC SDK file called sapnwrfc.ini has a note in it saying that GETSSO2=1 is not supported. If anybody knows why, we would be happy to hear.

0 Kudos

Julius,

Yes, you are correct - a SAP system must issue the SSO2 ticket. This is what happens when using GETSSO2=1 option. We need to know why the sapnwrfc.ini file says that this option is not supported.

We are using SNC to authenticate to AS ABAP and the user that is authenticated using SNC is the one which the SSO2 ticket is issued for - this is supported and widely used, but we are confused by the reference in sapnwrfc.ini where it says that GETSSO2=1 is not supported anymore.

Thanks,
Tim

0 Kudos

Hi Tim,

Possibly you need to distinguish between something which was found to be available and something which is supported (and will remain stable)?

However there is a known limitation to SSO2 tickets which can be frustrating if you don't know it -> some folks switch the user types to SERVICE so that they can avoid password rules and even license costs. but this also has the implication that authentication as a system service does not issue a tivket for the browser of the end user (even if that is the real person...).

There are even a few business applications which respect the user type.

I would check that as the first point of call.

Cheers,

Julius

0 Kudos

Julius,

The reason for opening this thread is that we found in the sapnwrfc.ini for older versions of the SDK that GETSSO2=1 is mentioned without any notes, then in version 7.20 of the SDK the same file has a note saying that the option is not supported. We are therefore trying to understand what this means. We feel that there must be a large number of SAP customers who have code that initiates and RFC connection to an AS ABAP system, and uses GETSSO2=1. I remember many SCN threads in past where questions were asked and in one, Wolfgang explained that the best solution was to use GETSSO2=1 to get the SSO2 ticket issued. However, there is also a function module which can be executed which will do the same, so we were wondering if the function module was the preferred method of getting an SSO2 ticket issued when using the NW RFC SDK, whilst the GETSSO2=1 is the best method when using the classic RFC SDK. We thought that asking on SCN might be the best way to get this answered, even though it is not a huge issue to us either way, and we were curious to know the answer. Instead, the thread has gone off in different direction and nobody has been able to answer the simple question as to why the note was added to the .ini file. This mystery might be left unsolved 🙂

Also, the use case for this code involves dialog users, so no concerns over the user type.

Thanks,

Tim

0 Kudos

Actually, I doubt that many customers voluntarily use this - customers don't develop their own SNC SSO.

Using dark function modules with unspeakable names is more likely (check on the attributes tab in SE37 whether that is released?) but if remote enabled then high on the priority list to be furnished with a check of the call attributes (kernel function RFCControl) so that it can be wrapped for WS but not really called from the client.

I faintly suspect that with SAP's own SSO the prior tolerated backdoors on SSO2 workarounds are being closed or not developed further for compatibility.

One thing is for sure: no one on SCN added that nwrfc.ini or can be officially authoritative on it, so you should open a customer message with SAP via SMP and ask for clarification. That would be my suggestion.

Cheers,

Julius

0 Kudos

Julius,

We are not discussing/using any backdoors. Just because you are not familiar with this technique, there is no need to be critical of the method we are using and make assumptions. If you take the time to check in SCN you will find many threads where SAP customers are discussing using SAP RFC SDK to get SSO2 tickets, and this is what we are doing and have been doing for a long time, using the classic SDK. One such thread is http://scn.sap.com/thread/125144 (which Srini mentioned when he opened this thread).

Also, this thread has nothing to do with the fact we are a vendor who has developed our own SNC SSO product for selling to SAP customers. The GETSSO2=1 parameter is not specific to SNC, and can be used to get an SSO2 ticket given a valid user id and password for a user.

This discussion has been taken out of context and I have tried to get it back on track so that somebody who has used the NW RFC SDK could offer some feedback without getting confused about the actual question we asked. We don't plan to say any more, since it is not important enough to waste any more time discussing it. We were just curious to know what the comment in the ini file meant.

Thanks,

Tim

0 Kudos

Hi Tim,

Srinivas seemed to find my opinion and advice helpful, so not sure what you are now ranting about?

A comment in a file from SAP can surely only be answered by SAP Support?

I am quite familiar with the mechanism and format of the sso2 cookie, so no need to belittle my comments as if they are irrelevant just because they dont fit your agenda to gain SCN support for using a feature.

That a feature during logon can be used to increase the attack surphase of SAP systems is one thing. That vendors use them and therefore make it more difficult for customers and SAP to implement security improvements as compatible changes is much worse. (eg. preventing customers from changing COMMUNICATION users to type SYSTEM is very seldom now a days, but then a big pain)

I find it good that SAP is making it easier and guiding customer towards SNC and SSO and using SAML for supported use-cases.

SSO2 trust chains is dead.

Of course that is just my opinion, but Srinivas asked for comments here on SCN and was probably not expecting you to highjack the thread, Perhaps you should create your own? Or is this one of your customers?

Cheers,

Julius

guilherme_deoliveira
Participant
0 Kudos

Hello Srini,

I've contacted the developers of the NW RFC SDK library and here are their comment:

"...
1. The functinality of getting SSO2 ticket from an existing RFC
connection could be misused and has been considered as a security issue.
Therefore, we removed this "feature" from the SAP NWRFC.

2. The official way to get SSO ticket can be found at:

http://help.sap.com/saphelp_nw73ehp1/helpdata/en/4d/a5ddc832211dcde10000000a42189c/content.htm?frame...
..."

I hope this helps and clarifies.

Best Regards,

Guilherme de Oliveira.

guilherme_deoliveira
Participant
0 Kudos

Hello Srinivas,

A further update and clarification on this...

Neither the classic RFC SDK, nor the NW RFCSDK has ever been able to

issue any SSO2 ticket. Both RFC SDK can only use a given SSO2 ticket as

logon parameter when connecting to the target SAP system. While the old

RFCSDK has an option that allows the calling application to get back a

SSO2 ticket for the current logon user after successfully connected to

the backend system by using a logon method other than SSO2, this option

was removed from the NW RFCSDK because it has been considered as a

possible security issue.

In general, a SAP SSO2 ticket can only be issued by a SAP system itself

or by a system trusted by the target SAP backend system.

Therefore, there is no possibility to get the SSO2 ticket from SAP with

the new NW RFCSDK library. However, if you indeed need this

functionality, you can retrieve to the old Classic RFC SDK library. They

are also compatible with the kernel 7.20.

Best Regards,

Guilherme de Oliveira.