JSON dictionary in the Relay State parameter

[Brent Putman]

On 3/22/24 11:18 PM, Florian Lengyel via users wrote:
> ... with the expectation that the IdP will return this value verbatim 
> to the service provider along with the SAML Response.


Yes, that is a requirement in the spec.


>
> Oracle Access Manager sanitizes the unsafe curly brackets and double 
> quotes, in accordancewith the OASIS SAML 2.0 standard, by replacing 
> the unsafe characters with a diamond containing a question mark. That 
> leads to login failures.


That result seems not correct if it's emitting a "diamond containing a 
question mark". That sounds like maybe a Unicode issue or some such - 
depends on how you view the encoded data.

You didn't mention the outbound binding, but assuming it's POST, that 
ought to come out as HTML-encoded. However...

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.


>
> Shibboleth version 4.0.1 allowed unusual Relay State parameters such 
> as JSON dictionaries--perhaps I overlooked a configuration I should 
> have set.


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.


>
> My understanding is that the Relay State should contain an opaque 
> identifier, whose interpretation is known only by the service 
> provider. Am I mistaken? Service provider implementations are 
> supposed to follow the standard and not send data structure through 
> the Relay State parameter.


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.

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.

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.

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).


>  How common is sending JSON through the Relay State?


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.

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