Credential matching relies on KeyInfo names too strictly, breaks signature verification

Description

The latest version of the SP/OpenSAML (see environment above for versions; it's really odd that it says Shibboleth 1.3.0, even though I know this is Shibboleth 2.3) code fails to validate the signature on the metadata at:

https://sso-test.isis.unc.edu/metadata/unc

The same code that produces this metadata and signature also produces the one at:

https://sso-dev.isis.unc.edu/metadata/unc

which works just fine. Previous versions of the service provider work just fine, and the file is not being corrupted during transit.

Pasting the metadata from the document that fails to validate into the signature verification tool at http://www.aleksey.com/xmlsec/xmldsig-verifier.html returns the following:

func=xmlSecOpenSSLX509NameRead:file=x509vfy.c:line=986:obj=unknown:subj=unknown:error=12:invalid data:reading octect values is not implemented yet
func=xmlSecOpenSSLX509FindCert:file=x509vfy.c:line=696:obj=unknown:subj=xmlSecOpenSSLX509NameRead:error=1:xmlsec library function failed:subject=CN=sso-test.isis.unc.edu,OU=Comodo InstantSSL,OU=Issued through University of North Carolina at Chapel Hill E-PKI,OU=Information Technology Services,O=University of North Carolina at Chapel Hill,STREET=CB 3420,L=Chapel Hill,ST=North Carolina,2.5.4.17=#130a32373539392d33343230,C=US
RESULT: Signature is OK

so it seems not to be an issue with the signature itself. I have verified that I have the correct certificate referenced in the MetadataProvider stanza:

<!-- Example of remotely supplied batch of signed metadata. -->
<MetadataProvider type="XML" uri="https://sso-test.isis.unc.edu/metadata/unc"
backingFilePath="unc-test-metadata.xml" reloadInterval="7200">
<MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
<MetadataFilter type="Signature" certificate="/opt/local/etc/shibboleth/sso-test.crt"/>
</MetadataProvider>

<MetadataProvider type="XML" uri="https://sso-dev.isis.unc.edu/metadata/unc"
backingFilePath="unc-dev-metadata.xml" reloadInterval="7200">
<MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
<MetadataFilter type="Signature" certificate="/opt/local/etc/shibboleth/sso-dev.crt"/>
</MetadataProvider>

The only logs I can seem to get (even when setting everything to debug in shibd.logger) say:

2009-11-18 16:21:16 INFO OpenSAML.MetadataProvider.XML : loaded XML resource (https://sso-test.isis.unc.edu/metadata/unc)
2009-11-18 16:21:16 DEBUG OpenSAML.MetadataProvider.XML : backing up remote resource to (/opt/local/var/run/shibboleth/unc-test-metadata.xml)
2009-11-18 16:21:16 INFO OpenSAML.Metadata : applying metadata filter (RequireValidUntil)
2009-11-18 16:21:16 INFO OpenSAML.Metadata : applying metadata filter (Signature)
2009-11-18 16:21:16 WARN OpenSAML.MetadataFilter.Signature : filtering out group at root of instance after failed signature check: CredentialResolver did not supply a successful verification key.
2009-11-18 16:21:16 CRIT OpenSAML.Metadata.Chaining : failure initializing MetadataProvider: SignatureMetadataFilter unable to verify signature at root of metadata instance.

This service provider is running on Mac OS X Snow Leopard, installed fresh today (18 November 2009) via macports, but we have seen this on other OSes as well (see shib-users thread titled Problems Verifying IdP Metadata Signature starting 16 November 2009).

Environment

2009-11-18 16:21:16 INFO Shibboleth.Config : Library versions: Xerces-C 3.0.1, XML-Security-C 1.5.1, XMLTooling-C 1.3.1, OpenSAML-C 2.3.0, Shibboleth 1.3.0

Activity

Show:

Scott Cantor December 3, 2009 at 2:22 PM

Closing with release. Wiki documentation will be updated, reflecting that the fix for this bug is now to add extractNames="false" to any File resolver that's causing verification failures due to name-mismatches.

Scott Cantor December 2, 2009 at 6:28 PM

Reopening to implement a more configurable fix that doesn't cause as much breakage with other use cases. Will make the auto-extraction of names a config option in the plugin, and leave on by default, so cases where it breaks anything can simply disable it. Those cases are much rarer.

Scott Cantor November 23, 2009 at 10:37 AM

http://svn.middleware.georgetown.edu/view/cpp-xmltooling?view=rev&revision=683

Disabled extraction of local credential names in favor of configuring them manually when needed.

Added additional logging to matching process to identify why credentials aren't returned.

Scott Cantor November 19, 2009 at 6:01 PM

I agree, it's an unintended side effect I need to fix, and I'm elevating the priority. This could break even runtime signatures very easily and I should be able to issue a patch release to fix it.

Since you have a simple work-around, I can take more time to look at my options.

Fixed
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Components

Fix versions

Affects versions

Created November 18, 2009 at 5:13 PM
Updated December 3, 2009 at 2:22 PM
Resolved December 2, 2009 at 10:53 PM

Flag notifications