<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    <div class="moz-cite-prefix">On 11/6/15 11:25 AM, Phil Lello wrote:<br>
    </div>
    <blockquote
cite="mid:CAPofZaGyFSU96gfi5ZnYzOBEgLoxRxB_7jbOBkiaXiBzGV2yKw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>I now have this working; there were two things to
                change:<br>
                <br>
              </div>
              <br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Glad to hear it.<br>
    <blockquote
cite="mid:CAPofZaGyFSU96gfi5ZnYzOBEgLoxRxB_7jbOBkiaXiBzGV2yKw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>This correctly adds the DS:X509 section to the generated
            XML<br>
            <br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Sending that is optional for a signature.  If you're testing with a
    Shibboleth IdP, that won't make any difference as to the IdP's
    ability to validate the signature.  It's just advisory.<br>
    <br>
    <br>
    <blockquote
cite="mid:CAPofZaGyFSU96gfi5ZnYzOBEgLoxRxB_7jbOBkiaXiBzGV2yKw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>- Adding metadata for the SP to the IdP (I haven't written
          my Metadata export yet, but had expected signed requests to be
          treated the same way as unsigned ones at the IdP, rather than
          throwing (IMHO) a misleading
          "org.opensaml.messaging.handler.MessageHandlerException:
          Validation of protocol message signature failed" when the
          message is intact but the IdP lacks metadata.<br>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
    Having the SP's signing cert in the SP metadata held by the IdP is
    absolutely mandatory.  Trust (e.g signature validation) in
    Shibboleth is based on metadata, period.<br>
    <br>
    <br>
    <blockquote
cite="mid:CAPofZaGyFSU96gfi5ZnYzOBEgLoxRxB_7jbOBkiaXiBzGV2yKw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>Everything now looks good, although I'm not convinced that
          there aren't higher level functions I should be using.<br>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
    <br>
    Indeed, there are lots of higher level components that would greatly
    simplify some of what you posted originally, esp around loading and
    using Credentials and the output of the message to the binding.  I'm
    swamped at the moment with the 3.2 release, but a combination of
    looking at the user's manual [1], the library's unit tests and the
    IdP would be a good place to research.<br>
    <br>
    One note however: it looks like you are using OpenSAML v2.  That
    will be officially unsupported as of middle of next year, along with
    the IdP v2.  If you are starting a new project with OpenSAML, I'd
    highly recommend you use OpenSAML v3. Most of what you already know
    is directly applicable.  There have been some changes in package
    names and some class names, but most of the library works the same
    way (the big exception being the messaging layer for encoding,
    decoding and handling protocol messages, which it doesn't appear you
    are using yet anyway).  Again, looking at unit tests and some of the
    IdP code is probably the best resource at this point.<br>
    <br>
    <br>
    [1]
    <a class="moz-txt-link-freetext" href="https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUserManual">https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUserManual</a> 
    <br>
  </body>
</html>