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

[Cantor, Scott]

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


>
>	- that cert definitely differed from the one in the FilesystemMetadataProvider / relying party conf

Ok. Then the metadata was wrong, but that has nothing to do with the load balancer being used or not. That's the point I'm trying to get across. Either it was broken to start with or something else is going on here that you haven't made clear to me yet.

>	- front-channel requests were working, which Implies they were matching the FilesystemMetadataProvider cert. (yes?)

If you mean that it was able to decrypt something you were sending it, and that you didn't turn off encryption for that RP in the IdP's config, then yes, the key in the metadata must have been one the SP had access to.

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

Ok, then you understand the point I was making there.

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

Yes. I assumed that's what you must have seen, if you needed to change metadata that was working for a back channel call originally. Using the load balancer isn't going to cause the back channel to suddenly get used, at least not normally.

And clustering can have fairly huge impacts on what works or doesn't, but we're just talking about the basic TLS negotiation and the IdP's acceptance of the key when it looks at the request, so that part at least is not at all impacted by clustering.

>> 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?"

Convention. I just meant that adding a load balancer doesn't change what certificate an SP presents when it makes a SOAP request. It doesn't know, obviously, what you've got listening on the port.

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

Yes.

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

Yes, I was going by the claim that it was working before. If only the front-channel was working, ok, but that doesn't explain why it suddenly started needing to make SOAP calls. That part shouldn't be affected by the load balancer.

Generally, if a Shibboleth SP starts making SOAP calls, that's usually because it stops getting any attributes and is defaulting to issuing a query for them. That can be prevented by simply not publishing metadata with an attribute query endpoint for the IdP. The only other case would be a change from POST to Artifact binding for the response to the SP, but that isn't a change that's just going to happen randomly.

-- Scott