Metadata resolver is looking at ID instead of entityID

[Cody Carmichael]

Yes I did post last week about the logs showing different values for the
expected and actual digest values. The logs are no longer showing messages
about that. Right now the logs spit out the decoded SAML message that
contains stuff for the AuthnRequest like the DigestMethod, DigestValue,
SignatureValue, KeyInfo, etc... And then right after that is the message
that the Metadata backing store does not contain any EntityDescriptors.

There is also this message at the end of the log:

Profile Action SelectProfileConfiguration: Profile
> http://shibboleth.net/ns/profiles/saml2/sso/browser is not available for
> RP configuration shibboleth.UnverifiedRelyingParty (RPID
> https://mySP.net/rest/v2/sso/message/shibboleth/metadata)


But I figured that was because it's calling my SP unverified because it's
not finding the metadata, and it's not finding the metadata for reasons I
haven't figured out. If the signature validation check is still failing,
the logs are not giving any indication of it.

On Mon, Aug 6, 2018 at 2:39 PM, Brent Putman <putmanb at georgetown.edu> wrote:

>
>
> 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/699efcfb/attachment.html>