<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 3/22/24 11:18 PM, Florian Lengyel
via users wrote:<br>
</div>
<blockquote type="cite"
cite="mid:MW5PR14MB5387A6E61B1EEF0034CD5E178E302@MW5PR14MB5387.namprd14.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<span>... with the expectation that the IdP will return this value
verbatim to the service provider along with the SAML Response.</span></blockquote>
<p><br>
</p>
<p>Yes, that is a requirement in the spec.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:MW5PR14MB5387A6E61B1EEF0034CD5E178E302@MW5PR14MB5387.namprd14.prod.outlook.com">
<div dir="auto"><br>
</div>
<div dir="auto">Oracle Access Manager sanitizes the unsafe curly
brackets and double quotes, in accordance<span> with the</span><span
style="font-size: 12pt;"> OASIS SAML 2.0 standard, by
replacing the unsafe characters with a diamond containing a
question mark. </span><span style="font-size: 12pt;">That
leads to login failures. </span><br>
</div>
</blockquote>
<p><br>
</p>
<p>That result seems not correct if it's emitting a "<span
style="font-size: 12pt;">diamond containing a question mark".
That sounds like maybe a Unicode issue or some such - depends on
how you view the encoded data.</span></p>
<p><span style="font-size: 12pt;">You didn't mention the outbound
binding, but assuming it's POST, that ought to come out as
HTML-encoded. However...</span><br>
</p>
If the SP is actually sending the JSON as a literal JSON string,
then that's unwise, for this exact reason. A better approach would
be to encode it so that it is a completely URL- or HTML-safe string,
so that no party will mutate it and cause lack of fidelity with the
original data. Base64 (or really Base64URL) would be a good choice.
If you want to go to these 2 vendors and ask them to fix something,
that seems the more bulletproof approach. But see below for the
actual requirements. JSON - encoded or not - is quite possibly too
large.<br>
<p><br>
</p>
<blockquote type="cite"
cite="mid:MW5PR14MB5387A6E61B1EEF0034CD5E178E302@MW5PR14MB5387.namprd14.prod.outlook.com">
<div dir="auto"><span style="font-size: 12pt;"><br>
</span></div>
<div dir="auto"><span style="font-size: 12pt;">Shibboleth version
4.0.1 allowed unusual Relay State parameters such as JSON
dictionaries--perhaps I overlooked a configuration I should
have set.</span></div>
</blockquote>
<p><br>
</p>
<p>We try to adhere to the spec. I think that the Java servlet spec
impl we use in the IdP automatically decodes URL and form params
before the IdP would see them. Then we would appropriately
re-encode them on the way back out based on the binding in use.
So in your case it must be that whatever we are doing, it just
happens to "work", based on what we happened to receive.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:MW5PR14MB5387A6E61B1EEF0034CD5E178E302@MW5PR14MB5387.namprd14.prod.outlook.com">
<div dir="auto"><span style="font-size: 12pt;"><br>
</span></div>
<div dir="auto"><span style="font-size: 12pt;">My under<span>standing
is that the Relay State should contain an opaque identifier,
whose interpretation is known only by the service provider. </span></span><span
style="font-size: 12pt;">Am I mistaken? Service provider
implementations are supposed to follow the standard and not
send data structure through the Relay State parameter. <br>
</span></div>
</blockquote>
<p><br>
</p>
<p>It's not really defined as an "identifier" per se, and the
structure/syntax of the value isn't formally constrained like
that. There's not even a requirement that it be opaque to the
recipient. There is an RFC "SHOULD" that it should be integrity
protected and tamper proof "by using a checksum, a pseudo-random
value, or similar means". (Can't digitally sign it, not enough
space). So sending literal JSON violates that recommendation...but
it's only a recommendation.</p>
<p>The Shib SP uses a pseudo-random value which winds up on-the-wire
at least as a simple alphanumeric string (which is just an index
into state stored back on the SP side). An approach like that
meets the tamper proof recommendation.<br>
</p>
<p>The other requirement though is that it is limited to 80 bytes in
size (RFC "MUST NOT" exceed). An arbitrary JSON object could
easily violate that. I'd check what they are actually sending and
if they're over that limit, you can point out that that is a clear
spec violation.</p>
<p>If you want all the details, look at the SAML 2.0 Bindings spec
doc. Section 3.4.3 is for the Redirect binding and 3.5.3 is for
POST binding (but they're basically identical).<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:MW5PR14MB5387A6E61B1EEF0034CD5E178E302@MW5PR14MB5387.namprd14.prod.outlook.com">
<div dir="auto"><span style="font-size: 12pt;"><span> How common
is sending JSON through the Relay <span>State? <br>
</span></span></span></div>
</blockquote>
<p><br>
</p>
<p>I doubt it's common and I personally haven't ever seen or heard
of a vendor doing it. But it's not technically disallowed as far
as I know, as long as it's under the 80 byte limit. But it's
probably not the wisest approach.<br>
</p>
<br>
</body>
</html>