JSON dictionary in the Relay State parameter

[Florian Lengyel]

OK, thank you.

I agree with Scott also. He assumes, correctly (I checked to make sure) that the SP sends a URL-encoded RelayState, in this case, a URL-encoded JSON dictionary. Here it is, URL-encoded (with some data values changed):

RelayState=%7B%22action%22%3A%22login%22%2C%22accountId%22%3A%0123456789-7cd3-46ff-a6f4-012345678912%22%2C%22redirect%22%3Anull%7D

And in that case, the IdP is supposed to send the RelayState back to the SP verbatim, if I understand Scott correctly.
That's not what Oracle Access Manager 12c does. URL-decodes the RelayState, replaces the curly braces and quotation marks with a Unicode character, and sends that instead. The Oracle IdP behavior seems to rely on an expansive interpretation of E90, at 4.1.6, as you note below.

Then again, as Scott says, "...your Oracle IdP is, huge shock, broken. That will not be the only bug, trust me."  For the record, I trust Scott. Shibboleth did not have this issue.

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


With your correction, the gap between the interpretations narrows slightly, particularly with his acknowledgment that data used to derive URLs, not just explicit URLs, falls under the errata's guidance. However, inconsistencies remain:

  *
While Scott focuses on the procedural integrity of data transmission, you and Oracle recognize broader risks associated with the data's content and its potential use. The inconsistency lies in how different parties interpret and address these risks broadly or narrowly.
  *
 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.
  *
Scott and your views start from a practical standpoint—emphasizing URL-encoding and the risks of unsigned data—while Oracle's broader approach aims at conceptual security, potentially covering scenarios beyond current standard practices or interpretations.

Many thanks,
Florian

________________________________
From: users <users-bounces at shibboleth.net> on behalf of Brent Putman via users <users at shibboleth.net>
Sent: Monday, March 25, 2024 2:28 PM
To: Shib Users <users at shibboleth.net>
Cc: Brent Putman <putmanb at georgetown.edu>
Subject: Re: JSON dictionary in the Relay State parameter


* This email originates from a sender outside of CUNY. Verify the sender before replying or clicking on links and attachments. *


On 3/25/24 8:42 AM, Cantor, Scott via users wrote:

My intention in this discussion is not to be confrontational but to seek a shared
understanding of the SAML 2.0 specifications, especially regarding handling the
RelayState. According to the text from Errata E90:


I echo everything that Scott said. Without a signature over the RelayState data, such as by a binding-level signature, the data is subject to manipulation.  So that's the main threat. That's why sending non-opaque data like URLs or JSON is not wise.

But in terms of what I said earlier:  Yes, in my rush to answer, I did overlook the errata language which mentioned the possibility of URLs "derived from" the RelayState.  So obviously if the JSON data contained literal URL(s) (e.g as a key value etc), then those are subject to the requirements of the errata (RFC "MUST" and "MUST NOT").  And technically, yes, if there is arbitrary data there that later will be used in the production/generation/derivation of URLs, then that would be covered too, conceptually speaking. But note that, in the absence of actual plainly visible URLs, no one but the SP could possibly know how the data would be used for that purpose.

If you have questions or seek clarifications about the SAML spec itself, there is an OASIS list (saml-dev) specifically for questions like this:

https://saml.xml.org/mail-lists-and-forums<https://urldefense.com/v3/__https://saml.xml.org/mail-lists-and-forums__;!!PxiZbSOawA!Nx7EUHj_Stm4KXb5JCmbrdFmeKVCVZRhoJtfG6xvISRBjB0SN6GZjpPWMW14fAWwSNLy__e9C1JBUoEyWSB8ilx8$>

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