Unsolicited IDP: RelayState and target

[Cantor, Scott]

> When SFDC sends the user back to our IDP,  they also send back post data
> with a RelayState variable set to the originally requested protected
> URL.  I belive SFDC is trying to emulate an SP, but they aren't an
> official SP.

We don't support non-standard requests. The only things we support for SAML 2 are standard requests, or the unsolicited trigger protocol that was modeled on the old 1.x request profile. Most broken SPs that can't generate standard requests can be told to issue redirects with some parameters that will allow that endpoint to be used, but if they don't allow control over the parameters, then it won't work.

>  From what I can tell here,
> https://wiki.shibboleth.net/confluence/display/SHIB2/IdPUnsolicitedSSO,
> the target parameter can be passed in along with the entityID to emulate
> the RelayState.

Yes, to match the old protocol. RelayState is a SAML parameter name and it's less confusing (to me) to avoid using SAML binding conventions when inventing a non-SAML protocol.

> Can I configured Unsolicited SSO to use the RelayState?

Not without plugging a custom MessageDecoder in. The UnsolictedSSO endpoint was coded to allow the protocol to be essentially replaced separately from the handler itself by plugging in a different decoder.

> Looking at the
> headers, it appears that the RelayState data is lost through
> authentication of my container.  If it can't be used, can the target
> parameter be configured to look at the RelayState post data?

The target parameter is "target", period. It also isn't necessarily the case that you can read POST body parameters in a GET at all. That would be up to the container.

-- Scott