Problem with SOAP call to 2.4.4 IdP / port 8443 / F5 load balancer

[Cantor, Scott]

On 11/11/15, 10:57 PM, "users on behalf of Benji Wakely" <users-bounces at shibboleth.net on behalf of B.Wakely at latrobe.edu.au> wrote:



>Problem:
>	- SP making a call to a previously-single-instance IdP (apache-->tomcat) fails when IdP is placed behind a load balancer. (f5-->apache-->tomcat)
>		# There were actually two problems:
>		- Disparate SP certs for back-and-front-end calls to IdP

No. There is only one certificate at the SP. If you're not seeing it, then you are *not* doing TLS end to end and so you cannot use TLS to secure the back channel, you'd have to use message signing. Whatever you think you did to fix this, you didn't. You broke it entirely by essentially authorizing the load balancer to speak on behalf of every SP. Don't do that.

>		- back-end calls sometimes would route to Node A on load balancer where Node B had the Session created for the user

That's not a change due to use of one load balancer vs. another, that applies to any clustered deployment.

>	For the back-end/front-end / split sessions:
>	- Not possible to Simply load balance this and keep Attribute Query functionality.

As Brent said, that's simply not true.

>Unresolved / never got to the bottom of:
>	- How or even conclusively If apache behaves differently when placed behind a load-balancer that Should be merely routing the traffic verbatim,

Because you're terminating TLS at the load balancer.

>Would have been nice to know / have learned:
>	- You can have more than certificate set in relying party metadata that will validate a SP.
>	   If this was a simple google fail, my apologies.

The SAML metadata spec is the authoritative document.

>Complicating issues / affecting diagnosis :
>
>	- You can't load balance a back-channel request where the front-channel request hits a different node.

Yes, you can, but you have to account for that.

-- Scott