<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hi Mohamed! <br>
</p>
<br>
<blockquote type="cite">an SP tells me that I ought to be able to
POST the SAMLResposne, without URLEncoding it...
<div><br>
</div>
<div>Googling around I can't see how I can influence how the
browser performs the POST.. Is there a way to do this in
shibboleth 3.3.1.</div>
<div><br>
</div>
</blockquote>
<br>
I don't think the Shib IdP is actually encoding (neither URL
encoding nor HTML form encoding) the SAMLRequest/SAMLResponse
parameter in the POST binding implementation. Why do they think we
are? Do you have a sample message or something from them that
demonstrates? I just looked both at the binding impl code +
Velocity template, as well as an actual test message exchange
flowing through my browser, and I don't see it.<br>
<br>
Maybe I'm missing something here, and Scott will remind me. <br>
<br>
<br>
<blockquote
cite="mid:CAOm-VQ6QDdeY0wWoQFK1LiW-NjgLgEP5Mkg_ByX+1TuaXn9RqA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>Quoting the SP:</div>
<div><br>
</div>
<div>> <span style="font-size:12.8px">It doesn't make any
sense to post FORM data which is also base64 encoded with
URL encoding on top of it. All SSO providers sends pure
base64 encoded SAMLResponse and I'm sure the one you are
using do have this capability.</span></div>
<br>
</div>
</div>
</blockquote>
<br>
Well, in general, what "makes sense" (or not) to the SP vendor is
kind of irrelevant. What matters is what the spec says:<br>
<br>
<blockquote type="cite">Note that any form control values included
MUST be transformed so as to be safe to include in the<br>
XHTML document. This includes transforming characters such as
quotes into HTML entities, etc.</blockquote>
<br>
<br>
We clearly are obligated to make sure the HTML is safe against XSS,
etc, and so we do currently HTML form encode the form's action URI
and RelayState parameter in the POST binding. But we don't do
anything that I can see to the SAMLRequest/SAMLResponse param.
Since it's Base64-encoded, it's already "safe" - the only possible
non-alphanumerics would be '+', '/' and '='. So I think we're
already conceptually in agreement with what the SP is saying, at
least via-a-vis the response message param.<br>
<br>
So I just don't know what they are seeing here. We'd need more
specific details from them.<br>
<br>
</body>
</html>