Skip to Content.
Sympa Menu

mace-opensaml-users - Re: [OpenSAML] Verifying SAML signed metadata files

Subject: OpenSAML user discussion

List archive

Re: [OpenSAML] Verifying SAML signed metadata files


Chronological Thread 
  • From: Brent Putman <>
  • To:
  • Subject: Re: [OpenSAML] Verifying SAML signed metadata files
  • Date: Mon, 28 Apr 2008 19:21:37 -0400



Paolo Selvini wrote:
Hi,
I need to parse a signed metadata file and verify its signature against a given certificate.
I am using version 2.1.0 of the OpenSAML library and now in fact the getSignature() method of EntityDescriptor returns a non null object. :-)
 
For a clear start I got a sample signed metadata from the OpenSAML-J 2.1.0 source code, in the file src\test\resources\data\org\opensaml\saml2\metadata\metadata.switchaai_signed.xml.
Then I extracted the public certificate in PEM format from such file and I have subsequently saved it, to use in the code.
 
The following is the code I used for reading and verifying the signed metadata file:
 
FilesystemMetadataProvider fsmd = new FilesystemMetadataProvider(new File(signedMetadataFilename));
fsmd.setParserPool(new BasicParserPool());
fsmd.initialize();
EntityDescriptor signedEntityDescriptor = fsmd.getMetadata();

The MetadataProvider impls drop the cached DOM after the provider is initialized in order to save memory.  On the signature element, this also includes dropping the Apache XMLSignature object which has been cached from unmarshalling. Both would be necessary to validate the signature.  In your case I think the ValidationException is getting getting (correctly) thrown by the SAMLSignatureProfileValidator, because the Apache XMLSignature instance is unavailable.

 

 
What's wrong with the former way to read a metadata from the file system? I assume the same would happen with a FileBackedURLMetadataProvider.

Yeah, the same thing would happen with the other provider.

So because of this, you can't really validate the signature on the metadata by pulling the root object off and processing it, nor anything else that requires access to the cached DOM elements of the tree, such as DOM-level schema validation. This is the expected behavior.

I would like to keep using the providers for reading metadata, as they embed the caching mechanism.

The correct approach is to use a MetadataFilter.  See the SignatureValidationFilter in the saml2.metadata.provider package. This requires the use of a SignatureTrustEngine, which is a higher-level API than the low-level SignatureValidator.  To replicate what you currently do (validate against a known key/cert trusted explictly in advance), just use an ExplicitKeySignatureTrustEngine, built with a StaticCredentialResolver containing your trusted keys/cert(s).

After building the filter, you'll just add to the provider with setMetadataFilter *before* you call fsmd.initialize().  If if fails validation, you'll get a FilterException.

For examples of how to build the filter, see also the SignatureValidationFilterTest in  src\test\resources\data\org\opensaml\saml2\metadata\provider.


--Brent




Archive powered by MHonArc 2.6.16.

Top of Page