<div dir="auto"><div dir="ltr">Thanks Brent. This is an SP initiated login config.. when I go through the workflow, the last step, after I properly authenticate against my IdP, is that my browser sends a POST back to the SP... <div>In chrome devtools, I can see that the Post is indeed URL encoded :</div><div><br></div><div><div style="font-size:12.8px"><br class="m_3619661752355433206gmail-Apple-interchange-newline">Content-Type: application/x-www-form-urlenco<wbr>ded</div><div style="font-size:12.8px"><br></div></div><div>I think this is what this SP is complaining about... but is this not expected behavior?</div><div dir="auto"><br></div><div dir="auto">Thanks</div><div dir="auto">Mohamed. </div><div style="font-size:12.8px"><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 25, 2017 at 7:12 PM, Brent Putman <span dir="ltr"><<a href="mailto:putmanb@georgetown.edu" target="_blank">putmanb@georgetown.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <p>Hi Mohamed! <br>
    </p><span>
    <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></span>
    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><span>
    <br>
    <br>
    <blockquote 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></span>
    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>
  </div>

<br>--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.n<wbr>et</a><br></blockquote></div><br></div>