AWS + ECP?

[John Dennis]

On 02/04/2016 08:00 PM, Brent Putman wrote:
>
>
> On 2/4/16 7:03 PM, Cantor, Scott wrote:
>> Formally speaking, ECP is SOAP and requires that content type.

Just be careful, SOAP 1.1 and SOAP 1.2 have different content types.

The media type 'application/soap+xml' is reserved for SOAP 1.2. RFC 3902 
"The "application/soap+xml" media type" states:

   The "application/soap+xml" media type explicitly identifies SOAP 1.2
   message envelopes that have been serialised with XML 1.0; message
   envelopes with a different SOAP namespace version or using another
   XML serialisation MUST NOT use it.

The "SAML V2.0 Enhanced Client or Proxy Profile Version 2.0" (current as 
of August 2013) states that SAML messages are wrapped in SOAP 1.1.

The "Simple Object Access Protocol (SOAP) 1.1" spec 
(https://www.w3.org/TR/2000/NOTE-SOAP-20000508/) in Section 6 "Using 
SOAP in HTTP" states:

    HTTP applications MUST use the media type "text/xml" according to
    RFC 2376 when including SOAP entity bodies in HTTP messages.

Therefore since ECP requires SOAP 1.1 (not SOAP 1.2) and SOAP 1.1 
requires 'text/xml' and because RFC 3902 reserves 'application/soap+xml' 
for SOAP 1.2 the media type should be 'text/xml' not 'application/soap+xml'.


> Yes, I was going to bring that up. It's technically not valid for a
> SOAP/ECP client to not send that.

Correct.

>> Practically speaking, the decoding class doesn't check, and sending
>> anything that doesn't get in the way will work (I tested with foo/bar,
>> worked fine).
>
> Yes, it was pretty much ported over from V2 as-is, and it never checked
> content type.  I guess we were adopting the "be permissive in what you
> accept" rule of internet programming.  We could actively enforce the
> type.  However, that leads to the opposite problem: breaking people who
> currently don't send anything, or who send the wrong thing.  Don't know
> which is preferable...
>
>> I believe the SP is pretty strict about that stuff, just because I
>> don't like having C/C++ code operating on unknown data if I can avoid it.
>
> Philosophically, I agree.  Just pointing out, though, that just because
> the request carries a Content-Type doesn't mean it actually *is* that
> type.  Could be broken or lying.  Which is exactly what curl seems to do
> by default, i.e. I don't think a naked SOAP Envelope is syntactically
> (at least not semantically) valid application/x-www-form-urlencoded (not
> param/value pairs).

FWIW the SAML IdP's, SP's and ECP clients we've written are pretty 
rigorous about content types and the format of HTTP headers and will 
reject requests and/or responses that do not comply with the RFC's. So 
yes we also philosophically agree.

Also, curl cannot know what the Content-Type should be when doing a 
post. But since the vast majority of posts made with curl are 
application/x-www-form-urlencoded it defaults to that Content-Type as a 
friendly favor if you do a post but fail to provide an explicit 
Content-Type header. So it's not really a fault of curl unless you 
believe friendly defaults are evil.


-- 
John