Forum Discussion
kevtheref_50650
Nimbostratus
NimbostratusF5 SAP Portal Integrated ITS and SSO
Hi,
We are implementing F5 into our SAP environment which includes Portal 7.0 and ESS/MSS into ECC 6.0. We have rather a complex network. When people access ESS via the internet they come into our ESS F5 for arguments sake I will call it https://ess.ourplace.com, SSL termination takes place here and the internal traffic is http.
This works fine for all except the integrated ITS transactions as they build a URL out in internet land to try and access the ECC backend. We don't allow direct access to ECC from the internet so we generate a URL back to https://ess.ourplace.com/bc/etc then at the ESS F5 we rewrite the header and pass the traffic through to our internal ECC F5 server which in turn passes it through to ECC. This portects our network and works fine except for the fact it prompts for a userid and password rather than using SSO for these transactions.
I'm picking I need to put the portal server certificate onto the ESS F5 so that in can recognise the request and pass it through via SSO. SSO is working for all but the integrated ITS transactions.
Please be aware I'm not F5 literate and don't have access to the F5 config, but I need tio sort t his issue quickly if possible.
Cheers Kevin (kevtheref)
- Hi Kevin.
You definitely have a complex setup, but it also shows off the power of the BIG-IP to enable solutions to these complex problems. I think I understand your setup, but the problem may be in a few different places, it's hard to say without more information.
On first glance, it feels to me that when you rewrite the traffic to /bc/etc, that perhaps the cookie is being lost and/or not forwarded. I'm assuming here that SSO works between ESS and ITS and that the cookie being used is valid for both "domains". For example, the cookie being set should be broad enough so that it's being sent and interpreted by the server correctly. So, that could be problem 1 or problem 2. Specifically, that 1, it's not being sent in the context of /bc/etc or problem 2, that the rewrite is not sending it along.
I'm making another big assumption here that you are using an SSO mechanism that relies on cookies. Something like CA Siteminder, or something along that vein.
You mention the SSL certification as well. If you are terminating SSL on the F5, then you must already have some certificate there, either from the BIG-IP's self-signed "store" or perhaps you have already imported the ESS server's SSL cert. In either case, if you are not getting browser errors when you browse to https://ess.ourplace.com then your cert is probably okay. However, I do wonder if the ITS server is expecting the traffic in an encrypted connection. In other words, perhaps because the F5 is doing SSL off-load, perhaps the ITS server is not accepting the credentials. Most SSO systems can have pretty strict settings. Again, all speculation.
In speaking with my colleagues, there is also a theory that the cookie is encrypted or being encrypted, and throwing off the SSO system. Cookie encryption settings are in the HTTP profile section of the Virtual Server configuration.
In any case, to troubleshoot this issue, I would begin by taking a trace (Wireshark, tcpdump, etc) of the traffic going to the ITS server. This should be easy because the connection is not encrypted. You can do this on the BIG-IP (using TCPDUMP) or on the server, using wireshark or other tools. Then, check to see if the SSO cookie is making it to the server. If it's not, take a look at your rewrite, and perhaps look at an F5 BIG-IP iRule that will send the cookie as well.
If the cookie is making it to the server, then the issue may be that your SSO vendor is rejecting it, and looking at your logs on the server (as well as the SSO system) might prove useful in finding out why. You can also try to compare the cookie being sent with one that doesn't go through the F5 and that you know works, to try to narrow down the differences.
Hope this helps and please post back your findings!
-Nojan 
fsolis_104880Buenos Días, en este momento yo también tengo problemas de Compatibilidad del balanceador de cargas con Single Sign On: actualmente los tres módulos principales de SAP que son SAP ERP, CRM y PORTAL tienen aplicada una funcionalidad de Single Sign On la cual busca simplicidad a la hora de autenticar usuarios en diferentes sistemas con una sola instancia de identificación. La preocupación actual es que después de realizar varias pruebas el balanceador de cargas no está permitiendo que se ejecute esta funcionalidad algo que perjudicaría mucho la forma en que actualmente está trabajando el aplicativo de SAP CRM según las políticas establecidas por el banco.
Cuando accedemos a PORTAL INTERNO a través del balanceador sin haber obtenido el token de SAP nos carga la primera pantalla en la que solicita el loggeo del usuario:
En cambio cuando ya ha recibido el token no requerimos este tipo de loggeo: