Retrieve MYSAPSSO2 cookie in ABAP

[Former Member]

Hello,

We want to retrieve the cookie MYSAPSSO2 in ABAP, but can't find how to do it.

The sequence of the process is like:

1.- The user logs in into SAP ERP 6.0 using webgui (ITS)

2.- The user runs a custom transaction that finally sends some info to a NON SAP application through an RFC connection and an integration engine (IBM Message Broker)

3.- In the info for the 3rd party application, the MYSAPSSO2 cookie should be also sent, because it's needed to identify the session who sended this information for later processing

4.- Later, and asynchronously, other integrations/information exchanges have to be done, but using this MYSAPSSO2 cookie as "sender identifier", to correlate these different communications

Any ideas on how to retrieve this SSO cookie with ABAP to be able to send it through the RFC connection?

Thanks in advance,

jmiturbe

[Former Member]

Hi Jmiturbe,

you can not access the MYSAPSSO2 cookie from within ABAP. However to enable RFC to send a ticket to the receiving side to do identity propagation you can simply click on current user instead of specifiying credentials. Please see the docs for more details.

regards,

Patrick

[Former Member]

Hello Patrick,

Thank you very much for your answer, but I have two different situations in wich the user is not valid for identity propagation:

1.- Shared/Generic users executing this integration. I can't control that the same user won't be used by different people

2.- Same user executing the integration from different desktops, for example, an operator that executes the integration from different SAP desktops

The effect would be the same: the destination application won't know which "sap session" corresponds to every integration execution.

This is why I need a unique "logon" identifier to send to the 3rd party system.

I thought about using the ABAP session id, obtained with the FM TH_GET_SESSION_ID, but found that for example when using ITS, every time a user executes the logon URL, the session id changes, even if the logon ticket is the same.

I need a session id that doesn't change unless all the browser windows are closed, the way it happens with MYSAPSSO2.

Any ideas? Does anybody know another id that could uniquely identify each logon-session?

Thanks in advance,

Joseba M. Iturbe

[Former Member]

Hi Soporte,

sorry, I'm a bit lost here. What is your intention. If it is only about identification of the user session, you can create your own token and send it to the backend. This even will allow you to create these identifiers at the granularity you need. The mysapsso2 cookie is NOT bound to a session and therefor does not match your description. The same cookie will be used for all logins from one pc to the backend within one browser instance. This implies, if you have two browser instances you will also get two MySAPSSO2 cookies even if the user is working on the same PC.

So the MYSAPSSO2 cookie is NEITHER specific to one PC NOR specific to a login session on a single backend. Please also note, that you can have more than one HTTP session per login.

I would guess that the identifier can be contructed from data you can retrieve via GET_USER_DETAILS. However this depends on the real use case, which I do still not understand.

Regards,

Patrick

[mvoros]

Hi,

not sure what exactly you want to do but there are some function modules that allow you to get SSO ticket for current user. I can't find one which I've seen before but FM CREATE_RFC_REENTRANCE_TICKET seems to be returning SSO ticket for current user.

If you want to send a SSO cookie as part of your data then I am not sure if it is a good idea. If an attacker can get to data then he will be able to logon as that user. I know that there is a expiry time for a cookie but still there will be a window when somebody can misuse these tickets. Why do you want to use SSO cookie for this?

Cheers

[Former Member]

Hi Martin,

the reentrance ticket is not the same as the logon ticket but the similiar to the assertionticket used by the RFC infrastructure. However as you already stated, you can only create this for the current user.

Usually it is used to enter into the same system again (i.e. a call back scenario).

[mvoros]

Hi Patrick,

I am 99% sure that it's possible. When you open a web dynpro app in SE80 and then click on test the system opens browser with WD app and you don't have to authenticate. What I remember is that this is implemented using SSO cookie. The system returns SSO cookie and it is passed to browser. As I said I don't remember FM and I am not in mood for debugging.

You are right that ABAP AS supports generating SSO cookie for current user only. There is unsupported way how to generate MYSAPSSO2 cookie for any user but I did not want to mention it. I don't think that it is a good idea to use them here. But I am not sure what needs to be achieved.

Cheers

[Former Member]

The reason why you don't have to login when testing from SE80 is because AS ABAP issues a logon ticket inside the IE control before starting the WDA and the logon ticket will be of course accepted since the system issuing it is the system checking it. The behaviour depends on login/*_sso2_ticket instance profile parameters and with newer releases whether AS ABAP HTTP security sessions are being used.

I tend to agree with Patrick since as far as I know the logon ticket gets parsed in a very low level part of the AS ABAP, maybe even by the kernel. I don't mind being proven wrong, though.

[mvoros]

No, it does not issue logon ticket inside IE control. I checked the code and it calls standard SICF service MYSSOCNTL. This service uses HTTP handler CL_HTTP_EXT_MYSSOCNTL. Here you can find the following code that returns SSO. It's same C routine that is used in CREATE_RFC_REENTRANCE_TICKET but SSO cookie is returned in different field.

*     Obtain logon ticket and set cookie MYSAPSSO2

      CALL 'Reentrance_Ticket' ID 'OPCODE'     FIELD 'P'

                               ID 'RETICKET'   FIELD ssoheader

                               ID 'SSO2TICKET' FIELD ticket. "#EC CI_CCALL

And yes you are right, logon ticket gets parsed by kernel but you can always parse it by yourself in HTTP handler.

Cheers

