Cross-contamination from conflicting @relayState settings
Basics
Technical
Logistics
Basics
Technical
Logistics
Description
In cases where <Sessions>/@relayState and <SessionInitiator>/@relayState are not set to the same value you can end up with odd behavior. For example, if <Sessions>/@relayState is "ss:mem" and <SessionInitiator>/@relayState is set to "cookie" the target redirect that occurs at the end of the response processing results in URLs like "ss:mem:751e175df861712bbbd11b7b4674c839f78cf563" which obviously doesn't work so well.
Only reproducible case was artificial, I changed the relay state value while sitting at the DS so that it switched mid-stream. I patched around that case.
There are no possible conflicting settings that I can see because of how the setting is used, but with this fix, it won't try to doubly-encode a state token generated by one mechanism with a different mechanism.
Scott Cantor June 26, 2012 at 6:49 PM
Still having no luck reproducing. Also saw report to mailing list that passing a relay state of ss:mem:something in the IdP initiated case was having the same result, and I can't reproduce that either. ;-(
It's possible I fixed this somewhere, but eyeballing 2.4.3 code doesn't give me any hints that I did.
That user report has me puzzled, because if not for that, I'd guess that this case involved an inadvertent double encoding of state, like putting the previously generated relay state value into a cookie. Still investigating that possibility.
Fixed
Pinned fields
Click on the next to a field label to start pinning.
In cases where <Sessions>/@relayState and <SessionInitiator>/@relayState are not set to the same value you can end up with odd behavior. For example, if <Sessions>/@relayState is "ss:mem" and <SessionInitiator>/@relayState is set to "cookie" the target redirect that occurs at the end of the response processing results in URLs like "ss:mem:751e175df861712bbbd11b7b4674c839f78cf563" which obviously doesn't work so well.