Co-existence problem with several SAP Portals and backend systems

[Former Member]

Co-existence problem with several SAP Portals and backend systems (JSESSIONID and MYSAPSSO2)

Hi,

We believe there is a design issue in SAP's implementation for the co-existance of several SAP Portals and that due to changed behaviour in IE8 this problem has grown in extent. It is now a more severe problem for our users.

The root cause of the problem is caused by how SAP Java AS handles authentication through JSESSIONID and MYSAPSSO2 cookies. Especially that SAP Java AS doesn't process the JAAS login stack if it receives a valid JSESSIONID.

A simplified model of our problem scenario is as follows:

- SAP Portal EP1 is connected to ABAP backend system BE1 through trust (STRUSTSSO2).

EP1 has url https://ep1.company.com and BE1 has url https://be1.company.com

- SAP Portal EP3 is connected to ABAP backend system BE3 through trust (STRUSTSSO2).

EP3 has url https://ep3.company.com and BE3 has url https://be3.company.com

There is no trust between the SAP Portal (none is intended) and back-end systems should not trust all portal systems due to security considerations.

From a user perspective EP1 and EP3 represent different applications that can and will be accessed in same browser session.

Whilst SSO to backend works fine when the user accesses EP1 or EP3 in an individual isolated IE session, conflicts occur when they are accessed in the same session. This conflict results in an authentication failure when accessing content from the respective back-end system. This problem is more severe with IE8 since each new tab or window will by default be opened in the same session.

(but even if changed behavior was modified in IE8 through registry change, the problem is still severe)

The following is a script demonstrating how: conflict which occurs

1.

User: Logs on to https://ep1.company.com/irj/portal

Server: EP1 server sends HTTP response to the user browser with two important cookies

MYSAPSSO2 with domain:.company.com

JSESSIONID with "default" domain ie. ep1.company.com

(domain has been changed by implementing note 791765 in order to minimize conflict. The problem is the same if this setting is not done)

2.

User: Accesses iView in EP1 that requires a connection to ABAP backend system BE1 (either through JCO or web) and this correctly sends the MYSAPSSO2 cookie from EP1

Server: BE1 server verifies the validity of the MYSAPSSO2 cookie from EP1 and correctly shows content

3.

User: Navigates to the different EP3 portal https://ep3.company.com in the same browser session

The browser will include the MYSAPSSO2 cookie from EP1 in this request (but not JSESSIONID)

Server: EP3 portal tries to validate the MYSAPSSO2 cookie from EP1, but since there is no trust between EP3 and EP1 this fails as expected. Server will then proceed down the JAAS login stack and perform the authentication against EP3 UME. Once this authentication is done, the EP3 server sends a HTTP response to the user browser with two important cookies

MYSAPSSO2 with domain:.company.com (thereby overwriting the MYSAPSSO2 from EP1)

JSESSIONID with "default" domain ie. ep3.company.com

4.

User: Accesses iView in EP3 that requires a connection to ABAP backend system BE3 (either through JCO or web) and this correctly sends the MYSAPSSO2 cookie from EP3

Server: BE3 server verifies the validity of the MYSAPSSO2 cookie from EP3 and correctly shows content

5.

User: Navigates back to EP1 portal https://ep1.company.com/irj/portal (for example through the home page)

The browser will now send the following cookie in the request

MYSAPSSO2 from EP3

JSESSIONID from EP1

Server: The EP1 server has now received a valid JSESSIONID, but an untrusted MYSAPSSO2. Surprisingly, the server verifies that the JSESSIONID is a valid EP1 session and accepts the logon. Thereby, it ignores the fact the MYSAPSSO2 is from an untrusted system (EP3). It sends no new cookies back to the user

6.

User: Accesses iView in EP1 that requires a connection to ABAP backend system BE1 (either through JCO or web).

Since step 5. didn't perform the authentication as expected, the browser now sends the MYSAPSSO2 cookie which came from EP3

Server: BE1 server fails to verify the validity of the MYSAPSSO2 cookie since it came from EP3 which is not a trusted system (and will not be due to security concerns)

The root cause as seen in step 5. is caused by the fact that if the SAP Java AS receives a valid JSESSIONID, it doesn't process the JAAS login stack which would reject the MYSAPSSO2 cookie. I believe the correct behaviour should be to validate both the JSESSIONID and process the JAAS login stack for each request requiring authentication.

Any ideas on workarounds?

[gregorw]

Hi Dagfinn,

I'm facing the same problem when I want to compare our development portal and integration or production. I have to open it in two separate IE-instances to get rid of the problem with the SAP Logon Ticket. The only quick & dirty solution that I can think of is to have ep1.company.com and ep2.company-online.com to have two separate domains which will cause the MYSAPSSO2 cookie not to be presented to the different portal and also back-end system.

Best regards

Gregor

[Former Member]

Yes,

Agree that the modification of domain name would work, but this is not an option as it of course violates company standard.

I thought of one way to really "hack it"¨; namely by including a custom build portal component which is added to the portal framework page which:

1. Parses the MYSAPSSO2 cookie through existing SAP libraries in order to findthe issuing SID

2. Deletes this cookie if the SID is not the current system (and possible also deletes the JSESSIONID) in order to trigger a relogin

