Metadata resolver is looking at ID instead of entityID

[Brent Putman]

On 8/6/18 2:29 PM, Cody Carmichael wrote:
> 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>]
>

Ok, good.  Then there's nothing fundamentally wrong with the metadata
itself.

>
> 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 issue is only for the DynamicHTTP- provider,
and not relevant for any others, including the Filesystem- one.


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

There's nothing obviously wrong (that I can see) with the syntax, etc,
so....


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

It's 99.9% certain that the signature validation is failing, and so the
message is correct.   If that is the case, you should have clear logs
indicating the signature failure.

Didn't you post last week-ish about something failing with signature
validation?  IIRC you had some custom metadata signing from your org's
developer, and the signature digest wasn't matching the validation
digest.  If you still haven't resolved that, then it's not going to
work.  Or if you did resolve that, then there's still something wrong
with signature validation, such as the validation cert you're pointing
at doesn't match the private key used to sign.

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

It's nothing like that.  The fact that it works without the
SignatureValidation filter tells you that the metadata and entityID
fundamentally are correct.  It's a virtual certainly that the metadata
is simply not passing the signature validation check.  Again, you
should see earlier log messages about that failure.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180806/91cd6a17/attachment.html>