Verification failed for URI

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Verification failed for URI

Cody Carmichael
I know what's happening but I don't know why. I'm new to stuff like signing and encryption and the shibboleth docs don't explicitly say WHICH certificate you're supposed to point to with the certificateFile attribute of the SignatureValidation filter. Here is my Metadata provider configuration:

<MetadataProvider id="HTTPMetadataCRC"
                  xsi:type="DynamicHTTPMetadataProvider">
        
        <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
                certificateFile="%{idp.home}/credentials/cert.pem"/>
</MetadataProvider> 

The cert.pem file is the SP's public key. The SAML request sent from the SP contains that same public key along with a DigestValue. But in the logs I have the following:

WARN [org.apache.xml.security.signature.Reference:791] - Verification failed for URI "#_someLongString"
WARN [org.apache.xml.security.signature.Reference:792] - Expected Digest: ABC123=
WARN [org.apache.xml.security.signature.Reference:793] - Actual Digest: XYZ456=
ERROR [org.opensaml.saml.metadata.resolver.filter.impl.SignatureValidationFilter:420] - Signature trust establishment failed for metadata entry https://mySP.net/rest/v2/sso/shibboleth/metadata

So, what specific cert file is the certificateFile attribute supposed to be pointing to? If it's supposed to be the SP's public key, why would the DigestValues be different?  

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Verification failed for URI

Tom Scavo
On Thu, Aug 2, 2018 at 5:39 PM, Cody Carmichael <[hidden email]> wrote:

>
> Here is my Metadata provider configuration:
>
>> <MetadataProvider id="HTTPMetadataCRC"
>>                   xsi:type="DynamicHTTPMetadataProvider">
>>
>>         <MetadataFilter xsi:type="SignatureValidation"
>> requireSignedRoot="true"
>>                 certificateFile="%{idp.home}/credentials/cert.pem"/>
>> </MetadataProvider>

This metadata provider has no child element (apart from the metadata
filter of course). Is that intentional? (I doubt it.)

From the wiki:

If you forget to configure a child element, the provider will default
to the well-known location strategy. This constrains the entityID to
be an URL (not an URN) but the provider does not check the URL scheme.
If the scheme on the entityID is "http:", the metadata exchange will
be vulnerable to a man-in-the-middle attack. For this reason, the
well-known location strategy should be avoided in most cases.

> The cert.pem file is the SP's public key. The SAML request sent from the SP
> contains that same public key along with a DigestValue.

The public key in SP metadata has nothing to do with the signature on
the SP metadata file.

> So, what specific cert file is the certificateFile attribute supposed to be
> pointing to?

It is the public key corresponding to the private key that signed the metadata.

You need to step back for a moment. The IdP rarely obtains SP metadata
directly from the SP, at least not dynamically.

Tom
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Verification failed for URI

Brent Putman
In reply to this post by Cody Carmichael



On 8/2/18 5:39 PM, Cody Carmichael wrote:
I know what's happening but I don't know why. I'm new to stuff like signing and encryption and the shibboleth docs don't explicitly say WHICH certificate you're supposed to point to with the certificateFile attribute of the SignatureValidation filter.

As Tom said, it would be the cert whose public key corresponds to the private key used to sign the metadata.


The cert.pem file is the SP's public key. The SAML request sent from the SP contains that same public key along with a DigestValue. But in the logs I have the following:

WARN [org.apache.xml.security.signature.Reference:791] - Verification failed for URI "#_someLongString"
WARN [org.apache.xml.security.signature.Reference:792] - Expected Digest: ABC123=
WARN [org.apache.xml.security.signature.Reference:793] - Actual Digest: XYZ456=

You're obfuscating the values there, obviously, but if the expected vs actual values are indeed different, then this is not indicating a cert problem.  It really does mean that the signature was generated over bytes that are different than what you are receiving.  So it really is an invalid signature.

Since as Tom said, you seem to be using the "well-known location" strategy, that means you're getting the metadata directly from the SP dynamically. That's a bit unusual, but not really incorrect, if that is what is intended here.  You'd have to followup with the SP to troubleshoot this. Most likely something about the way they are storing or hosting or publishing the metadata is causing changes to the metadata document after signing, resulting in a signature validation failure even if the validation key is correct (it may not be, you'd want to confirm that as well). The addition or removal of even a single whitespace character in the signed bytes of the document will result in signature failure.


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Verification failed for URI

Brent Putman
In reply to this post by Tom Scavo



On 8/2/18 6:28 PM, Tom Scavo wrote:
If you forget to configure a child element, the provider will default
to the well-known location strategy. This constrains the entityID to
be an URL (not an URN) but the provider does not check the URL scheme.
If the scheme on the entityID is "http:", the metadata exchange will
be vulnerable to a man-in-the-middle attack. 

That's true, but if the metadata is signed and you have the SignatureValidation filter enabled with requireSignedRoot="true", as he does, then that warning re MITM is not really relevant.

For this reason, the
well-known location strategy should be avoided in most cases.

