Metadata resolver is looking at ID instead of entityID

Cody Carmichael ccarmichael at
Mon Aug 6 14:29:21 EDT 2018

What I put for my original metadata-rpovider was a poor copy/paste, sorry.

When I configure my metadata provider like so:

<MetadataProvider id="LocalEntityMetadataCRC" xsi:type="
> FilesystemMetadataProvider"
>                       metadataFile="/opt/shibboleth-
> idp/metadata/meta-cert2.xml">
> </MetadataProvider>

It's able to resolve it, per the logs

Metadata Resolver FilesystemMetadataResolver LocalEntityMetadataCRC:
> Resolved 1 candidates via EntityIdCriterion: EntityIdCriterion [id=
> <>]

If I recall correctly, this is because there are no configured child
elements so it falls back to using the well-known location strategy (which
I guess means it uses the entityID? Unless falling back to the well-known
location strategy is just for DynamicHTTPMetadataProvider where
that warning about lack of child filters is documented). But I would like
to configure the metadata provider with SignatureValidation. So I
configured the metadata-provider thusly:

<MetadataProvider id="LocalEntityMetadataCRC" xsi:type="
> FilesystemMetadataProvider"
>                       metadataFile="/opt/shibboleth-
> idp/metadata/meta-cert2.xml">
>         <MetadataFilter xsi:type="SignatureValidation"
> certificateFile="%{idp.home}/credentials/cert.pem" />
> </MetadataProvider>

And the logs tell me this:

Metadata Resolver FilesystemMetadataResolver LocalEntityMetadataCRC:
> Metadata backing store does not contain any EntityDescriptors with the ID:
> <>

So what's happening here? The cert.pem contains the public key that was
used to sign the metadata. If it's not using the entityID anymore because
of the presence of a child element, and it's not using the ID in the
metadata, what is it using? What's the big giant elephant I'm missing?

On Mon, Aug 6, 2018 at 2:18 PM, Cantor, Scott <cantor.2 at> wrote:

> > No, you're interpreting that too literally.   Metadata lookup (at least
> in all the
> > basic and common cases) is by entityID.  Additionally, the ID attrib in
> > metadata is usually a transient value, generated and assigned anew on
> each
> > new document "version", and as such there is no way that it could be
> used as
> > the basis for looking it up by another party, since there's practically
> speaking
> > no way they would or could know it in advance.
> Metadata's much looser, it can definitely be a fixed value, that's not
> unusual. It's just the signature anchor. I would probably suggest we clean
> up that message, though it's true it hasn’t really come up before.
> -- Scott
> --
> For Consortium Member technical support, see
> confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at


*Cody Carmichael *
Engineering Operations  | Voalte
Office: 941-312-2830 | Ext
Email: ccarmichael at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list