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: Paolo Selvini <>
  • To: "" <>
  • Subject: RE: [OpenSAML] Verifying SAML signed metadata files
  • Date: Fri, 2 May 2008 15:42:12 +0200
  • Accept-language: it-IT, en-US
  • Acceptlanguage: it-IT, en-US

Hi again and thanks for the hint about the metadata filter.
I did as you suggested and I managed to correctly verify a signed metadata file.
 
Now I have a (hopefully) last problem: my original metadata file contains a SPSSODescriptor element with a number of AttributeConsumingService elements. According to the specification, each of those can store one or more RequestedAttribute elements, possibly including a FriendlyName attribute.
 
However, if I use - for the value of such FriendlyName attribute - some accented chars (like à, è, ...) that are pretty common in the Italian language, the signature in the new signed file is no more verified. That is, the same code used to sign and verify a metadata file without accented chars, no longer works it I change even just a single char (say from "a" to "à") in the unsigned file, sign it and verify it. If I replace the accented char back with a normal char, sign and verify again, everything is ok.
What happens is a MetadataProviderException with inner cause "org.opensaml.saml2.metadata.provider.FilterException: Signature trust establishment failed for metadata entry" when I invoke the initialize() method on the metadata provider.
 
FYI: both the unsigned and the signed files have UTF-8 encoding without BOM (byte order mark).
 
Any idea about the possible cause?
 
thanks,
Paolo
 


From: Brent Putman [mailto:]
Sent: martedì 29 aprile 2008 1.22
To:
Subject: Re: [OpenSAML] Verifying SAML signed metadata files



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



Le informazioni contenute in questa comunicazione e negli allegati sono riservate; e' vietato a soggetti diversi dai destinatari qualsiasi uso, copia, diffusione di quanto in essi contenuto.
Se avete ricevuto questa copia per errore, vi preghiamo di distruggerla immediatamente ed informarci via e-mail.

Prima di stampare questa e-mail consideratene l’impatto sull’ambiente. Grazie per la collaborazione.


This e-mail and any attachment(s) are strictly confidential. This message must not be copied, disclosed or used by anybody other than the intended recipient(s).
If you are not the intended recipient, please inform the sender by e-mail and destroy this message immediately.

Please consider the environment before printing this e-mail. Thank you for your cooperation.



Archive powered by MHonArc 2.6.16.

Top of Page