I'd say personally that's a little strong.  If used correctly, as it appears to be here, then it's technically speaking fine, albeit a little atypical.


You need to step back for a moment. The IdP rarely obtains SP metadata
directly from the SP, at least not dynamically.

It's unusual, but we do support that model of self-signed and self-published metadata, including use of URI subject alt names in certs to bind the signing key to the party's entityID.  There was a time when we thought this might be one way out of the non-scalable batch model of metadata.  MDQ is probably the true way forward at this point, but the well-known location strategy isn't really "bad", if implemented correctly.

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Verification failed for URI

Cody Carmichael
In reply to this post by Brent Putman
The SP in this case is a product under development by the company I work for. I've been working with the SP's dev for several days on this and unfortunately it's very time sensitive. What would be the more 'usual' way to get metadata from the SP? FileBackedHttp? I'm new to most of the concepts involved with shibboleth so I don't have a concept of the typical way to do things.

What would make the signature invalid? The dev generated the public and private keys and I have a copy of the public key which is the cert.pem that's being pointed to. 


On Thu, Aug 2, 2018 at 7:09 PM, Brent Putman <[hidden email]> wrote:



On 8/2/18 5:39 PM, Cody Carmichael wrote:
I know what's happening but I don't know why. I'm new to stuff like signing and encryption and the shibboleth docs don't explicitly say WHICH certificate you're supposed to point to with the certificateFile attribute of the SignatureValidation filter.

As Tom said, it would be the cert whose public key corresponds to the private key used to sign the metadata.


The cert.pem file is the SP's public key. The SAML request sent from the SP contains that same public key along with a DigestValue. But in the logs I have the following:

WARN [org.apache.xml.security.signature.Reference:791] - Verification failed for URI "#_someLongString"
WARN [org.apache.xml.security.signature.Reference:792] - Expected Digest: ABC123=
WARN [org.apache.xml.security.signature.Reference:793] - Actual Digest: XYZ456=

You're obfuscating the values there, obviously, but if the expected vs actual values are indeed different, then this is not indicating a cert problem.  It really does mean that the signature was generated over bytes that are different than what you are receiving.  So it really is an invalid signature.

Since as Tom said, you seem to be using the "well-known location" strategy, that means you're getting the metadata directly from the SP dynamically. That's a bit unusual, but not really incorrect, if that is what is intended here.  You'd have to followup with the SP to troubleshoot this. Most likely something about the way they are storing or hosting or publishing the metadata is causing changes to the metadata document after signing, resulting in a signature validation failure even if the validation key is correct (it may not be, you'd want to confirm that as well). The addition or removal of even a single whitespace character in the signed bytes of the document will result in signature failure.




--



Cody Carmichael 
Engineering Operations  | Voalte
Office: 941-312-2830 | Ext 

Email: [hidden email]
  

 


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Verification failed for URI

Cantor, Scott E.
In reply to this post by Brent Putman
On 8/2/18, 7:16 PM, "users on behalf of Brent Putman" <[hidden email] on behalf of [hidden email]> wrote:

> That's true, but if the metadata is signed and you have the SignatureValidation filter enabled with
> requireSignedRoot="true", as he does, then that warning re MITM is not really relevant.

Only if signatures are combined with short validity windows and a filter to enforce the upper bound on that window, otherwise you're vulnerable to injection of old metadata that invalidates revocation.

In practice, this just isn't something you can rely on any single SP to do, it's a trust model that only works at federation scale. SAML has no trust model outside of our federation model, it's simply "punt, do nothing, pretend it's fine". How we got here is sad and confusing, but when I tossed PKIX, I never anticipated people would simply accept "nothing" as an alternative for revocation.

> I'd say personally that's a little strong.  If used correctly, as it appears to be here, then it's technically speaking fine,
> albeit a little atypical.

It's a case of overstating the facts to convince people to avoid doing something that's a bad idea 95% of the time. Not to mention you're trusting that SP to actually use their metadata properly when it comes to changing keys, etc. You just can't in practice, so it breaks anyway.

"Never do it" is a better piece of advice for the vast majority of deployers than trying to explain all the caveats one would have to understand and implement to do it properly.

That's always been my underlying thinking anyway.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Verification failed for URI

Tom Scavo
In reply to this post by Cody Carmichael
On Thu, Aug 2, 2018 at 7:21 PM, Cody Carmichael <[hidden email]> wrote:
> The SP in this case is a product under development by the company I work
> for. I've been working with the SP's dev for several days on this and
> unfortunately it's very time sensitive. What would be the more 'usual' way
> to get metadata from the SP? FileBackedHttp? I'm new to most of the concepts
> involved with shibboleth so I don't have a concept of the typical way to do
> things.

See the MetadataManagementBestPractices [1] topic.

From what you've said so far, this sounds like local metadata to me.

Tom

[1] https://wiki.shibboleth.net/confluence/x/JQXKAg
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Verification failed for URI

Cantor, Scott E.
In reply to this post by Cody Carmichael
On 8/2/18, 7:21 PM, "Cody Carmichael" <[hidden email]> wrote:

