<html>

  <head>

    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <br>

    <br>

    <div class="moz-cite-prefix">On 4/11/16 1:05 PM, Paul Hethmon wrote:<br>

    </div>

    <blockquote

      cite="mid:8379A5A1-1A60-4F80-B110-E0E0544E2767@clareitysecurity.com"

      type="cite">

      <pre wrap="">The bug is on the generating side, it’s not putting the proper padding on the encoded string.</pre>

    </blockquote>

    <br>

    Yep.  Not a multiple of 4 bytes.<br>

    <br>

    <br>

    <blockquote

      cite="mid:8379A5A1-1A60-4F80-B110-E0E0544E2767@clareitysecurity.com"

      type="cite">

      <pre wrap="">

I think I can make a case that the XML Tooling code should throw an error here or take the Apache approach and assume the padding.</pre>

    </blockquote>

    <br>

    That's how we *would* fix it if it weren't EOL.<br>

    <br>

    <blockquote

      cite="mid:8379A5A1-1A60-4F80-B110-E0E0544E2767@clareitysecurity.com"

      type="cite">

      <pre wrap=""> Given this is with a v2 system, there is no fix to be made there,</pre>

    </blockquote>

    <br>

    Right, EOL, so no fix.  So you'll need to get the generating side to

    fix.<br>

    <br>

    I did look to see whether the SAML 2 Bindings spec says anything

    about padding required or not.  It doesn't directly, just invoked

    RFC 2045.  The language there doesn't have a MUST, but it seems

    pretty clear on my read that it's required.<br>

    <br>

    In my experience, some Base64 encoding libraries in some languages

    deliberately do not add any padding, leaving it up to the caller to

    do so.  So that might be the case for whatever is generating this

    SAML binding request.<br>

    <br>

    <blockquote

      cite="mid:8379A5A1-1A60-4F80-B110-E0E0544E2767@clareitysecurity.com"

      type="cite">

      <pre wrap=""> not sure if v3 is essentially the same code.

</pre>

    </blockquote>

    <br>

    It's not.  V2 had a Base64 class copied in from some other open

    source project.  So it doesn't handle this case.  V3 java-support's

    Base64Support is just a light wrapper around the Apache

    commons-codec.  As Paul pointed out in the Jira, it already handles

    this case, so v3 does too.<br>

    <br>

  </body>

</html>