<div dir="ltr">I found it...<br><br><bean id="MyIdpMDInput" class="net.shibboleth.metadata.pipeline.SimplePipeline"<br>  p:id="MyIdpMDInput"><br>  <property name="stages"><br>    <util:list><br>      <ref bean="readMyIdpMetadata"/><br>      <ref bean="validateInCommonSignature"/><br>      <ref bean="commonProcessing"/><br>    </util:list><br>  </property><br></bean><br><br><bean id="commonProcessing" class="net.shibboleth.metadata.pipeline.CompositeStage"<br>  p:id="commonProcessing"><br>  <property name="composedStages"><br>    <util:list><br>      <ref bean="logItemErrors"/><br>      <ref bean="terminateOnInvalidSignature"/><br>      <ref bean="validateValidUntil"/><br>      <ref bean="disassembleEntitiesDescriptor"/><br><b>      <ref bean="stripSignatureElement"/><br></b>      <ref bean="validateSchema"/><br>      <ref bean="removeEntities"/><br>      <ref bean="removeInvalidContactPerson"/><br>      <ref bean="removeOrganization"/><br>      <!--<br>          Extract entityID attributes as ItemIDs so that we can<br>          remove duplicates when we merge.<br>      --><br>      <bean id="extractIDs"<br>        p:id="extractIDs"<br>        class="net.shibboleth.metadata.dom.saml.EntityDescriptorItemIdPopulationStage"/><br>    </util:list><br>  </property><br></bean><br><br><br><bean id="stripSignatureElement" class="net.shibboleth.metadata.dom.ElementStrippingStage"><br>  <property name="id" value="stripSignatureElement"/><br>  <property name="elementName" value="Signature"/><br>  <property name="elementNamespace" value="<a href="http://www.w3.org/2000/09/xmldsig#">http://www.w3.org/2000/09/xmldsig#</a>"/><br></bean><br><br>I still haven't figured out why the SP SignatureFilter was filtering out the child entities.  The best I can tell the problem is with the MDA.  When I compare the metadata downloaded from the MDQ service using wget to what the MDA has aggregated the only difference in the entity descriptor is there is a comment line in the metadata when I download the metadata using wget that is somehow getting stripped out when the MDA is aggregating the metadata.  I can't find a specific MDA stage I have configured that would explain the comments being removed, but I'll find it eventually.  For now, removing the Signature after I validate the metadata prior to commonProcessing has resolved the issue and the SP is now loading all the entities. <br><br>--<br><br>Thanks,<br><br>Dan </div><br clear="all"><div><div dir="ltr" class="gmail_signature"><br>--<br><br>Thanks,<br><br>Dan McLaughlin<br>Technology Consortium, LLC<br><a href="mailto:dmclaughlin@tech-consortium.com" target="_blank">dmclaughlin@tech-consortium.com</a><br>mobile: 512.633.8086<br><a href="http://www.tech-consortium.com" target="_blank">http://www.tech-consortium.com</a><br><br>NOTICE: This e-mail message and all attachments transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is strictly prohibited. The contents of this e-mail are confidential and may be subject to work product privileges. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.</div></div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 5, 2022 at 8:37 AM Dan McLaughlin <<a href="mailto:dmclaughlin@tech-consortium.com">dmclaughlin@tech-consortium.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I could have sworn there used to be an API in the MDA to remove<br>
signatures from metadata.  I was planning on just leaving all the<br>
signatures, but in the latest release of the SP, the SignatureFilter<br>
fails to validate any signatures other than the root.  Since I already<br>
validated all the signatures before aggregating and signing the<br>
metadata, I figured just removing all the signatures before signing<br>
the aggregated metadata would be faster than trying to figure out why<br>
the SP is filtering them out.<br>
<br>
>From what I can tell, the SP seems to validate the root and any child<br>
entity descriptors with signatures.<br>
<br>
I use the MDA to fetch IDP metadata from multiple sources, including<br>
several from the InCommon MDQ. I use the MDA to download, validate<br>
signatures, aggregate, sign the aggregated metadata, then validate the<br>
signature and schema.  Everything passes validation in the MDA, and if<br>
I use xmlsectool directly to validate the signature, it also passes<br>
validation.  But the SP filters out all child entities with signatures<br>
because it says it can't verify the signature with the supplied keys.<br>
<br>
2022-10-04 16:18:49 INFO Shibboleth.Application : building<br>
MetadataProvider of type XML...<br>
2022-10-04 16:18:49 INFO OpenSAML.MetadataProvider : building<br>
MetadataFilter of type Signature<br>
2022-10-04 16:18:49 INFO XMLTooling.CredentialResolver.Chaining :<br>
building CredentialResolver of type File<br>
2022-10-04 16:18:49 INFO XMLTooling.SecurityHelper : loading<br>
certificate(s) from file<br>
(C:/shib-sp/etc/shibboleth/my-fed-signing-cert-2015.pem)<br>
2022-10-04 16:18:49 INFO XMLTooling.CredentialResolver.File : no<br>
private key resolved, usable for verification/trust only<br>
2022-10-04 16:18:49 INFO XMLTooling.CredentialResolver.Chaining :<br>
building CredentialResolver of type File<br>
2022-10-04 16:18:49 INFO XMLTooling.SecurityHelper : loading<br>
certificate(s) from file<br>
(C:/shib-sp/etc/shibboleth/my-fed-signing-cert-2022.pem)<br>
2022-10-04 16:18:49 INFO XMLTooling.CredentialResolver.File : no<br>
private key resolved, usable for verification/trust only<br>
2022-10-04 16:18:49 INFO XMLTooling.CredentialResolver.Chaining :<br>
building CredentialResolver of type File<br>
2022-10-04 16:18:49 INFO XMLTooling.SecurityHelper : loading<br>
certificate(s) from file<br>
(C:/shib-sp/etc/shibboleth/inc-md-cert-mdq.pem)<br>
2022-10-04 16:18:49 INFO XMLTooling.CredentialResolver.File : no<br>
private key resolved, usable for verification/trust only<br>
2022-10-04 16:18:49 DEBUG OpenSAML.MetadataProvider.XML : using local<br>
resource (C:/shib-sp/var/run/shibboleth/my-federation-idp-devmetadata2.xml),<br>
will monitor for changes<br>
2022-10-04 16:18:49 DEBUG OpenSAML.MetadataProvider.XML : loading<br>
configuration from external resource...<br>
2022-10-04 16:18:49 INFO OpenSAML.MetadataProvider.XML : loaded XML<br>
resource (C:/shib-sp/var/run/shibboleth/my-federation-idp-devmetadata2.xml)<br>
2022-10-04 16:18:49 DEBUG XMLTooling.Signature : unmarshalling ds:Signature<br>
2022-10-04 16:18:49 DEBUG XMLTooling.Signature : unmarshalling ds:Signature<br>
2022-10-04 16:18:49 DEBUG XMLTooling.Signature : unmarshalling ds:Signature<br>
2022-10-04 16:18:49 DEBUG XMLTooling.Signature : unmarshalling ds:Signature<br>
2022-10-04 16:18:49 INFO OpenSAML.MetadataProvider : applying metadata<br>
filter (Signature)<br>
2022-10-04 16:18:49 WARN OpenSAML.MetadataFilter.Signature : filtering<br>
out entity (<a href="https://idp.foo.edu/idp/shibboleth" rel="noreferrer" target="_blank">https://idp.foo.edu/idp/shibboleth</a>) after failed signature<br>
check: Unable to verify signature with supplied key(s).<br>
2022-10-04 16:18:49 WARN OpenSAML.MetadataFilter.Signature : filtering<br>
out entity (<a href="https://idp.bar.edu/idp/shibboleth" rel="noreferrer" target="_blank">https://idp.bar.edu/idp/shibboleth</a>) after failed signature<br>
check: Unable to verify signature with supplied key(s).<br>
2022-10-04 16:18:49 WARN OpenSAML.MetadataFilter.Signature : filtering<br>
out entity (<a href="https://idp.test.edu/idp/shibboleth" rel="noreferrer" target="_blank">https://idp.test.edu/idp/shibboleth</a>) after failed<br>
signature check: Unable to verify signature with supplied key(s).<br>
<br>
<br>
Here is what Metadata Provider looks like...<br>
<br>
<MetadataProvider type="XML" validate="true"<br>
path="C:/shib-sp/var/run/shibboleth/my-federation-idp-devmetadata2.xml"><br>
<MetadataFilter type="Signature"><br>
<CredentialResolver type="Chaining"><br>
<CredentialResolver type="File"<br>
certificate="C:/shib-sp/etc/shibboleth/my-fed-signing-cert-2015.pem"/><br>
<CredentialResolver type="File"<br>
certificate="C:/shib-sp/etc/shibboleth/my-fed-signing-cert-2022.pem"/><br>
<CredentialResolver type="File"<br>
certificate="C:/shib-sp/etc/shibboleth/inc-md-cert-mdq.pem"/><br>
</CredentialResolver><br>
</MetadataFilter><br>
</MetadataProvider><br>
<br>
--<br>
<br>
Thanks,<br>
<br>
Dan McLaughlin<br>
Technology Consortium, LLC<br>
<a href="mailto:dmclaughlin@tech-consortium.com" target="_blank">dmclaughlin@tech-consortium.com</a><br>
mobile: 512.633.8086<br>
<a href="http://www.tech-consortium.com" rel="noreferrer" target="_blank">http://www.tech-consortium.com</a><br>
<br>
NOTICE: This e-mail message and all attachments transmitted with it<br>
are for the sole use of the intended recipient(s) and may contain<br>
confidential and privileged information. Any unauthorized review, use,<br>
disclosure, or distribution is strictly prohibited. The contents of<br>
this e-mail are personal and may be subject to work product<br>
privileges. If you are not the intended recipient, please contact the<br>
sender by reply e-mail and destroy all copies of the original message.<br>
</blockquote></div>