Customize the POST encoding format?

[Tom Scavo]

On Sat, Mar 25, 2017 at 8:10 PM, Mohamed Lrhazi <lrhazi at cua.edu> wrote:
>
> I can see that the Post is indeed URL encoded :
>
> Content-Type: application/x-www-form-urlencoded

On the wire, does the <form> element have an @enctype HTML attribute?
If not, it's default value is "application/x-www-form-urlencoded" by
definition (of the HTML spec, not the SAML spec).

> I think this is what this SP is complaining about... but is this not
> expected behavior?

Yes, this is expected behavior. The SAML spec is silent about the
form/@enctype attribute. The browser may use any value it wants. For
POST, the default is "application/x-www-form-urlencoded" so that's
what you'll get unless the @enctype HTML attribute is present on the
<form> element.

Tom

> On Sat, Mar 25, 2017 at 7:12 PM, Brent Putman <putmanb at georgetown.edu>
> wrote:
>>
>> Hi Mohamed!
>>
>>
>> an SP tells me that I ought to be able to POST the SAMLResposne, without
>> URLEncoding it...
>>
>> 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.
>>
>>
>> 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.
>>
>> Maybe I'm missing something here, and Scott will remind me.
>>
>>
>> Quoting the SP:
>>
>> > 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.
>>
>>
>> Well, in general, what "makes sense" (or not) to the SP vendor is kind of
>> irrelevant.  What matters is what the spec says:
>>
>> Note that any form control values included MUST be transformed so as to be
>> safe to include in the
>> XHTML document. This includes transforming characters such as quotes into
>> HTML entities, etc.
>>
>>
>>
>> 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.
>>
>> So I just don't know what they are seeing here.  We'd need more specific
>> details from them.
>>
>>
>> --
>> To unsubscribe from this list send an email to
>> users-unsubscribe at shibboleth.net
>
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net