SAML Response Destination gets "URL encoded" on IDP 2.x

[Cantor, Scott]

> They use an base64 encoded token in their AssertionConsumerServiceURL
> which our 2.x some how half URL-encodes (where did the = go?)

That's a broken URL. The original query string parameter isn't safely encoded, so the equals gets chopped somewhere. I don't really know why the IdP would be altering it at all, but when it comes to unsafe URLs, all bets are off.

> I tried to read in saml-bindings-2.0-os.pdf to see if this was OK or not
> but I couldn't find anything.

It has nothing to do with SAML, that's just a bug in a web app. You can't pass unsafe values in a query string without encoding them.

> 3.x doesn't URL-encode it at all. I know 3.x is the way forward but
> we're not ready to switch for at least a month so we'd like to get it
> working on 2.x.

Neither one should be encoding it, but whatever they are doing, 2.x certainly isn't getting a patch now if that's what you're suggesting.

-- Scott