Is it possible to relax domain level for MYSAPSSO2 cookie in ABAP AS ?

[tim_alsop]

Hi,

In Java AS we can use UME property ume.logon.security.relax_domain.level to configure the DNS domain which is valid for an SSO2 cookie. The default for this parameter is 1 so that the hostname is removed when the cookie is issued.

For example, if the portal is on host http://portal.dept.company.com we can set this UME property to 2 and this will make the SSO2 cookie used by browser so it is applicable to all DNS hosts in company.com domain, e.g. *.company.com. The default value of 1 would make the cookie applicable to dept.company.com which is not good for us.

Heres the problem:

We want to do same as above, but with ABAP AS, so when ABAP AS is creating an SSO2 cookie (login/create_sso2_ticket = 1 or 2) we want to specify the domain relax level, otherwise the ABAP AS is creating a cookie for DNS domain *.dept.company.com which we don't want.

I have tried to search SAP help and used google, but cannot find any info on such a configuration in ABAP AS - maybe I am missing it ?

Thanks,

Tim

[WolfgangJanzen]

Short answer: no, it's not possible.

[tim_alsop]

Wolfgang,

Thankyou. I feared this was the case

We will have to get an SSO2 cookie by authentiation to a Java stack first and then present this cookie to SAP ABAP.

Thanks,

Tim

[WolfgangJanzen]

Please keep in mind that the SAP Logon Ticket needs to be protected - you should make sure that it is not send to servers which are not intended to get hold of this credential.

Actually, it is adviced to setup a proper DNS (sub) domain which contains only those servers which belong to the same trust realm. (Notice: a server might have multiple hostnames, so it's possible to assign them to a DNS domain without changing their hostname - but just by adding another alias hostname).

Domain relaxation has the opposite effect: it increases the number of potential recipients.

Futhermore it might cause problems when trying to delete such cookies: if the cookie was set with "relaxed" domain attribute it can only be deleted by setting the cookie with the same (relaxed) domain attribute (and a proper "expires" respectively "max-age" attribute).

If servers reside in different (sub) domains and/or use different "domain relaxation" settings it can happen that multiple cookie with the same name but different domain attributes (and/or path attributes) are set - and subsequently send. Notice: if the cookies have the same name and same path attribute but different domain attribute they are send in an arbitrary, undefined order - according to the [standard|http://www.faqs.org/rfcs/rfc2965.html]:

If multiple cookies satisfy the criteria above, they are ordered in the Cookie header such that those with more specific Path attributes precede those with less specific. Ordering with respect to other attributes (e.g., Domain) is unspecified. (section 3.3.4)

Thus, I'm not a friend of the "domain relaxation feature". I consider it harmful.

Best regards, Wolfgang

Edited by: Wolfgang Janzen on Nov 23, 2009 9:30 PM

[tim_alsop]

Woflgang,

Sorry for delay with my response. Thankyou for providing additional info.

The SAP customer that I am helping with their SSO2 setup has a very complex setup and we discovered a number of inconsistencies with the SSO2 configuration and cookie domain configuration. They had logon issues because the browser was sending two MYSAPSSO2 cookies, one for company.com domain and one for department.company.com domain, and SAP portal is only checking one of these cookies and if it was created by an untrusted issuer, then the logon fails. If portal was checking the other MYSAPSSO2 cookie sent, it would accept this because it was created by itself. Anyway, after investigating this with HTTP traces, we found that making the cookie domain the same on all portals fixed the problem.

However, once the portals were fixed, we found that in many cases, they logon to portal and then access an ABAP backend system, which is also configured to create SSO2 tickets (e.g. cookies). The domain of the SSO2 cookie issued by ABAP systems was not company.com and this means that the browser then has more than one MYSAPSSO2 cookie to send to portal systems when they are accessed.

Anyway, from above you can see that there were some issues. We solved the issue by stopping the ABAP system from issuing a new SSO2 ticket during logon, and now all MYSAPSSO2 cookies are using same domain level. If it was possible to change domain relax level on ABAP system to be same as on portal systems (e.g. company.com instead of department.company.com) then this would have been a better fix.

Most companies use 3 level domains, e.g. host.company.com, but when 3 or more domain levels are used, the setup becomes more complex. Most importantly for this customer, all is working well now and the users can hop between different portal systems and access backend systems without needing to manage SSO2 trust between each of the portals and ABAP systems.

Thanks again,

Tim

[gregorw]

Dear ,

I've posted your suggestion as an Idea on SAP Idea Place:

Provide parameter ume.logon.security.relax_domain.level for NetWeaver ABAP

I hope can help us to get this feature implemented.

Best regards

Gregor

[WolfgangJanzen]

Well, my answer is still the same (for the same reasons stated above).

Meanwhile SAML 2.0 is available and an ideal solution for such cross-domain usage scenarios.

Best regards, Wolfgang