[Former Member]

But then you are on a double-stack system and in SE80 you already are on the inside?

--> SAPJSF is taking care of it for you from SE80 tests That affects WS for sure and WD is started via the message server so if you land on a new server with individual PSE it can happen that you cannot logon if they dont all trust each other.

If it does not work from SE80 on single stack systems for WD then it normally means that there is some ICM setting that is not correct.

If it theb still does not work for the user on single stack systems for WD then it means that there is some PSE setting that is not correct.

Cheers,

Julius

[Former Member]

Hi Martin,

there are unsupported features you can use for many things. However in this case, I do not see how this can help here. The question initially was about accessing the incoming ticket in the HTTP request not about how to create a new one for the app. For RFC connections, I do not even see, why this would be required, as the RFC hinmself has the ability built in.

As the ticket part of the incoming http request, for security reasons, is already consumed at a very low level in the ICF and therefor unavailable to the application, I doubt you will be able to access this ticket. But there are others more knowledgeable that may have more info about this.

The reentrence and assertion tickets were created to get some short lived information, which can be used by apps to let a user establish a new session to the same (re-entrance ticket) or some other system (assertion ticket) in mediated scenarios or in case of a protocol change. This will allow to specify for which systems such information can be used, as you ahve to establish trust first. If you could access the ticket of the user directly, other systems would not be able to see, that the communication was mediated or initiated via a different server.

Regards,

Patrick

[mvoros]

Hi,

as I said before I am not sure about what OP wants to achieve. But from description I understood that he wants to send MYSAPSSO2 cookie to 3rd party app. I don't think that it's a good idea but if my understanding is right then generating this cookie in ABAP code will help.

Regardless accessing MYSAPSSO2. It's consumed by ICM but it should still be available to HTTP handler in SICF. Hence it should not be a problem to access it (I haven't tested this).

Cheers

[Former Member]

Hi Martin,

please read this response from jmiturbe. There it is stated:

Soporte Desarrollo wrote:
I need a session id that doesn't change unless all the browser windows are closed, the way it happens with MYSAPSSO2.

If you create the ticket in the ABAP system, you will get a new one for each request unless you store it somewhere in the system (which hopefully noone will do ).

Regards,

Patrick

[Former Member]

To answer your original question, you can also call the function and wait for the RECEIVING results and keep the control in ABAP? Close the connection after a limit is reached and issue an error message and refresh button to the user in the UI.

You can still do secure calls that way if you only receive certain results.

Cheers,

Julius

[Former Member]

Hello Everybody,

And thanks for the ansewers!

I'll try to explain the need a bit better, because it seems that nobody understood why I needed that kind of behavior.

We have an RFC integration with a third party application that has to process every request from SAP and create an object. Once SAP receives the answer that the object was correctly created, we will launch a browser with an URL to the 3rd party application to access that object with the application web functionallity.

The problem is that the 3rd party application has to identify the item that was created through the integration, in an scenario in which sap users could be shared, in which this user could have created additional items directly from the 3rd party application and not from SAP, ...

We can receive a cookie from the third party application, but as we don't know how to "inject" a cookie when opening a URL in SAP, we thought that we could do the other way, send SAP logon ticket to the 3rd party application on the RCF call and after opening the URL, when the 3rd party application reads the SAP logon ticket, it will redirect the user to the corresponding item.

I think we finally found a FM to retrieve the ITS context that it seems to include MYSAPSSO2 information.

Anyway I want to know if you'll do it other way or why some of you don't consider a good idea to send SAP cookies to this 3rd party application.

Thanks in advance,

jmiturbe

[Former Member]

I would rather have the 3rd party system generate the cookie and then open the URL from SAP including that cookie. See method SET_COOKIE of IF_HTTP_ENTITY.

[mvoros]

Hi,

I agree with Samuli. Forget about all craziness related to MYSAPSSO2. Get a cookie from 3rd party system. If you want to set a cookie for client then you can use same trick as service MYSSOCNTL is using. You can write your own HTTP handler which will accept two URL parameters: 3rd party cookie content plus URL for redirection. So you will send a user to URL  <SAP_HOSTNAME>/redirector?cookie=<content>&url=<URL>. This service will set a cookie passed via URL parameter and redirect user to 3rd party app. The only complication is that you have to be careful about domains.If you SAP system and 3rd part system have same domain then just a cookie for this domain, not just for a hostname of SAP system. Also do not forget to encode URL parameters with base64 to avoid issues with binary data. As I said above service MYSSOCNTL is doing almost same thing so you can have a look at its HTTP handler CL_HTTP_EXT_MYSSOCNTL. Here you can see how to read URL parameters, how to set cookies and how to redirect client to different URL.

Cheers

[Former Member]

I do agree to Samuli and MArtin as well. The reason mostly is, the SAPSSO2 cookie being treated as sort of a passpoart for more than one system. If the 3rd party system has such a ticket like the SAP reentrence ticket (which you would use in the inverse case of the 3rd party talking to the SAP system and then redirecting the user to SAP) the scope of the ticket is smaller (only the host) and instead of usually 8h the ticket is valid for minutes only.

Ragards, Patrick

[adimyati]

I have a similar situation: I need to add the mysapsso2 cookie into the URL as a ticket parameter rather than as part client browser (because of the 3rd party target limitation).

I read from above comment, there is an FM to retrieve the ITS/ICM context. Could anyone share which one of them?

Thank you