> The SP in this case is a product under development by the company I work for. I've been working with the SP's dev for
> several days on this and unfortunately it's very time sensitive. What would be the more 'usual' way to get metadata
> from the SP? FileBackedHttp? I'm new to most of the concepts involved with shibboleth so I don't have a concept of the
> typical way to do things.

You might want to read [1]. If you're not following one of the models discussed, the fallback of doing it all manually by hand and punting security is simply the norm unfortunately.

The usual way is you need a federation, a third party to sign the metadata that exists between the two. If you're inside a firewall, then the usual way is doing things manually with the understanding that updates and revocation would be done by calling the guy up. That works inside an enterprise, just not otherwise. Even there, having automated metadata update is good, but you can't do that correctly unless the one producing it understands how to separate the metadata from the software's actual configuration to properly handle updates before they actually get made to the running system. That's essential for key rollover.

These are not Shibboleth concepts, for the record. The only standardized trust model SAML has is mine, and I published it at OASIS as the Metadata Interoperability Profile. Nobody not doing that is doing anything interoperable and usually they're not doing anything securely either. But doing that virtually requires a third party metadata source, or a fair amount of careful planning and work.

-- Scott

[1] https://wiki.shibboleth.net/confluence/display/CONCEPT/TrustManagement


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Verification failed for URI

Brent Putman
In reply to this post by Cody Carmichael



On 8/2/18 7:21 PM, Cody Carmichael wrote:
The SP in this case is a product under development by the company I work for. I've been working with the SP's dev for several days on this and unfortunately it's very time sensitive. What would be the more 'usual' way to get metadata from the SP? FileBackedHttp?
Ah.  Well, if you're still in the dev/testing phase and are just trying to get a working interop between a dev IdP and SP, then the easiest is to probably just manually configure the SP's metadata on the IdP using the Filesystem- provider and avoid the signature or verifying.  Since you've presumably manually obtained it from a trusted source and and trust your own system and filesytem, that's fine, at least for dev/testing etc.

I'm new to most of the concepts involved with shibboleth so I don't have a concept of the typical way to do things.

There probably isn't a single typical way, it depends. It's a big topic.  The most common approaches are: 1) IdP and SP are members of a federation and they both consume each other's metadata by consuming the federation's published aggregate 2) use of an MDQ server for dynamic metadata 3) share the metadata out-of-band as I described above.  #3 doesn't scale very well though, for obvious reasons, and should usually be avoided for real production deployments.


What would make the signature invalid? The dev generated the public and private keys and I have a copy of the public key which is the cert.pem that's being pointed to. 


The error you posted has nothing to do with the keys.   Either the signature was fundamentally invalid from the time it was signed, due to a broken signature approach, a bug, etc; or perhaps more likely, the metadata document was changed after it was signed.  If the XML signature library the dev is using is known to be good, then it's likely to be the latter.  If he's doing something fundamentally wrong or the library has bug(s) or he/she is rolling their own XML signature code, then it could very well be the former. 

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Verification failed for URI

Cody Carmichael
In reply to this post by Tom Scavo
See the MetadataManagementBestPractices [1] topic.

Yes I've read through that, but it didn't provide any use cases. Like if the SP is going to have lots of people logging in and out, doesn't the SP metadata need to be gotten with each login? So wouldn't it make sense to get it dynamically instead of from a static file? Is the metadata something to identity each user logging in or just the SP itself? These are the dumb questions I need clarification on.

On Thu, Aug 2, 2018 at 7:27 PM, Tom Scavo <[hidden email]> wrote:
On Thu, Aug 2, 2018 at 7:21 PM, Cody Carmichael <[hidden email]> wrote:
> The SP in this case is a product under development by the company I work
> for. I've been working with the SP's dev for several days on this and
> unfortunately it's very time sensitive. What would be the more 'usual' way
> to get metadata from the SP? FileBackedHttp? I'm new to most of the concepts
> involved with shibboleth so I don't have a concept of the typical way to do
> things.

See the MetadataManagementBestPractices [1] topic.

From what you've said so far, this sounds like local metadata to me.

Tom

[1] https://wiki.shibboleth.net/confluence/x/JQXKAg
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]



--



Cody Carmichael 
Engineering Operations  | Voalte
Office: 941-312-2830 | Ext 

Email: [hidden email]
  

 


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Verification failed for URI

Tom Scavo
On Thu, Aug 2, 2018 at 7:37 PM, Cody Carmichael <[hidden email]> wrote:
>> See the MetadataManagementBestPractices [1] topic.
>
> Yes I've read through that, but it didn't provide any use cases.

I appreciate any feedback you might have.

> Like if the
> SP is going to have lots of people logging in and out, doesn't the SP
> metadata need to be gotten with each login?

No, the number of user accesses is irrelevant.

> So wouldn't it make sense to get
> it dynamically instead of from a static file?

No, see above.

> Is the metadata something to
> identity each user logging in or just the SP itself?

That's a key question and probably the source of most of your
confusion. The metadata describes the SP, not the user.

Tom
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]