SSO with logon tickets: problem with domain name restrictions

[Former Member]

Hi Gurus

Our portal host name is > stpnetprd.company.local and

Portal accessing URL is > https://mystp.net:50101/irj/poral

and R3 host name is stpeccprd.company.local

because of these domain name constraint with portal and R3, we are not using SSO with logontickets.

And Our Portal's UME is R/3.

"As of now We are using UIDPW method to logon to ESS,

This requires to update the password (through personalization) everytime whenever

the ESS User changes his password .

For ESS We want to implement SSO with logon tickets,

My questions are :

Is it possible with different domains like above.

Is it possible with parameter ume.login.mdc.hosts (cross domain SSO)

System detials EP.7.0 SP17 MSSQL2005 Windows 2003 server and ECC 6.0 at SP17

Thanks in Advance

Regards

Balaji

Edited by: BALAJI NAMPALLY on May 7, 2010 2:31 PM

[Former Member]

Hi Balaji,

yes it is possible. Since you are using a common domain which is company.local, you can *relax" the domain from xxxx.company.local to company.local.

Domain relaxing is described here: [Network and Communication Security|http://help.sap.com/saphelp_nwce72/helpdata/en/b9/c892f1ffc34156883ddd24aec01253/content.htm]

For using JCO/web services the domain restriction does not apply anyway, you just have to setup trust between the ticket issuing system and the consuming system.

Regards,

Martin

[Former Member]

Thank you Markus

I doubt we cannot use domain relaxation with our scanario

While my portal accessing URL is http://mystp.net:50100/irj/portal/

R3 server host name is eccstpprd.company.local

Thanks in advance

Regards

BALAJI

[Former Member]

Hi Balaji,

ok, I misunderstood the question then. You are right, domain relaxing will not help you.

But this ain't not your problem. If you are only using the business package ESS/MSS, the content is rendered in Web Dynpro Java on the portal server or a different AS Java where the content is deployed. The R3/HCM system is maintained in the properties of ESS/MSS as a JCO destination. The JCO destination does not follow any domain restrictions since the calls are not initiated by the user's browser, but by the application server itself. The logon ticket is then handed over as a JCO parameter.

You have to setup trust between Application Server Java and HCM system so that HCM can recognize the user from the logon ticket.

The domain restriction would apply, if content is rendered directly on the HCM system. As far as I know that is not the case with ESS/MSS.

Hope that helps you!

Regards,

Martin

[cris_hansen]

Namaste Balaji,

Please note that your Portal uses the following FQDN: mystp.net Browsers will sent the MYSAPSSO2 cookie to all servers in the domain ".net". Your backend system has a different domain: .company.local (FQDN stpeccprd.company.local). That is why the SSO does not work: both systems should have the same domain name.

You will need to change the domain name of your backend system to have the SSO working, as the cookies can only be set in this case into the browser. Please have a look at SAP note 654982 for more information.

I hope this information helps.

All the best,

Cristiano

[Former Member]

Hi Christiano,

you are right for direct browser access, but since ESS/MSS uses machine to machine (JCO) communication between portal server and HR system, this domain restriction does not apply. The same is true for web services.

Only if the end user accesses content directly on the backend system, SSO via logon ticket will not work.

Regards,

Martin

[Former Member]

Martin,

ESS/MSS aren't all about Java webdynpro, and it's being replaced as ABAP webdynpro.

you also cannot stop developer create their BSP/webdynpro appliactions on ABAP backend.

@Balaji, a workaround solution would be introducing url redirection, e.g. put a webdispatcher in front of portal, redirect https://mystp.net:50101/irj/portal to https://stpnetprd.company.local/irj/portal or you put a webdispatcher in front of ECC, which listen to mystp.net domain, but you need pay attention to the ABAP web application which generate URL using table HTTPURLLOC, check notes 871004, 1325985 etc.

or forget about MYSAPSSO2 cookie, but using client certificate.

[Former Member]

Thank you Denny Liao, Martin Kraus, and Cristiano Hansen

But why is this parameter:

ume.login.mdc.hosts (cross domain SSO).

As my understand, what ever the hostnames we define for the above parameter value. The Portal system will create a logonticket for each.

for eg: if i put ume.login.mdc.hosts= abc.com and xyz.net.

for every time when i logon to the system , The system issues two tickets.

Please correct me if i wrong!

Thanks in advance

Balaji.

[cris_hansen]

Hi Balaji,

In this case it seems that you are correct. Please have a look at the documentation in the SAP Library entitled "Configuring Logon Tickets for Multiple Domains":

http://help.sap.com/saphelp_nw04s/helpdata/en/e0/fa984050a13354e10000000a1550b0/frameset.htm

The article discussed a UME property called "ume.login.mdc.hosts". You can insert <FQDN>:<PORT>, bounce

the Portal and then the backend call should work without the secondary login prompt.

I hope this helps.

Have a nice weekend,

Cristiano

[WolfgangJanzen]

 Our portal host  name is  stpnetprd.company.local           and 
 Portal accessing URL is   https://mystp.net:50101/irj/poral
 and  R3 host name is       stpeccprd.company.local

Why aren't you using the URL https://stpnetprd.company.local/irj/portal to access your portal?

Notice: ".net" is not a valid domain to be used for cookie domain restrictions (browsers might discard the entire cookie).

The best solution is: place both servers (EP and ERP) in one common (sub-)domain; this domain assignment is not related to physical network neighborhood. As you might know you can assign multiple hostnames (respecitively aliases) to one physical machine. Grouping only the relevant servers in one dedicated domain has the great advantage of controlling the scope / range of cookies, javascript coding, etc. (to prevent cross-site scripting attacks ). Since you have posted your question in this forum you seem to be interested in a secure solution (hopefully).