<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 11/7/16 4:54 PM, Kim, Allan wrote:<br>
</div>
<blockquote
cite="mid:A86F20B04C9D1B42B362008FD2FC50F77D7CFF7D@XMAIL-MBX-AT1.AD.UCSD.EDU"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.pl-s
{mso-style-name:pl-s;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">At UCSD we’ve run into some unexpected
behavior while testing ECP with IdP 3.3.0-SNAPSHOT. The latest
opensaml-soap-impl has added content type validation for SOAP
requests in HTTPSOAP11Decoder, and accepts only text/xml as a
valid type. I’m sure this is technically correct for SOAP 1.1
</p>
</div>
</blockquote>
<br>
It's not just technically correct, it's an RFC MUST, see [1] part 6:<br>
<br>
"
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
HTTP applications MUST use the media type "text/xml" according to
RFC 2376 [3] when including SOAP entity bodies in HTTP messages."<br>
<br>
Per RFC 2119, the MUST means it's an absolute requirement, there's
no wiggle room at all.
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
Clients sending anything else are just broken. I'm not terribly
inclined to make our code more complex to deal with broken clients,
especially if there's a relatively easy workaround.<br>
<br>
<blockquote
cite="mid:A86F20B04C9D1B42B362008FD2FC50F77D7CFF7D@XMAIL-MBX-AT1.AD.UCSD.EDU"
type="cite">
<div class="WordSection1">
<p class="MsoNormal">– however various ECP reference client
implementations have gotten away with using other content
types in the past and now seem to fail validation. For example
ShibHttpClient from
<a moz-do-not-send="true"
href="https://github.com/DARIAH-DE/shib-http-client">https://github.com/DARIAH-DE/shib-http-client</a>
sends text/plain, </p>
</div>
</blockquote>
<br>
That seems trivially wrong.<br>
<br>
<blockquote
cite="mid:A86F20B04C9D1B42B362008FD2FC50F77D7CFF7D@XMAIL-MBX-AT1.AD.UCSD.EDU"
type="cite">
<div class="WordSection1">
<p class="MsoNormal">and I think SwiftECP sends
<span class="pl-s">application/vnd.paos+xml. </span></p>
</div>
</blockquote>
<br>
That just doesn't even make any sense. The request to the IdP is
NOT reverse SOAP (PAOS), it's SOAP, period.<br>
<br>
<blockquote
cite="mid:A86F20B04C9D1B42B362008FD2FC50F77D7CFF7D@XMAIL-MBX-AT1.AD.UCSD.EDU"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span class="pl-s"><o:p></o:p></span></p>
<p class="MsoNormal"><span class="pl-s"><o:p> </o:p></span></p>
<p class="MsoNormal"><span class="pl-s">Is it possible to turn
either content type validation or SUPPORTED_MEDIA_TYPES into
configurable options? This would allow IdP deployers to
support slightly out-of-spec clients while allowing other
OpenSAML users to enforce strict validation when desired.</span></p>
<br>
</div>
</blockquote>
<br>
<br>
I'd suggest to go with Scott's filter solution, to just force the
Content-Type as seen by the application to text/xml.<br>
<br>
Even if we did expose such options on the decoder to allow
workarounds for broken clients, in the IdP it would be problematic
to set them. The decoders are all defined under system/ which isn't
designed to be user-modifiable. I suppose we could expose a
property or something. It would have to mean an enumeration of the
allowed types, not a boolean. If you just turned off validation,
you'd be broken and the request would fail if the client sent
'application/x-www-form-urlencoded', which was the original problem
here. [2] [3] curl does that by default on a POST if you don't tell
it otherwise.<br>
<br>
<br>
<br>
[1] <a class="moz-txt-link-freetext" href="https://www.w3.org/TR/2000/NOTE-SOAP-20000508/">https://www.w3.org/TR/2000/NOTE-SOAP-20000508/</a><br>
<br>
[2] <a class="moz-txt-link-freetext" href="https://issues.shibboleth.net/jira/browse/OSJ-155">https://issues.shibboleth.net/jira/browse/OSJ-155</a><br>
<br>
[3] <a class="moz-txt-link-freetext" href="https://issues.shibboleth.net/jira/browse/IDP-708">https://issues.shibboleth.net/jira/browse/IDP-708</a><br>
<br>
</body>
</html>