Metadata resolver is looking at ID instead of entityID

[Tom Scavo]

On Mon, Aug 6, 2018 at 2:29 PM, Cody Carmichael <ccarmichael at voalte.com> wrote:
>
> 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]

That's because you removed the metadata filter, which has a bug (your bug).

> 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).

The "well-known location strategy" applies to
DynamicHTTPMetadataProvider only. If you find documentation to the
contrary, please let me know.

> 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>

Where did you get this signed metadata in the first place? Local
metadata is rarely signed.

Tom