Metadata resolver is looking at ID instead of entityID

[Cody Carmichael]

Ah, you were correct that I needed to look earlier in the logs.


> [org.apache.xml.security.signature.Reference:791] - Verification failed
> for URI "#_f82d91b40d8850701548612d14cedb7b"
> [org.apache.xml.security.signature.Reference:792] - Expected Digest:
> Igunx6qgopGS6lUqRjopyPq9wLZN51legZzLMQb0Q98=
> [org.apache.xml.security.signature.Reference:793] - Actual Digest:
> N/rKwh55tO5Ap5n9FIHEMwgmRn/iUE/TiuGiLGDan/0=


The dev has checked the code on their side and found no issues in the
signature. Does it matter that the cert.pem that my metadata-provider is
pointing to is a standard public cert that contains the 'BEGIN
CERTIFICATE/END CERTIFICATE' strings? The key and cert were created per the
"Creating a SAML key and Certificate" section of the docs except the
signature algorithm is sha256WithRSAEncryption instead of the
sha1WithRSAEncryption that appears in the example. Exactly what part of the
metadata needs to be hashed to create the digest value that is added in the
signed info?

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

>
>
> On 8/6/18 3:27 PM, Cody Carmichael wrote:
>
> 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...
>
>
> Errors about the signature validation would occur well before that.  Since
> this is the Filesystem- provider, errors there would occur at IdP startup
> and/or at metadata refresh time.  I'd wager a hefty sum that if you restart
> your IdP, and then look the logs since that startup (without even
> attempting any SP login activity) you will see errors there from the
> SignatureValidation filter and the components it calls.
>
>
> 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.
>
>
> Correct, exactly.  In the IdP "unverified" means "no metadata" for that
> entity.
>
>
> If the signature validation check is still failing, the logs are not
> giving any indication of it.
>
>
> Look earlier in the logs.  The errors with the Filesystem- provider will
> happen at IdP start time, not when you are attempting to log in to your
> SP.  (The latter would be true as you were doing before with the dynamic
> HTTP provider, since there it's going to resolve the metadata at runtime
> when it first needs to be looked up.)
>
> --Brent
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180807/abbaf9de/attachment.html>