<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 1/14/15 7:18 AM, Marvin Addison
      wrote:<br>
    </div>
    <br>
    <br>
    <br>
    <blockquote
cite="mid:CACOs9MTogSD++rSbcUOvFwprkhg3=A1S5m31fMmz7-ZucU_f+Q@mail.gmail.com"
      type="cite">
      <div>
        <div><br>
        </div>
        <div>
          <div>    &lt;bean
            id="shibboleth.idp.ext.OpensamlCustomSecurityConfig"</div>
          <div>       
class="edu.internet2.middleware.shibboleth.idp.ext.securityconfig.OpensamlCustomSecurityConfigBean"</div>
          <div>        depends-on="shibboleth.OpensamlConfig"&gt;</div>
          <div><br>
          </div>
          <div>        &lt;!-- primary algorithms for use with RSA
            signing keys --&gt;</div>
          <div>        &lt;property name="signatureAlgorithmRSA"</div>
          <div>            value="<a moz-do-not-send="true"
              href="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256">http://www.w3.org/2001/04/xmldsig-more#rsa-sha256</a>"/&gt;</div>
          <div>        &lt;property
            name="signatureReferenceDigestMethod"</div>
          <div>            value="<a moz-do-not-send="true"
              href="http://www.w3.org/2001/04/xmlenc#sha256">http://www.w3.org/2001/04/xmlenc#sha256</a>"/&gt;</div>
        </div>
      </div>
    </blockquote>
    <br>
    <br>
    Those algorithms look correct to me for RSA, at least just
    eyeballing it.  In any case, if they weren't, you'd get an exception
    from Santuario or the JCA framework indicating an invalid or
    unresolveable algorithm.  The same would be true if the SHA-256
    variants weren't supported by your JRE.<br>
    <br>
    <br>
    <br>
    <blockquote
cite="mid:CACOs9MTogSD++rSbcUOvFwprkhg3=A1S5m31fMmz7-ZucU_f+Q@mail.gmail.com"
      type="cite">
      <div><br>
        <div>I've turned up loggers for more information, but I simply
          don't see what's wrong. I hope someone on the list has some
          suggestions.<br>
        </div>
      </div>
      <br>
    </blockquote>
    <br>
    I don't have any really good ideas.  Maybe if this security config
    initializing bean was really running before OpenSAML actually was
    initialized, the global security config instance would be null, so
    the config bean would be essentially a no-op and so nothing would be
    set.  But the depends-on above looks correct, unless you guys have
    renamed the 'shibboleth.OpensamlConfig' bean for some reason.  Maybe
    check for an unintended character added to the bean name or
    something l like - a stray vi keystroke, etc?<br>
    <br>
    The only logging in the config bean is just the case where the
    global security config isn't an instance of the expected type, which
    would also catch the null case I just described.  That's on WARN, so
    if you aren't seeing that, I'm out of ideas at the moment.  This
    bean is very simple, there's not much to go wrong.<br>
    <br>
    Since it's just the one class and the project is easy to build, my
    only other suggestion would be to add some debug logging to the
    config initializing bean, just to see if it's even getting called
    and doing anything.  Or if you want I could do that in the project
    in svn itself.<br>
    <br>
    <br>
  </body>
</html>