MDA Removing Signatures

Wed Oct 5 15:03:53 UTC 2022

I found it...

<bean id="MyIdpMDInput"
class="net.shibboleth.metadata.pipeline.SimplePipeline"
  p:id="MyIdpMDInput">
  <property name="stages">
    <util:list>
      <ref bean="readMyIdpMetadata"/>
      <ref bean="validateInCommonSignature"/>
      <ref bean="commonProcessing"/>
    </util:list>
  </property>
</bean>

<bean id="commonProcessing"
class="net.shibboleth.metadata.pipeline.CompositeStage"
  p:id="commonProcessing">
  <property name="composedStages">
    <util:list>
      <ref bean="logItemErrors"/>
      <ref bean="terminateOnInvalidSignature"/>
      <ref bean="validateValidUntil"/>
      <ref bean="disassembleEntitiesDescriptor"/>

*      <ref bean="stripSignatureElement"/>*      <ref
bean="validateSchema"/>
      <ref bean="removeEntities"/>
      <ref bean="removeInvalidContactPerson"/>
      <ref bean="removeOrganization"/>
      <!--
          Extract entityID attributes as ItemIDs so that we can
          remove duplicates when we merge.
      -->
      <bean id="extractIDs"
        p:id="extractIDs"

class="net.shibboleth.metadata.dom.saml.EntityDescriptorItemIdPopulationStage"/>
    </util:list>
  </property>
</bean>

<bean id="stripSignatureElement"
class="net.shibboleth.metadata.dom.ElementStrippingStage">
  <property name="id" value="stripSignatureElement"/>
  <property name="elementName" value="Signature"/>
  <property name="elementNamespace" value="
http://www.w3.org/2000/09/xmldsig#"/>
</bean>

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.

--

Thanks,

Dan

--

Thanks,

Dan McLaughlin
Technology Consortium, LLC
dmclaughlin at tech-consortium.com
mobile: 512.633.8086
http://www.tech-consortium.com

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.

On Wed, Oct 5, 2022 at 8:37 AM Dan McLaughlin <
dmclaughlin at tech-consortium.com> wrote:

> I could have sworn there used to be an API in the MDA to remove
> signatures from metadata.  I was planning on just leaving all the
> signatures, but in the latest release of the SP, the SignatureFilter
> fails to validate any signatures other than the root.  Since I already
> validated all the signatures before aggregating and signing the
> metadata, I figured just removing all the signatures before signing
> the aggregated metadata would be faster than trying to figure out why
> the SP is filtering them out.
>
> From what I can tell, the SP seems to validate the root and any child
> entity descriptors with signatures.
>
> I use the MDA to fetch IDP metadata from multiple sources, including
> several from the InCommon MDQ. I use the MDA to download, validate
> signatures, aggregate, sign the aggregated metadata, then validate the
> signature and schema.  Everything passes validation in the MDA, and if
> I use xmlsectool directly to validate the signature, it also passes
> validation.  But the SP filters out all child entities with signatures
> because it says it can't verify the signature with the supplied keys.
>
> 2022-10-04 16:18:49 INFO Shibboleth.Application : building
> MetadataProvider of type XML...
> 2022-10-04 16:18:49 INFO OpenSAML.MetadataProvider : building
> MetadataFilter of type Signature
> 2022-10-04 16:18:49 INFO XMLTooling.CredentialResolver.Chaining :
> building CredentialResolver of type File
> 2022-10-04 16:18:49 INFO XMLTooling.SecurityHelper : loading
> certificate(s) from file
> (C:/shib-sp/etc/shibboleth/my-fed-signing-cert-2015.pem)
> 2022-10-04 16:18:49 INFO XMLTooling.CredentialResolver.File : no
> private key resolved, usable for verification/trust only
> 2022-10-04 16:18:49 INFO XMLTooling.CredentialResolver.Chaining :
> building CredentialResolver of type File
> 2022-10-04 16:18:49 INFO XMLTooling.SecurityHelper : loading
> certificate(s) from file
> (C:/shib-sp/etc/shibboleth/my-fed-signing-cert-2022.pem)
> 2022-10-04 16:18:49 INFO XMLTooling.CredentialResolver.File : no
> private key resolved, usable for verification/trust only
> 2022-10-04 16:18:49 INFO XMLTooling.CredentialResolver.Chaining :
> building CredentialResolver of type File
> 2022-10-04 16:18:49 INFO XMLTooling.SecurityHelper : loading
> certificate(s) from file
> (C:/shib-sp/etc/shibboleth/inc-md-cert-mdq.pem)
> 2022-10-04 16:18:49 INFO XMLTooling.CredentialResolver.File : no
> private key resolved, usable for verification/trust only
> 2022-10-04 16:18:49 DEBUG OpenSAML.MetadataProvider.XML : using local
> resource
> (C:/shib-sp/var/run/shibboleth/my-federation-idp-devmetadata2.xml),
> will monitor for changes
> 2022-10-04 16:18:49 DEBUG OpenSAML.MetadataProvider.XML : loading
> configuration from external resource...
> 2022-10-04 16:18:49 INFO OpenSAML.MetadataProvider.XML : loaded XML
> resource (C:/shib-sp/var/run/shibboleth/my-federation-idp-devmetadata2.xml)
> 2022-10-04 16:18:49 DEBUG XMLTooling.Signature : unmarshalling ds:Signature
> 2022-10-04 16:18:49 DEBUG XMLTooling.Signature : unmarshalling ds:Signature
> 2022-10-04 16:18:49 DEBUG XMLTooling.Signature : unmarshalling ds:Signature
> 2022-10-04 16:18:49 DEBUG XMLTooling.Signature : unmarshalling ds:Signature
> 2022-10-04 16:18:49 INFO OpenSAML.MetadataProvider : applying metadata
> filter (Signature)
> 2022-10-04 16:18:49 WARN OpenSAML.MetadataFilter.Signature : filtering
> out entity (https://idp.foo.edu/idp/shibboleth) after failed signature
> check: Unable to verify signature with supplied key(s).
> 2022-10-04 16:18:49 WARN OpenSAML.MetadataFilter.Signature : filtering
> out entity (https://idp.bar.edu/idp/shibboleth) after failed signature
> check: Unable to verify signature with supplied key(s).
> 2022-10-04 16:18:49 WARN OpenSAML.MetadataFilter.Signature : filtering
> out entity (https://idp.test.edu/idp/shibboleth) after failed
> signature check: Unable to verify signature with supplied key(s).
>
>
> Here is what Metadata Provider looks like...
>
> <MetadataProvider type="XML" validate="true"
> path="C:/shib-sp/var/run/shibboleth/my-federation-idp-devmetadata2.xml">
> <MetadataFilter type="Signature">
> <CredentialResolver type="Chaining">
> <CredentialResolver type="File"
> certificate="C:/shib-sp/etc/shibboleth/my-fed-signing-cert-2015.pem"/>
> <CredentialResolver type="File"
> certificate="C:/shib-sp/etc/shibboleth/my-fed-signing-cert-2022.pem"/>
> <CredentialResolver type="File"
> certificate="C:/shib-sp/etc/shibboleth/inc-md-cert-mdq.pem"/>
> </CredentialResolver>
> </MetadataFilter>
> </MetadataProvider>
>
> --
>
> Thanks,
>
> Dan McLaughlin
> Technology Consortium, LLC
> dmclaughlin at tech-consortium.com
> mobile: 512.633.8086
> http://www.tech-consortium.com
>
> 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 personal 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20221005/4202e4e9/attachment.htm>