Relaystate Problem

[Cantor, Scott]

On 10/15/12 1:44 PM, "Rainer Hoerbe" <rainer at hoerbe.at> wrote:
>
>First, the initial resource URL was mapped to the correct path:
>Shibboleth.Apache [20999] shib_check_user: mapped
>https://storksaml2.portalverbund.at/secure/echo.php to storksaml2
>
>Second, the ACS digested the Response:
>Shibboleth.Apache [21001] shib_check_user: mapped
>https://storksaml2.portalverbund.at/Shibboleth.sso/SAML2/POST to
>storksaml2
>
>Third, the original mapping seems to be lost:
>Shibboleth.Apache [21001] shib_check_user: mapped
>https://storksaml2.portalverbund.at/ to storksaml2

No, the mapping is fine, it says storksaml2. That's all that I was after.
So it should derive the correct cookie name based on that.

>Both name and value are identical.

Then I have no idea, unless the SP response is broken in some way. It
isn't consuming the state, for whatever reason.

>For my understanding: Doesn't <SessionInitiator relayState="cookie" ...>
>specify to use the cookie to store the resource path in the cookie? It
>looks very much like this:
>Cookie: 
>_shibstate_1350286969_c8e2=https%3A%2F%2Fpvpsaml2.portalverbund.at%2Fsecur
>e%2Fecho.php

Yes. But the name will depend on the applicationId, so if that's off, it
won't recover it. Since it's not apparently wrong, that shouldn't be a
problem.

I don't know why else it could be failing. As a test, I'd probably go
ahead and try the alternate relayState types particularly taking it out
altogether and let it pass the URL as the state. Just as a test.

Also, I'd perhaps look and see what the response to the SP looks like in
the HTML form it's posting. Is there anything unusual about the RelayState
form input? More than one of them?

-- Scott