JSON dictionary in the Relay State parameter

[Florian Lengyel]

>> Before I head off to saml-dev about the OASIS spec, there seem to be three takes on the
>>  matter.

>There really aren't, and the errata doesn't enter into it. The errata has to do with SPs protecting themselves in their usage of the field, it has no ?>bearing on the actual requirement on the IdP to be 100% faithful in returning the value.

>> * You make a crucial point: only the SP knows how to use the RelayState, which can
>> create a disconnect between how IdPs handle the data and the errata's broader security
>> intentions.

>It does not, for the reason I stated. The spec requirements are clear and simple.

They might be "clear and simple," except they flatly contradict you on this point. Own it—I say this because I am sick of being patronized and condescended to on this list.  See below for a direct quote from the Errata.

>The errata is about other stuff that doesn't enter into this conversation at all unless one is analyzing the SP's approach to relay state, which is not >the IdP's problem.


Then how do you explain the following passage in the Errata that ex refer to identity providers in the following, and I quote from
SAML Version 2.0 Errata 05 (oasis-open.org)<http://docs.oasis-open.org/security/saml/v2.0/errata05/os/saml-v2.0-errata05-os.html#__RefHeading__8196_1983180497>


Add text to [SAMLBind] Section 3.1.1., before line 233:

New:

Some bindings that define a "RelayState" mechanism do not provide for end to end origin authentication or integrity protection of the RelayState value. Most such bindings are defined in conjunction with HTTP, and RelayState is often involved in the preservation of HTTP resource state that may involve the use of HTTP redirects, or embedding of RelayState information in HTTP responses, HTML content, etc. In such cases, implementations need to beware of Cross-Site Scripting (XSS) and other attack vectors (e.g., Cross-Site Request Forgery, CSRF) that are common to such scenarios.

Implementations MUST carefully sanitize the URL schemes they permit (for example, disallowing anything but "http" or "https"), and should disallow unencoded characters that may be used in mounting such attacks. This caution applies to both identity and service provider implementations.

"This caution applies to both identity and service provider implementations." Not just service providers.

-F






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20240326/28fcabff/attachment.htm>