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

[Benji Wakely]

> Scott Wrote:
> 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.

I'm certainly missing something about all this, then.
I wasn't "Not seeing the certificate", exactly...

When I had the debugging turned up, the back-channel request 
_definitely_ had:
	- a cert (displayed in my IdP log) that originated with the SP,
	- that cert definitely differed from the one in the FilesystemMetadataProvider / relying party conf
	- front-channel requests were working, which Implies they were matching the FilesystemMetadataProvider cert. (yes?)

(Since this problem started, the certs have been updated all around, so it's something of a moot point now.)

I agree that if I was doing a MITM decrypt/re-encrypt of the back-channel at the F5, it would either:
	- not authorise anything, as the IdP would fail to recognise any of the incoming requests as correctly certified, or
	- recognise everything as valid, regardless of origin, as I would have had to have broken the IdP to blindly accept 
	  anyone as valid.  

But in either case, I'd be seeing the F5's certificate reflected in the IdP log of the back-channel request, surely?

> Scott wrote:
> There is only one certificate at the SP.

Out of ignorance, I ask "Is that axiomatically true, or is it true by convention/best practice?"
...Is it technically possible for a SP to:
	- use a certificate for SAML encryption / the front-channel that differs from the cert it 
	   might present as a TLS client?


> >		- 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.

Definitely.  Not a shibboleth-specific issue.

> >	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.

That's correct - I'd gotten "Attribute Query" and "Artifact Resolution" muddled.

> >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.

...But then I wouldn't have been seeing an external SP back-channel cert in my IdP logs,
I would have been seeing a locally-hosted load-balancer certificate, surely?


> >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.

So it is.
I can see it at page 7 of:
https://www.oasis-open.org/committees/download.php/51890/SAML%20MD%20simplified%20overview.pdf
for my future reference.


> >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.

Agreed - this list has been helpful in illustrating potential solutions - thanks all.

--Benji