SAML Response Destination gets "URL encoded" on IDP 2.x
cantor.2 at osu.edu
Wed Apr 20 09:48:54 EDT 2016
> 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.
More information about the users