SSO to a hosted R/3 system

Question

Can we use SSO with logon tickets when the R/3 system is hosted by an external partner and the domain name is not the same as the domain name of the portal server? We're accessing the R/3 trough a VPN tunnel.
Will SSO work also when accessing the portal from the internet???

Answer 1

Hi,
1. in common domain ITS is a problem. Let's say you have portal.intranet.company.com and its.outsourced.company.com. In this case you can set in portal using relax-domain setting of UME, that cookie will be generated for *.company.com. Portal works, ITS works. But when you logoff, you are still logged in. The problem is, that ITS resent SSO ticket after accepting portal's one (no advice helped to get rid of this "feature", although with latest PL). If logoff deletes ITS's one (because HTTP is a stupid protocol, it happens), you cannot logoff really, browser sends ticket issued by portal and you are in again. There are also ugly backside effects with exceptions and so on.
2. If you create alias its.intranet.company.com (from point 1), you use in portal this alias and cookie is issued for *.intranet.company.com (default setting) , browser can see both server in the same domain. I made a simple test and that worked. So I do not know about potential backside effects.
Definitelly, in HTTP (stupid one) server does not know, who issued some cookie and for which domain, so R/3 will never know it in any case (of course, content contains SID of ticket issuer)
3. Well, you will need proxy will manipulation of headers and content of HTTP traffic. This means SSL from browser must terminate in proxy and optionally start again here and continue to portal - this. I think that there is a thread in these forums how to do it. You will need to study in detail SAP's document about Apache reverse proxy (probably you use apache on solaris). I'm afraid I could not find a link quickly, try search in SDN.
4. IMHO SAP logon tickets are suitable and secure enough for most of applications like internet shops, customer support... There are weaker solutions of other vendors deployed in Internet without problems. But surely in case of bank applications for VIP customers every wise consultant will recommend additional security.
The problem I met with is possible to eliminate with setting cookie only for reverse proxy. If you set cookie's domain restriction too wide (e.g. *.company.com), it will be delivered to any server in *.company.com. This is a well-know weakness of HTTP. There were simple cracks in the past, that somebody created non-authorized server thehacker.company.com (well, internet is large and ugly place sometimes) - if you have access to DNS of some internet provider and if your end user clicks OK in every dialog window (what most of users obviously does , you are in trouble, this unathorized server might receive the ticket. Probability is low, as hacker must have knowledge of logon ticket feature, your architecture and application, write access to DNS, create some fake page forwarding to hacker's server and so on. But why not? I expect that every serious hacker reads all relevant forums. Who can guarentee you that some of answers here (also this are not hacker's trojan horses? If you talk about security, if you use sources that are not 100% trusted, you should double check and analyse. And count the risk and possible loss of money.
Pavol