(which is done through SPNEGO kerberos authentication)

But it is not a way I am willing to go at the moment.

Regards

[Former Member]

I am not sure why you consider this sort of "forward proxy" approach to be a "hack" if you document it well?

An SSO2 ticket is digitally signed (against modifications) but not encrypted and there are standard libraries to extract "verification" data from them for re-use with non-SAP webservers, so a forward proxy is much the same in my books if a SAP system is behind it.

I would not neglect the option of looking into SAML as a longer term solution and more standards based "workaround" in stead of SSO2 proprietary tricks and added complexity in the architecture.

A question: Are these BSP's or ESR webservices in the portal?

Cheers,

Julius

[Former Member]

Hi Julius,

I've done my fair share of well-documented "hacks", but I believe I will avoid it this time.

If the "hack" had been added to the authentication stack (for example a new JAAS login module), I would have gone for it. But I don't want to modify the frameworkpage which I consider part of content. Also we have 6-7 different frameworkpages which need to be maintained.

I've long been preaching to this customer that SAML is the future of authentication, but have been unsure at just how ready it is for large landscapes at the moment. Perhaps this can be one more reason why we should start down this path.

In the portal there are most kinds of different web content, from webdynpro for java and abap, bsps, portal components with JCO connections, BW reports, BSPs and adobe interactive forms (integrated with webdynpro for abap). There are approximately 40 000 users, so it is not really an option to tell everyone to open a new session in IE8.

Regards

Dagfinn

[Former Member]

I do not have experience (yet) with multiple backend systems, but for multiple portals and complex applications it works for + 1 million SU01 users on one backend system - so it should work for 40k as well

But I can understand that you do not want to be a beta-tester so perhaps consider opening a message with SAP before you make the investment.

I would also be curious to know, but don't see any problems (at least not for webservices) because you can authenticate at message level and the backend systems trust the SAML identity provider.

BSP's might be a different topic though.

Cheers,

Julius

[Former Member]

btw: In your SAML specific thread which was moved to the IdM forum you mentioned ASJava only systems, but here you have BSP's in the list?

Perhaps they are the problem?

There is an ancient thread about this in the security forum. I will try to track it down for you.

Cheers,

Julius

[former_member182046]

Hi guys,

Thank you very much for this excellent track and especially Dagfinn for his lucid representation of the problem. I have learned a lot from reading it and also from Gregor's and Julius' replies.

By the way: Wouldn't this make a great blog in the style of Jim Spath's troubleshooting detective stories?

Again, thanks a lot,

Thorsten

[Former Member]

Hi Julius,

The Authentication as a service/IdM/SAML thread is a different case and unrelated to this problem

You are correct that on a message level (such as webservice) this should generally not be problem, since the Java AS runtime passes the correct credentials from the internal security session. However, it seems to be a problem when using JCO connections as it reads from the cookie instead of the internal security session (not confirmed this 100%)

However, for all application which have the user interface rendered from an ABAP system will only receive the SAP Logon Ticket Cookie and will therefore make the authentication on a logon ticket from the wrong system.

Regards

Dagfinn

[Former Member]

Thorsten: I like my detective stories to have a happy ending (even though someone might get killed along the way)

But perhaps a blog will come eventually.

Cheers

[Former Member]

Hi,

Is it not possible to create an additional logon stack for MYSAPSSO2 authentication and make the flag requisite/sufficient login module stack for ticket even when JAAS login module stack is succeeded?

or Is this your question??I am thinking that it may be possible to create a new logon stack for MYSAPSSO2 cookie verification.

Regards,

Isvarya

[Former Member]

Hi,

We are facing the same issue.

I tried forward proxy approach to read all cookies and the delete once not related to current portal.

However, I can see only one MYSAPSSO2 cookie and that too with domain and path as null.

Any thoughts?

Were you able to find any workaround for this problem?

Regards,

Apurva

[Former Member]

Dear all,

as I understand the original problem was:

- 2 SAP Portals issuing MYSAPSSO2-Cookies

Is there a solution to that?

Maybe change the name of the Cookie?

Maybe reiussing by processing the JAAS login stack?

Thank you,

best regards, David

[Former Member]

Hi,

As far as I know there is not a good solution to resolve this problem.

It is not possible to change the name of the MYSAPSSO2 cookie.

Also, as far as I can see, the JAAS login stack is not processed if you have a valid MYSAPSSO2 cookie (which IMHO is provides worse security).

My guiding principle for SSO is that each middleware/application server should provide its own SSO. In this case this means that you should avoid trust relations between a portal system and ABAP backend system. The major security risk is the hijacking and injection of other people's MYSAPSSO2 cookie.

The ABAP application server today support SSO through X.509 certificates and SAML. For most landscapes I prefer SAML. ABAP application server of the future may support other authentication methods (SPNEGO kerberos would be the obvious one, though it is probably complex to implement).

Regards

Dagfinn

[Former Member]

Hi,

We are facing similar issue.

How did you resolve it?

Regards,

Apurva

[Former Member]

hi

     im also facing that problem .....kindly share the doc for how to resolve this problem.

Regarding,

Antony

[Former Member]

iam also having same problem.if there is way to delete mysapsso2 cookie????let me know