Metadata resolver is looking at ID instead of entityID

[Cody Carmichael]

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=
> https://mySP.net/rest/v2/sso/message/shibboleth/metadata
> <https://mysp.net/rest/v2/sso/message/shibboleth/metadata>]


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:
>  https://mySP.net/rest/v2/sso/message/shibboleth/metadata
> <https://mysp.net/rest/v2/sso/message/shibboleth/metadata>


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 osu.edu> 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 https://wiki.shibboleth.net/
> confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>



-- 



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


<http://www.voalte.com/klas-report-classifies-voalte-as-a-strategic-solution-provider-with-the-most-robust-interfacing/>
<http://www.voalte.com/klas-report-classifies-voalte-as-a-strategic-solution-provider-with-the-most-robust-interfacing/>
<http://www2.voalte.com/l/8232/2017-01-30/6k3skb>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180806/b6e25c18/attachment.html>